> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/configuration/account-and-teams/entra-group-role-provisioning.md).

# Entra groups driving Nullify roles

For connecting the directory and the provisioning-only Entra application, start with [Microsoft Entra ID SSO and SCIM](/configuration/account-and-teams/entra-sso-and-scim.md).

Use your existing LIAM/Saviynt integration to translate Microsoft Entra group membership into Nullify SCIM user roles. This keeps the official production **Nullify** enterprise application, client ID `37d9fe25-ca83-49ac-a099-054de06b1aad`, for Microsoft sign-in and any separate Azure DevOps connection. It does not require a second Entra application or Microsoft Graph permissions on Nullify's sign-in application.

This is a configuration contract for your identity lifecycle system, not an installed Saviynt connector. Your administrator must configure and test the membership source, mappings, synchronization and failure handling. Nullify's SCIM API cannot read your Entra groups itself, and changes take effect only after your client successfully writes them.

## Select the provisioning path

Microsoft [does not enable automatic provisioning on the enterprise application created from an OIDC app registration](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/known-issues#automatic-provisioning-isnt-available-on-my-oidc-based-application). Microsoft's alternatives are gallery integration or a second non-gallery application. Do not assume the official Nullify application's **Provisioning** tab provides a SCIM connector. With the one-application setup, configure your existing LIAM/Saviynt client to call Nullify's SCIM API instead.

Start with the connected production directory and tenant-specific SCIM base URL and credential described in [Microsoft Entra ID SSO and SCIM](/configuration/account-and-teams/entra-sso-and-scim.md#scim-provisioning). Keep this credential in your identity system's approved secret store. Do not use Nullify's Azure application secret as the SCIM credential.

## Agree the group mapping

Use immutable Entra group object IDs from the customer's connected directory. Group display names can change or collide. Map your approved access groups to the following values:

| Customer group object ID                     | Nullify SCIM role value |
| -------------------------------------------- | ----------------------- |
| Your approved Nullify administrator group ID | `admin`                 |
| Your approved Nullify editor group ID        | `editor`                |
| Your approved Nullify viewer group ID        | `viewer`                |

The table deliberately contains no example group IDs: your administrator supplies and verifies the actual IDs. Use the member's Entra **user object ID** as `externalId`, not a group ID, Saviynt account ID, email or UPN. Use the returned SCIM `id` to address that member's later updates.

For each user, evaluate the current approved memberships and compute the complete desired role set before writing:

* Exactly one distinct mapped role: send that one lowercase value and the approved active state. Multiple groups mapping to the same role may collapse to that one value.
* No mapped role, disabled source account, or removal from the approved access scope: explicitly deactivate the existing Nullify user and clear its roles. Omitting the user from a sync run does not remove access.
* Two different mapped roles or an invalid mapping: do not select the highest role or an arbitrary first role. Deactivate the affected user and alert your identity administrator to resolve the conflict before restoring access.
* Failed or incomplete membership retrieval: do not invent a role or treat a partial result as a complete group list. Alert and follow your approved failure and revocation policy; a failed sync does not revoke the last successfully provisioned access automatically.

Decide explicitly whether your LIAM source expands nested groups and how it handles disabled accounts, direct entitlements and conflicting assignments. Microsoft [group-based application assignment](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/assign-user-or-group-access-portal?pivots=portal) requires Entra ID P1 or P2 and does not expand nested groups. Do not assume a separate identity lifecycle connector behaves identically.

## Control sign-in admission in Entra

If your IAM policy restricts the enterprise application to assigned users, open the official **Nullify** enterprise application in your customer directory. Under **Users and groups**, assign the approved groups, then set **Properties → Assignment required?** to **Yes**. Microsoft documents [assignment requirements](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/application-properties) and [restricting application access](https://learn.microsoft.com/en-us/entra/identity-platform/howto-restrict-your-app-to-a-set-of-users).

You can assign the three approved role groups to provide sign-in admission, while LIAM/SCIM maps each group to its Nullify role. A separate SSO access group is also possible if your governance design requires it. Enterprise-app assignment alone does not link a Nullify account, activate workspace membership or update its stored role; complete the provisioning steps independently.

Preserve and test the approved setup and recovery administrators before changing assignment requirements. Verify an assigned ordinary user succeeds and an unassigned ordinary user is denied; Microsoft Global Administrators bypass the assignment requirement, so they are not a valid negative test. If this same enterprise application also serves an Azure DevOps connection, verify the approved ADO setup/reconnection flow after the change rather than assuming assignment changes cannot affect it.

## Replace roles on every membership change

Send the full desired role set using `PATCH /Users/{id}` relative to the displayed SCIM base URL. For an administrator moved to the viewer group:

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {"op": "replace", "path": "roles", "value": [{"value": "viewer"}]}
  ]
}
```

Nullify accepts exactly one recognized role, activates that role assignment and applies it to the stored workspace user. A role change does not reactivate a deactivated lifecycle state; restore `active: true` separately only after resolving the customer's access decision. SCIM does not assign teams: provision the approved team memberships separately through Nullify's access controls when the selected role uses team scope.

For removal from all access groups or an ambiguous assignment, deactivate and clear roles in one request:

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {"op": "replace", "path": "active", "value": false},
    {"op": "replace", "path": "roles", "value": []}
  ]
}
```

An empty role set leaves the record unactivated, even if the lifecycle is later set active. To restore access, send one approved role and `active: true`. Preserve two usable Microsoft workspace administrators; Nullify can reject a change that removes the last qualified administrator. Escalate that error and verify a replacement rather than reporting successful deprovisioning.

A request containing two roles or an unknown role receives `400` and leaves the previous assignment unchanged. Such a rejected request is **not** a completed revocation. Check every response, retry transport failures safely, read the user back, and alert on unresolved failures. Do not mark an identity-system task successful solely because it queued a request.

If a gallery connector is introduced later, Microsoft documents [assertive app-role replacement](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/customize-application-attributes#provisioning-a-role-to-a-scim-app). A single-role expression can choose unpredictably when multiple roles are assigned, and an additive mapping can leave removed roles behind. That future configuration requires its own compatibility and lifecycle validation; it is not available merely because the current app publishes roles.

## Verify before enforcing Microsoft sign-in

Test the actual production client configuration with an explicitly approved pilot roster before scaling it. Keep ordinary sign-in allowed during linking and provisioning, then complete the [Entra-only acceptance procedure](/configuration/account-and-teams/entra-sso-and-scim.md#require-microsoft-sign-in).

1. Create or reconcile one approved user for each role. Verify its exact Entra object ID, SCIM remote ID, stored role, activation and expected Microsoft access.
2. Move a test administrator to the viewer group. Verify the stored role changes and an existing Microsoft session and WebSocket lose administrator operations.
3. Remove a test member from all mapped groups and disable another source account. Verify deactivation, account-link admission and existing-session denial; keep the two recovery administrators available.
4. Test overlapping groups, an unknown role, a membership read failure, and a SCIM write failure. Confirm ambiguity deactivation works, errors are surfaced, and no failed request is reported as a completed revocation.
5. Restore a resolved single-role assignment. Verify the approved role, lifecycle, teams and access, then test credential revocation and cross-workspace requests are rejected.

Record the customer's actual group IDs, LIAM connection owner, mapping rules, synchronization frequency, observed revocation delay and escalation process. Group-driven provisioning is complete only after these customer-side settings and end-to-end results are verified; the API and this guide alone do not establish it.