Entra groups driving Nullify roles
For connecting the directory and the provisioning-only Entra application, start with Microsoft Entra ID SSO and SCIM.
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. 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. 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:
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 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 and restricting application access.
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:
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:
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. 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.
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.
Move a test administrator to the viewer group. Verify the stored role changes and an existing Microsoft session and WebSocket lose administrator operations.
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.
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.
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.
Last updated