SCIM

An Organization administrator role is required. For information, see User roles.

System for Cross-domain Identity Management (SCIM) allows you to sync users from your identity provider An identity provider (IdP) stores and authenticates the identities of users to log in to system, files, or applications. (IdP) to Nintex Workflow. Once it's set up, you can manage user lifecycles in a Nintex Workflow tenant directly through your IdP. This topic is for Organization admins who manage user lifecycle and access in Nintex Workflow. It covers SCIM concepts, capabilities and limitations, SCIM and SSO integration, SCIM setup, and provisioning outcomes and sync behavior.

SCIM, SSO (single sign-on), and User Directory work independently. Each feature supports a different aspect of user management:

• SCIM enables you to assign roles and Nintex Workflow groups to users based on group memberships in your IdP and configured user management rules.
• Auto onboarding allows any active user with access to the SSO connection to sign in to Nintex Workflow, even if they haven’t been added through SCIM or invited manually. These users are assigned the default Participant role. If a previously disabled user signs in through SSO, auto onboarding re-enables the account. Nintex trusts the IdP. If the IdP allows the user to sign in, the user’s account in Nintex is enabled.
• User Directory lets workflow designers find users and assign tasks to them in workflows.

Prerequisites

You must be an Organization admin, and your organization must have an SSO connection to access SCIM. For more information, see User roles.

SCIM overview

• SCIM keeps users in Nintex Workflow in sync with your IdP, including user details (name, email), status (active/disabled/deleted), and group membership.

• User access is managed through user management rules that map IdP groups to Nintex roles, tenant access and Nintex Workflow group memberships. When multiple rules apply, the highest role is assigned, and users are added to all applicable groups. For more information, see SCIM user management rules.

• If a user no longer matches a user management rule, the access and group memberships granted by that rule are removed.

• SCIM applies only to users included in your IdP provisioning scope. For example, in Microsoft Entra ID, the provisioning scope is determined by the users or groups assigned to the Enterprise application. Members of nested groups are not included automatically, so only direct group members are in scope. If a user is removed from the provisioning scope, the IdP typically sends a SCIM update to disable the user in Nintex.

• SCIM and SSO work independently. Users can still sign in through SSO even if they are not provisioned through SCIM.

Set up SCIM with your identity provider

Note: Nintex Workflow supports the SCIM 2.0 protocol for provisioning and synchronization.

Use this general process to configure SCIM between your identity provider (IdP) and Nintex Workflow. For provider specific steps, see Configure SCIM for Azure Active Directory.

1. Create a directory in Nintex Workflow: On the SCIM page, create and name the directory. Copy the Base URL and API key, and store the key securely. For more information, see SCIM.

2. Configure SCIM in your IdP: Use the Base URL as the SCIM endpoint (Tenant/Base URL) and the API key as the secret or token. Pause auto provisioning, if supported.

3. Configure groups: Assign only the groups you want to manage through SCIM.

   • If you use the default rules, create IdP groups with the same names (for example, Nintex Designers) and assign users to those groups.

   • If you create custom rules, create the required IdP groups and assign users to those groups.

   • Add the groups to the provisioning scope.

   • If your IdP supports it, provision only the groups you plan to use for SCIM (without provisioning users). If not, start auto-provisioning and wait for the provisioning cycle. Custom groups must be provisioned before you can create rules for them.

4. Create user management rules: Use default rules or create rules to map existing IdP groups. For more information, see SCIM user management rules.

5. Complete setup: Start auto-provisioning if it was paused. If auto-provisioning is already running, sync rules to apply them to users provisioned through SCIM during setup.

User management rule outcomes

User management rules are applied based on changes in your IdP. The following table shows how user access and roles are updated in Nintex Workflow.

Action in IdP	Result in Nintex Workflow
Add user to a group linked to a rule	The user is created (if new) and assigned the role defined by the matching rule.
User is in multiple groups linked to rules	Assigns the highest role from applicable rules and adds the user to all Nintex groups defined in those rules.
Remove user from one group, but retain them in another group linked to a rule	Removes the user from the Nintex group if no other rule applies. Recalculates the role based on remaining rules.
Remove user from all groups linked to rules	Removes access assigned through SCIM rules. Further access depends on the SSO configuration.
Disable user in IdP	Marks the user as inactive in Nintex Workflow. Assigned roles and group memberships remain unchanged.
Unassign user from the application in the IdP	Removes SCIM-based access. The user may become inactive depending on IdP behavior. If the user signs in again through SSO, the default Participant role is assigned through auto-onboarding.

Sync options for SCIM

Use the following table to determine which sync option to run based on your requirement. For more information, see Sync rules

Note: The identity provider provisioning cycle and Nintex rule sync serve different purposes. Provisioning sends updates from the identity provider, while rule sync reapplies rule logic to users already provisioned in Nintex Workflow.

Requirement	Action	Location	Details
Push a change from the IdP to Nintex Workflow immediately. For example, an urgent add or remove.	Provision on-demand	In your identity provider. For example, Entra ID Enterprise Application > Provisioning > Provision on-demand	To provision group membership, select the group and include the user during provisioning.
Apply a changed rule to existing users. For example, after disabling or deleting a rule.	Rule sync	Nintex SCIM page > Specific rule	Partial sync applies updates to affected users and reapplies all rules to those users.
Apply all rule changes to existing users after multiple updates	Sync rules (All)	Nintex SCIM page	May take time for large directories. Use only when required.

Troubleshooting SCIM access and synchronization

If you experience SCIM access or sync issues, try the relevant troubleshooting steps below:

• User cannot sign in or does not receive the expected access (role, tenant access, or Nintex group membership):

  1. Confirm that auto-provisioning is not paused in your IdP.

  2. Verify that the user is active in your IdP and that the First name, Last name, and Email fields are populated.

  3. Confirm that the group is assigned to the Enterprise application.

  4. Provision the group and the user membership (run provisioning on demand or wait for the scheduled run), then run a Rule sync in Nintex.

  If the user still does not have access, force the IdP to resend the provisioning request:

  1. Remove the user from the provisioning scope and run provisioning.

  2. Add the user back to the provisioning scope and run provisioning again.

  3. If multiple users in the same IdP group are affected, perform these steps at the group level.

  If the user still cannot sign in:

  1. Check the IdP provisioning logs for errors.

  2. If you see a 401 authentication error, recreate the directory in Nintex and update the API key in your IdP, then run provisioning again.

  If the issue is not resolved, contact Nintex Support.

• Organization admin access issues

  • If another Organization admin is available, they can grant access from the User management page in the Organization settings.

  • If the Organization admin was part of a SCIM managed group:

    Confirm that the Organization admin is still in the group. To ensure Azure Active Directory resends the provisioning event:

    1. Remove the user from the group.

    2. Run provisioning on demand.

    3. Add the user back to the group.

    4. Run provisioning on demand again.

    Note: If your default user management rules are still available, create a group named Nintex Administrators, assign it to the enterprise application, add the Organization admin to the group, and then run provisioning on demand.

  • If the Organization admin wasn’t part of a SCIM managed group:

    If the Organization admin was previously assigned to the enterprise application but later removed, Azure Active Directory may have sent a disable event that deactivated the user in Nintex. To restore access:

    1. Add the Organization admin back to the enterprise application.

    2. Run provisioning on demand.