Setting up SSO and SCIM for your phone system

A phone system holds call history, recordings and the ability to dial out as your company, so it is worth treating as a proper business application. Two standards keep it in step with the rest of your accounts: single sign-on, which handles sign-in, and SCIM, which handles the creation and removal of accounts. They are often mentioned together but they solve different problems, and you will want both.

What each one does

• Single sign-on (SSO), commonly through SAML: staff sign in to the phone system with their company identity, using the same password and multi-factor checks as everything else. The phone system trusts the identity provider's answer instead of keeping a separate password.
• SCIM, the System for Cross-domain Identity Management: the identity provider tells the phone system when to create, update or deactivate a user, and which groups they belong to. Nobody has to create accounts by hand.

Tizbo supports SAML SSO and SCIM, so users and teams can be provisioned from your identity provider and removed from it.

The distinction matters at the edges. With SSO alone, a person who has left can no longer sign in once their company identity is disabled, but their account, extension and call routing still exist until someone deletes them. With SCIM, deactivation in the identity provider reaches the phone system, and the account is deactivated there too.

Before you start

1. Decide who administers the identity provider and who administers the phone system. The setup needs both, usually in a short working session.
2. List the groups you will map: for example everyone in Support, everyone in Sales, and a small group of phone administrators.
3. Decide what each group gets: which team, which role and which numbers or queues.
4. Keep a break-glass administrator account that signs in without SSO, stored securely, in case the identity provider is unavailable.
5. Tell staff the date, and what will change for them when they next sign in.

The joiner flow

When a new person joins, HR or IT creates them in the identity provider and puts them in the right group. SCIM then creates their phone account, assigns them to the team that matches their group, and gives them the role mapped to it. On their first day they sign in with SSO and find their extension and their team already there. The aim is that nobody on the phone side does anything for a standard hire.

The mover flow

When someone changes teams, the identity provider group changes and SCIM updates the phone account to match. Check what happens to their old team's queues and their direct number. A person who moves from Support to Sales should stop receiving support calls, and the old group membership should not linger.

The leaver flow

The leaver is the case that justifies the whole exercise. When someone is disabled in the identity provider, three things should follow without anyone remembering to do them:

• They can no longer sign in.
• Their phone account is deactivated, so softphones and desk phones registered to them stop working.
• Their calls go somewhere sensible. Decide in advance where: a colleague, a team queue or voicemail with a message. A number that rings an empty seat loses customers.

Recordings and call history belong to the company, so decide on a retention rule for a departed user's data and record who may access it.

A worked example

Bell & Ortiz LLP has forty staff. Its IT contractor creates three groups in the identity provider: Attorneys, Front desk and Phone admins. Each is mapped to a role and a team in the phone system. The contractor tests with a single account created for the purpose. She adds it to Front desk and confirms the phone account appears with the right team. She signs in with it and checks that the multi-factor prompt appears. She removes it from the group and confirms the phone account is deactivated within the expected time. Only then does she switch the whole firm over.

A month later a paralegal leaves. The office manager disables her in the identity provider on her last afternoon, and her desk phone stops working. Her direct line now rings the front desk group, which the firm set as the rule for departed staff.

Testing checklist

1. Create a test user in the identity provider, in a test group, and confirm the account appears with the correct role.
2. Sign in as that user with SSO, including the multi-factor step.
3. Change the user's group and confirm their team changes.
4. Disable the user and confirm sign-in fails and the account is deactivated.
5. Sign in as the break-glass administrator and confirm it still works.
6. Repeat the whole test after any change to groups or roles.

Common mistakes

• Turning on SSO and forgetting to remove old passwords for administrators.
• Mapping everybody to an administrator role because it is quicker.
• Not testing the leaver flow until someone leaves.
• Letting two sources create users, such as SCIM and a manual import, which produces duplicates.
• Losing access to the break-glass account because it was never written down.

Set a reminder to review group mappings every quarter. Roles drift as teams change, and the identity provider is the one place where you can see the whole picture.