Is it possible to assign a workgroup as a Policy Rule Owner in an SOD Policy?

[acgsneddon (Ashley Sneddon)]

Which IIQ version are you inquiring about?

8.4p2

Please share any images or screenshots, if relevant.

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

Hi all,

I’m working with IdentityIQ 8.4 and have run into an issue while configuring Separation of Duties (SoD) policies.

I understand that at the policy level you can assign a Policy Owner and a Policy Violation Owner, and these can be either an identity or a workgroup (as documented in the IIQ 8.4 Policy Management guide). However, when I try to assign a workgroup as the Policy Violation Owner for an individual SOD rule, the value does not persist — it saves as “None”.

From what I can tell, rule‑level Policy Violation Owners appear to support only identities, the manager of the violating user, or a rule that selects an identity. But I want to confirm whether that limitation is intentional and documented, or if there is a supported method to assign a workgroup specifically at the rule level.

My questions:

1. Is it technically possible in IdentityIQ 8.4 to assign a workgroup as the Policy Violation Owner for a specific SOD policy rule?

2. If not, are there recommended approaches or best practices for handling rule‑level ownership by groups, such as functional identities or owner‑selection rules?

Any guidance, documentation references, or examples would be greatly appreciated.

Thanks!

[aleksander_jachowicz]

Have you tried updating that in debug and saving it manually?

Not suggesting as a solution but to see if maybe it’s a GUI thing.

It should be possible imho.

[Peddapolu (Venkateswar Rao Peddapolu)]

Hi @acgsneddon That is not a limitation, as you showed in the screenshot, you didn’t select the Identity radio button. It selected the None radio button, which is why it’s storing None on the policy violation owner. Select the Identity radio button, and it will save the workgroups.

Thanks,

PVR.

[neel193 (Neelmadhav Panda)]

@acgsneddon Which policy are you testing? I just tried it in Role SOD and am able to set the workgroup as owner.

[acgsneddon (Ashley Sneddon)]

Hi all, thank you for your responses. I tested your suggestions in our lower environment and was able to successfully update the rule owner through the UI. However, when I tried the same steps in our Production environment, any attempt to assign a workgroup as the rule owner reverts back to “None” after saving and reopening the policy rule.

This makes me think the issue may be linked to a configuration difference between environments, although I haven’t yet identified what that might be. My next step is to test whether the update persists if I make the change directly through Debug.

Thanks again for your help so far.

[neel193 (Neelmadhav Panda)]

@acgsneddon In one of my past projects, we have written a rule runner task to set the email settings to send to a file and we use to run it every hour. So any change made to the settings will be reverted to Send to File, based on the task.

You might want to check if you have a similar task or plugin to restrict the policy violation ownership in UI.

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

[acgsneddon (Ashley Sneddon)]

Hi all,

Following further investigation into this issue, I wanted to share my findings and ask whether the reasoning appears sound, or if anyone else has encountered the same behaviour.

The Issue:
When editing an individual SOD rule (SODConstraint) within a Toxic Combination policy in IdentityIQ 8.4, selecting a workgroup as the Policy Violation Owner does not persist — after saving, the value reverts to “None”. This occurs consistently in Production but does not reproduce in lower environments.

What I’ve Found:

The official documentation (Defining Policies - SailPoint IdentityIQ) only lists three valid options for the rule-level violation owner: a specific identity, the violating user’s manager, or a rule. Workgroup is not mentioned — despite being explicitly supported for the Policy Owner field on the same page.

The UI suggest field returns workgroups because they share the spt_identity table with regular identities, so it appears you can select one. However, the backend validation silently discards the workgroup reference on save, writing None to the violation_owner_type column. This appears to be by design, not a bug.

The database confirms this pattern. Across all our SOD policies, the violation_owner_type column only ever contains Identity, Manager, or None — never Workgroup.

The difference between Production and lower environments is likely due to patch-level differences (Production may be on a newer patch with tighter validation) or, as suggested by @neel193 , a scheduled task or plugin that resets the configuration. I’ve checked for rule-runner tasks but haven’t found one that explicitly targets violation ownership.

The Suggested Workaround:
For anyone needing group-based ownership at the SOD rule level, the supported approach is to use a PolicyOwner Rule that returns the desired workgroup. For example:

import sailpoint.object.Identity;

Identity workgroup = context.getObjectByName(Identity.class, "Your Workgroup Name");

return (workgroup != null) ? workgroup : policy.getOwner();

Set the rule-level violation owner to Rule and select this rule. The violation work item routing will then honour the workgroup, including distributing work items to its members.

Can anyone confirm:

• Is this a known product limitation / by-design behaviour in IIQ 8.4?
• Has anyone successfully persisted a workgroup as a rule-level violation owner via XML import (bypassing the UI), and if so, does it function correctly at runtime?
• Has SailPoint documented this distinction in any KB article or release note that I may have missed?
• Any input from those who have dealt with this would be appreciated. Happy to share more detail on what we’ve found if useful.

Many thanks

[neel193 (Neelmadhav Panda)]

@acgsneddon Could you please also confirm if you have any Global Work Item Forwarding rule configured?

[acgsneddon (Ashley Sneddon)]

Where would the find the Work Item Rules in the screenshot?

[neel193 (Neelmadhav Panda)]

Global Settings → IdentityIQ Configuration → WorkItem

[acgsneddon (Ashley Sneddon)]

We do have a Global work item forwarding rule assigned.

[neel193 (Neelmadhav Panda)]

It’s very unlikely that this rule may cause issue as your owner reverting back from workgroup to none, as soon as you save it. even without running identity refresh.

i tried it again and i can see workgroups can be set as owner from the dropdown. I am suspecting it could be some environment specific issue or cache which is blocking it.