Skip to main content
SCIM (System for Cross-domain Identity Management) makes your identity provider (IdP) the source of truth for who can access incident.io and what they can do, so accounts and permissions follow your directory rather than being managed by hand. SCIM is available on the Enterprise plan. This guide is for administrators setting up SCIM: you’ll need the Manage security settings permission in incident.io and admin access to your identity provider.

​
How SCIM works

​
Without SCIM

Anyone in any connected Slack workspace can have an incident.io account. We create their account when they interact with incident.io in Slack (for example, by joining an incident channel) or sign in to the web dashboard with Slack. When they’re deactivated in Slack, they’re automatically deactivated in incident.io.
Users can also get an incident.io account by signing in to the web dashboard using SAML. You grant additional base roles and custom roles by hand, so when someone joins, a user with the Manage users permission assigns their permissions from Settings → Users → Users tab. See user roles and permissions for more details.

​
With SCIM

When SCIM is enabled, users are provisioned automatically from your IdP the moment they’re assigned the incident.io application, and deactivated when they’re unassigned, so leavers lose access with no manual step. Roles are managed entirely by your IdP and can no longer be edited in incident.io, so you don’t have to assign roles to new joiners or downgrade users when their access changes. Your SCIM groups also sync into the Catalog, so you can use them to drive workflows and on-call. See user roles and permissions for more details.

​
Setting up SCIM

1

Connect your identity provider

Go to Settings → Users → SCIM and click Connect. Choose your provider and follow the provider-specific steps to create the connection.
The SCIM tab of the Users settings page, with a Connect button
We support featured providers including Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, OneLogin, JumpCloud, CyberArk, PingFederate, and Rippling, as well as a generic Custom SCIM option for anything else. For a detailed, provider-specific walkthrough, see Okta SCIM setup.
The provider list titled Select your identity provider, showing Okta, Entra ID, Google Workspace, CyberArk, JumpCloud, OneLogin, PingFederate, Rippling, and a Custom SCIM option
SCIM is push-based, so incident.io only syncs the groups you choose to push from your IdP. If a group you expect isn’t showing up, you likely need to push it from your provider. See the SCIM team sync FAQ for details.
2

Map groups to roles

Once you’re connected, click Complete setup to open the setup wizard, then map your SCIM groups to incident.io roles.By default, every SCIM user is given the Standard role, which assigns a Viewer seat, so you only need to add assignments for groups that should get elevated permissions. Any user assigned a role other than Standard uses a Responder seat. Learn more about seat types.A user takes the highest base role across all their mapped groups, plus every custom role from those groups. Some examples:
  • Everyone in the Engineers group should have access but no admin permissions. You don’t need a mapping for this, since the default Standard role already covers it.
  • You and other Incident Managers should be admins, so you add an assignment mapping the Incident Managers group to the Admin role.
  • Your IT team should manage SCIM and SAML, so you map the IT group to a custom role with the Manage security settings permission.
You must map at least one group to the Owner role before you can finish setup. If you’re not in that group, or you later remove yourself from it, you’ll be locked out of your SCIM settings. If that happens, contact us at help@incident.io.
The Complete SCIM setup wizard on the Map groups to roles step, before any groups have been assigned
3

Confirm and enable

Review the confirmation step, then click Enable SCIM and assign roles.From here, incident.io starts creating users from SCIM and reassigning any permissions that don’t match your group-to-role mappings, so users with admin, owner, or custom roles will lose them if their groups aren’t mapped accordingly. It can take a few minutes for roles to update.
From here you might want to:
  • Manage roles as your teams change. Update your group-to-role mappings any time.
  • Assign on-call seats by group. Give whole SCIM groups an on-call seat automatically.
  • Build a team structure from your groups. Use your synced SCIM groups to create a Team catalog type that drives workflows and on-call.
  • Enforce single sign-on. Set up SAML SSO, which runs independently of SCIM but can use the same identity provider, such as Okta or Microsoft Entra ID.

​
Managing roles after setup

To change your group-to-role mappings later, go to Settings → Permissions → SCIM assignment. Click Add assignment to map a new group, or edit and remove existing assignments. Removing a group’s assignment downgrades its members to Viewer permissions.

​
Assigning on-call seats

You can also give whole SCIM groups an on-call seat automatically. On the Settings → Users → SCIM page, use the On-call seat assignments section and click Add assignment to pick a group. Members of an assigned group are automatically granted an on-call seat that can’t be manually removed. If someone leaves the group, they keep their seat until it’s manually revoked. See managing seats for more.

​
Disabling SCIM

To turn SCIM off, go to Settings → Users → SCIM and click Disable SCIM. Once disabled, you can manage user roles in incident.io again. Existing users keep their current roles, but any SCIM-only users (those with no Slack, Teams, or SAML login) are deactivated, since they’d have no way to sign in. To re-enable SCIM, you go through the setup steps again.

​
FAQs

SCIM is available to customers on our Enterprise plan. For more pricing details, see pricing.
When you enable SCIM, we link existing users to SCIM users by their email address. We then update their permissions to match the group-to-role mappings you’ve defined. If a user was previously an admin but isn’t in a group mapped to the admin role, they’ll be downgraded to a viewer or responder.If a user exists in incident.io but not in SCIM, they keep their existing role and are marked as ‘Unlinked’ in the user list. If you don’t want these users to have dashboard access at all, we recommend setting up SAML against the same identity provider, so that only users assigned the incident.io app can sign in.
Most users are left in their current state, so if you’re an owner you’ll keep your owner role. The exception is SCIM-only users (those with no Slack, Teams, or SAML login): they’re deactivated when you disable SCIM, since they’d otherwise have no way to sign in.
No. Once SCIM is enabled, it becomes the source of truth for a user’s permissions. To elevate a user’s permissions, add them to an appropriate group in your identity provider.
A user can be deactivated in your IdP but remain active in incident.io through Slack or Microsoft Teams. In Slack, they remain active while they’re a member of a connected workspace. In Microsoft Teams, they remain active while they’re a member of a team where the incident.io bot is installed. To avoid this, use the same identity provider to manage access to incident.io and your connected Slack or Microsoft Teams accounts.
Yes. If you have both SAML and SCIM set up, users can sign in via your identity provider and be added to schedules and escalation paths without needing a Slack or Microsoft Teams account.SCIM provisions the user and assigns their on-call seat, while SAML handles their login. The two don’t need to point at the same IdP, as long as the user appears in both with the same email address.Without SAML and SCIM, users need a Slack or Microsoft Teams account to participate in on-call rotations.