I am experiencing an issue where Separation of Duties (SoD) warnings are not appearing during the Access Request and Approval process, even though the policy is active and violations are correctly identified in Search afterwards.
Environment & Scenario:
Policy Setup: I have an access-based SoD policy configured between Entitlement A and Entitlement B. The state is set to ENFORCED.
Step 1: I requested Entitlement A for an identity via the Request Center. It was approved and successfully provisioned.
Step 2: After provisioning was complete, I requested Entitlement B for the same identity.
The Issue: * During the request submission, there was no warning icon or notification regarding an SoD violation.
During the approval process, the approver (Reviewer) did not see any âReview Policyâ button or warning indicator.
Post-Provisioning: Once Entitlement B was provisioned, I checked the Search menu and the identity was correctly flagged as a policy violator.
What Iâve Checked:
The SoD policy is definitely Enabled.
The Entitlements are correctly mapped in the policy criteria.
Identity indexing seems fine since Search picks up the violation after the fact.
Question: Why is the Preventative SoD check failing to trigger during the request and approval stages? Is there a specific Global Setting or a background task (like Identity Refresh or specific indexing) that must be completed for real-time detection to work?
I would appreciate any insights or advice on what might be misconfigured.
Has this functionality ever worked in the desired way?
I ask this because, according to SailPoint documentation, the Violation Owner (which would be responsible for receiving the violation) currently has a predominantly informational role.
The documentation also states that the Violation Owner will be assigned to remediations and violations when this feature becomes available, as described in the following excerpt:
âWill be assigned to all remediations and violations when this feature becomes available.â
In this scenario, an alternative approach would be to configure a Governance Group or a specific identity as an approver in one of the approval levels. To keep governance aligned, the recommended approach would be to set the Violation Owner as a Governance Group and configure the same group at one of the approval levels.
We were not expecting the access request to be blocked.
However, at a minimum, we expected a warning to be displayed during the access request stage.
Currently, no warning is shown at all.
Even though the SoD policy is configured as Enforced, the policy does not appear to function during access requests. At this point, SoD policies seem to be effective only for identifying violations through search queries, not for surfacing warnings or enforcement during the request process.
Preventative SoD is supposed to show a warning icon + âReview Policyâ to the reviewer before approval. If you see nothing during the request/approval flow but Search flags the violation later, then the preventative SoD check isnât running or isnât returning results.
SoD rules are defined at the entitlement level. If you request a role or access profile, ISC will only flag it if that role/access profile introduces a conflict with other entitlements the user already has. It wonât detect conflicts that exist inside the same role/access profileâs access list. So a single role that contains both conflicting entitlements wonât trigger an SoD warning by itself.
In your scenario Entitlement A provisioned, then Entitlement B requested, if A is definitely showing as current access in ISC at the time you request B and you still donât get a warning, that points to a tenant-level configuration issue. Can you try SoD Violations API to prove whether the preventative SoD engine can see the conflict at request time, even if the UI isnât showing warnings. If not then, next step is to open a SailPoint Support case and include a couple request IDs.
The tenant you are testing upon, does that have ARM/ARM SOD subscribed ?
If yes than reach out to support to get ARM_SOD FF enabled.
Now, to your expectation:
When you raise a request will it show violation while requesting â NO, SOD is checked post the request is submitted so any violation are to be shown to the approver/requester once the SOD validation stage is passed on the access request.
Also, please ensure you have created a SOD policy and enabled the same and not a General Policy, as general policy violations does adhere to warnings which are expected in this scenario.
Does it block the request now? I have set up an SoD and tried requesting entitlements where no approver is requiered. What happens is that i see a warning in the request center, but after a small time period when I refresh the page it says that the access was approved.