We are able to have IT roles detected for users upon identity refresh. However, we don’t see the business role getting detected when a user has the IT role. I see that some of the business roles have been configured to have assignment rules are defined such that the user has the IT role. Then the business role gets detected. However, when configuring business roles this way, it seems to be configuring them kind of backwards. Ideally, I want the assignment rule to act as it should - if a user has a certain attribute (not and IT role) then assign the business role.
Is there a configuration setting we’re missing somewhere which will allow a business role to be detected?
You’re correct in observing that IT Roles are detected automatically when the identity is refreshed, but Business Roles are not, even if configured to have IT Roles as “Required Roles”. This is actually by design in SailPoint IdentityIQ.
Here’s the explanation:
This is the expected behavior in IdentityIQ. IT Roles are designed to be automatically detected based on entitlements. Business Roles, however, are not automatically assigned unless one of the following methods is used:
Manual assignment
Access request
Assignment Rule based on identity attributes (e.g., department, title, location)
Using the presence of an IT Role in a Business Role’s assignment rule is not the intended approach. Assignment rules are meant to evaluate identity attributes, not existing role memberships.
Recommended Approach: To have Business Roles assigned automatically:
Avoid using IT Roles as conditions within assignment rules.
Configuration Note: There is no configuration setting in IdentityIQ that enables Business Roles to be assigned based on IT Role membership. This behavior aligns with the design principle that Business Roles should define access needs, not inherit from existing access.
@SuryaTejaD - Thank you. This is great info. I also had a separate post where someone provided feedback indicating that it would be bad design to have birth right roles that were also requestable. The suggestion being to create a new role that’s requestable instead of have a birthright role (assignment rule) that is also requestable." Can you tell me your opinion of standards to follow in that regard?
Regarding your follow-up — it’s generally not recommended to make a birthright role (assigned via assignment rule) also requestable. Doing so can lead to confusion, audit complexity, and potential provisioning conflicts.
Best Practice:
Keep birthright roles non-requestable and assigned solely via rules.
If similar access needs to be requestable, create a separate role with a clear name distinction.
This approach keeps your role design clean, auditable, and easier to manage. Hope this helps clarify the standard approach—happy to assist further if needed!