Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.
Hi everyone,
I’ve been exploring different approaches to access design in SailPoint ISC and wanted to get some insights from others here.
In many implementations, I see two common approaches:
Designing access around business roles (aligned with job functions)
Designing access directly around application entitlements
Both approaches seem valid, but they come with different trade-offs.
For example:
Business roles make access easier to understand and manage from a governance perspective
Entitlement-based design provides more flexibility and granular control
However, in real-world scenarios:
Roles can become too broad or difficult to maintain over time
Entitlements can become complex and harder for users to interpret
What I Have Tried / Explored
I have been looking into both approaches through different learning scenarios:
Explored how business roles simplify access requests and improve usability
Looked into entitlement-based design for more precise access control
Compared how both approaches impact governance and user experience
However, I am still trying to understand how these approaches are balanced in real-world implementations.
My Question
I wanted to understand from others here:
How do you usually approach access design in your implementations?
Do you prefer business roles, entitlements, or a combination of both?
At what point does one approach start creating more challenges than benefits?
What I’m Trying to Understand
I’m mainly trying to understand whether:
One approach is generally preferred
Or a hybrid model is considered best practice in most cases
In my opinion, business roles also include entitlements, so what it appears that you are asking is for a design approach between attribute based access (often called RBAC) and Access Request (ARP). That will come down to how well you can define the jobs (what attributes are you receiving from the HR source) compared to what access they require.
Personally, I would recommend RBAC wherever possible, then ARP to complete the picture
That’s a really helpful way to frame it — especially the distinction between RBAC and ARP.
I agree that RBAC works well when job roles and attributes are clearly defined from the HR source. It definitely makes access more structured and easier to govern.
At the same time, I’ve seen cases where roles don’t fully capture all access needs, especially for exceptions or application-specific requirements, which is where ARP becomes important.
In your experience, how do you usually handle situations where RBAC starts becoming difficult to maintain due to frequent role changes or exceptions? Do you lean more towards refining roles or increasing reliance on ARP in those cases?
In practise, when RBAC starts to become hard to maintain I try to avoid over defining roles as this can/will lead to role explosion. Validate the underlying entitlement model and simplify. A Role should hold a significant number of people either as a total figure or as a percentage, and be broad strokes. The fine granularity of ARP should then be used to handle the exceptions
That makes a lot of sense, especially the point about avoiding role explosion.
I like the idea of keeping roles at a broader level and focusing on validating and simplifying the underlying entitlement model instead of over-defining roles. It seems like that helps maintain scalability over time.
Using ARP for exceptions also feels like a practical balance, rather than trying to force every edge case into RBAC.
so in the past i’ve created a Role based on Department that is automatically assigned with Entitlements like, shared Mailbox, Distribution Lists, Shared folders for the team/department and etc etc. Then i create Business Roles based on Job Function. 80 % captures this, other 20 % are loose Entitlements. Now i’ve started the same way, but then with Business Roles with a combination of Access Profiles and Entitlements if needed.
That’s a really interesting approach, especially combining department-based roles with business roles to cover different dimensions of access.
The 80/20 split you mentioned makes a lot of sense — capturing the majority through structured roles and leaving the remaining access as loose entitlements feels like a practical balance rather than over-engineering roles.
Your current approach using Business Roles with Access Profiles + Entitlements also seems more aligned with ISC design, especially from a request and governance perspective.
Thanks for sharing your experience — really helpful to understand how this works in practice.
Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.