Table of Contents

Configure Microsoft Entra SCIM Provisioning

Configure Microsoft Entra outbound User provisioning for Diggle’s supported SCIM subset.

Before you start

You need Diggle workspace administrator access, an Entra administrator who can manage application provisioning, the Entra tenant ID, and one assigned test user with an approved work email. Confirm the required Entra licensing with your tenant administrator.

Connect the application

  1. Ask Diggle to enable SCIM for the workspace, then create a provisioning token in Manage Workspace → Integrations. Select Microsoft Entra and enter the Entra tenant ID.
  2. Open the intended Enterprise Application in Microsoft Entra and its Provisioning settings. Configure automatic outbound provisioning for a non-gallery/custom application as applicable.
  3. Enter the copied Diggle SCIM endpoint as Tenant URL. Enter the raw provisioning token as Secret Token; Entra supplies the Bearer authorization header.
  4. Select Test Connection. Save only after the connection succeeds.
  5. Configure User mappings below. Scope provisioning to the intended assigned users. Entra-side group assignment can define that scope; disable synchronization of Group objects to Diggle.

Supported mappings

Entra source conceptDiggle SCIM target
Stable directory object identifier (objectId)externalId
Approved deliverable work email or approved email-shaped principaluserName
Exactly the same approved source expressionemails[type eq “work”].value (optional)
Display namedisplayName
Intended lifecycle expressionactive
Explicit approved workspace roleurn:ietf:params:scim:schemas:extension:diggle:2.0:User:role (optional)

Do not independently map differing UPN and mail values to userName and work email. When both are sent, they must identify the same normalized email. Choose any missing-mail fallback deliberately. Remove unsupported name components, company/HR fields, multiple emails, email labels, projectIds and reprovision mappings.

Configure attribute mappings

  1. Open Entra ID → Enterprise apps → your application → Provisioning → Attribute Mapping and select the User mappings. Older portal layouts show this under Mappings.
  2. Map objectId directly to externalId. For a new integration, use it as the matching attribute with precedence 1. Check existing source-owned users before changing matching rules in an established integration.
  3. If every assigned user has an approved work email in mail, map mail to userName. If you also send work email, use the identical source for both targets. Do not introduce a UPN fallback unless those values are approved deliverable addresses for your workspace.
  4. Map displayName directly. Apply profile and lifecycle mappings on both creation and updates.
  5. Keep active as a Boolean target and use the lifecycle expression below. Do not replace it with a constant true.
Switch([IsSoftDeleted], , "False", "True", "True", "False")

The expression maps the provider’s soft-deleted/out-of-scope state to inactive. Test assignment removal and account disablement with your actual tenant configuration before rollout.

Optional workspace role

  1. In User mappings, open Advanced Options → Edit target User attributes (older layouts: Show advanced options → Edit attribute list).
  2. Add the following attribute as a single-valued, optional String. It is not a primary key or matching attribute.
urn:ietf:params:scim:schemas:extension:diggle:2.0:User:role

Save the attribute list, then add a mapping to this target. If all assigned users should have Run only access, use a Constant value of runner. Otherwise map an approved source value that returns exactly admin, creator or runner. A constant applies to every user in scope and can change existing roles. Omit the mapping if Diggle should retain existing roles and use the default for new users.

See Microsoft’s attribute mapping instructions for the current portal controls and schema editor.

Deprovisioning configuration

Keep Create and Update target object actions enabled. Disable the Delete target object action because Diggle rejects terminal SCIM DELETE. Keep the active lifecycle mapping and do not enable skip-out-of-scope deletions; unassignment must still send a disable update.

Note: Before permanently purging a directory user, confirm that Diggle received active=false or explicitly revoke the user’s workspace access in Diggle. If a user is purged before a disable update arrives, Delete-disabled configuration can leave access active.

Start and monitor provisioning

Assign a small test scope under Users and groups. Set provisioning scope to assigned users and groups only, keep Group object synchronization disabled, and start provisioning. Use Provision on demand for a test user where available. Inspect Provisioning logs for the operation, status and error details, then verify access in Diggle. Test Connection alone does not validate mappings or offboarding.

Validate before expanding scope

  1. Create one assigned test user; verify the expected role.
  2. Update displayName and the approved email aliases. Confirm that the global Diggle login profile is not silently replaced.
  3. Unassign or deactivate the user and verify active=false and loss of workspace access.
  4. Reassign/reactivate and verify permitted membership restoration without historical private project grants.
  5. Test the local Diggle revoke case: later active=true must remain blocked until deliberate admin unblock.
  6. Verify group unassignment, soft deletion and permanent deletion behavior with the chosen target actions.

See Microsoft’s provisioning lifecycle guidance and out-of-scope behavior.

Related articles