Only allow 1 role for an Application Entitlement

Which IIQ version are you inquiring about?


Is this question regarding a custom connector? If so, please share relevant details below.

No, this question is not regarding a custom connector.

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

Some applications have an entitlement which is a single valued entitlement.

What would be a OOTB solution to have 1 value as default (which might be different based on department/function) and have managers request other values?

At a client/project we have implemented roles for each entitlement and set them as permitted on ‘birthright’-roles when multiple values are allowed. Problem here: no automatic assignment and when there is a possibility to request 2 roles.

– Remold

Perhaps you can create a Policy that creates a violation if a user would have two roles of this kind. The Policy must be enforced and it should not be allowed to submit a request with a violation - not sure if that is desirable, but that would be an option to implement this. So, when a new value is needed, the new value can be requested via a role and in the same request, the role representing the existing value must be removed.

An alternative option would be to detect a change to the entitlement in a Before Provisioning Rule and then create a plan to revoke the role for the old value immediately.

– Menno

Thanks @menno_pieters ,

I came to the same options, but this will not solve the initial assignment.

The first option is also not so user friendly. It is not possible to go a step back when the Policy Violation has been found, as the simulated provisioning is performed after the submit of the Access Request :frowning:

The Before Provisioning Rule option sounds like the best option.

An other option would be to create a new QuickLink to select the entitlement (select user → select Application → Select single entitlement) and have the workflow handle the revocation of the old entitlement/role. However this is not OOTB and extra instructions are needed for the end-users.

Too bad there is no real OOTB solution, as I see this issue for multiple applications:

  • Changing approval limit (expenses, insurance payout, …)
  • Profile templates (SalesForce Profiles)

Let me discuss the options with the client and have them decide the way forward.

– Remold

  1. Problem with Permitted Roles is, when you request them, There is no minimum and maximum number of roles can be selected. You can select all the Roles or no selection also allowed. We cannot control using OOTB. I wish there is min/max config for Permitted Roles.
  2. You can try using Policy Violation preferably Advanced Policy Violation.
  3. Role SOD Policy, make sure requester select remove operation of existing Role.
  4. Before Provisioning Rule, If user requests for Role/Entitlement, add one more remove attribute request operation for the existing entitlement/role for the same application. Just a couple of lines of code would do the magic here.

Creating Role for a single entitlement is not a good practice, I will try to avoid that.

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