# Violation when requesting entitlements that are part of Role SoD Policy

**URL:** <https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109>\
**Category:** IIQ Discussion and Questions\
**Tags:** roles, identityiq\
**Created:** [March 3, 2026, 4:31pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109 "2026-03-03T16:31:56Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![SReddy\_IAM](https://avatars.discourse-cdn.com/v4/letter/s/e9c0ed/32.png) [@SReddy\_IAM](https://developer.sailpoint.com/discuss/u/SReddy_IAM)\
**Post date:** [March 3, 2026, 4:31pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/1 "2026-03-03T16:31:56Z")

</div>

## Which IIQ version are you inquiring about?

_8.5_

## Share all details about your problem, including any error messages you may have received.

is there any OOTB way to detect Role SoD violations when access requests are submitted for underlying role entitlements?

For example -

I have an SoD policy for Role 1 (Role contains Entitlement A) and Role 2 (Role contains Entitlement B).

Role 1 is already assigned to my identity. When I submit an access request for Entitlement B (just the entitlement, not the role), is there a way to throw a violation?

---

<div class="post-metadata">

**Author:** ![abhi617](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/abhi617/32/34487_2.png) [@abhi617](https://developer.sailpoint.com/discuss/u/abhi617)\
**Post date:** [March 3, 2026, 9:51pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/2 "2026-03-03T21:51:03Z")

</div>

@SReddy_IAM there isn’t a clean out‑of‑the‑box way for a Role SoD policy to fire when you request just an underlying entitlement.

---

<div class="post-metadata">

**Author:** ![mandarsane](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mandarsane/32/35650_2.png) [@mandarsane](https://developer.sailpoint.com/discuss/u/mandarsane)\
**Post date:** [March 4, 2026, 10:11am UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/3 "2026-03-04T10:11:14Z")

</div>

Hi @SReddy_IAM ,

Try using advanced policy to see if it works

---

<div class="post-metadata">

**Author:** ![neel193](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/neel193/32/34038_2.png) [@neel193](https://developer.sailpoint.com/discuss/u/neel193)\
**Post date:** [March 4, 2026, 2:44pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/4 "2026-03-04T14:44:14Z")

</div>

@SReddy_IAM Have you tried Entitlement SOD with Ent A vs Ent B as conflicting entitlements?

---

<div class="post-metadata">

**Author:** ![tharshith](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/tharshith/32/34929_2.png) [@tharshith](https://developer.sailpoint.com/discuss/u/tharshith)\
**Post date:** [March 11, 2026, 1:41pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/5 "2026-03-11T13:41:41Z")

</div>

Hi @SReddy_IAM

OOTB feature as such is not available. However you can utilize Entitlement SOD Policy or Advanced Policy to tackle this usecase

---

<div class="post-metadata">

**Author:** ![kallajayaram](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/kallajayaram/32/35609_2.png) [@kallajayaram](https://developer.sailpoint.com/discuss/u/kallajayaram)\
**Post date:** [March 15, 2026, 6:07pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/6 "2026-03-15T18:07:07Z")

</div>

Hi @SReddy_IAM

OOTB in IdentityIQ, SoD policies are usually checked based on the access a user will have after the request is completed. If the policy is defined at the role level, the violation is normally detected when the conflicting roles are assigned.since the request is only for Entitlement B and not Role 2, the violation may not trigger if the SoD rule is defined only between Role 1 and Role 2.

---

<div class="post-metadata">

**Author:** ![r\_pragati](https://avatars.discourse-cdn.com/v4/letter/r/41988e/32.png) [@r\_pragati](https://developer.sailpoint.com/discuss/u/r_pragati)\
**Post date:** [March 15, 2026, 8:50pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/7 "2026-03-15T20:50:13Z")

</div>

Hi @SReddy_IAM you can create an Entitlement SoD policy.

---

<div class="post-metadata">

**Author:** ![neel193](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/neel193/32/34038_2.png) [@neel193](https://developer.sailpoint.com/discuss/u/neel193)\
**Post date:** [March 16, 2026, 1:41pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/8 "2026-03-16T13:41:27Z")

</div>

@SReddy_IAM I tested this with EntSOD and it is working for me. TestPrism1 and TestPrism2 are conflicting entitlements defined in policy. I assigned a role having TestPrism1 and tried assigning TestPrism2.. it is throwing the conflict.

 ![image](https://global.discourse-cdn.com/sailpoint/original/3X/4/c/4c7abd2abb8a848f720f7d37b24a100ca0ad3bd3.png)

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [May 15, 2026, 1:41pm UTC](https://developer.sailpoint.com/discuss/t/violation-when-requesting-entitlements-that-are-part-of-role-sod-policy/198109/9 "2026-05-15T13:41:43Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
