I’ve been trying to understand how people approach access design in SailPoint, especially when deciding what should go into a role versus what should be requested separately.
From what I’ve seen, roles help simplify access and make things easier from a governance perspective. But at the same time, not all access seems suitable to be bundled into roles, especially when it comes to exceptions or less frequently used permissions.
In some cases, adding too much into roles can make them hard to maintain, while keeping too much outside roles can increase manual requests.
So I wanted to ask:
How do you usually decide what should be part of a role?
What kind of access do you prefer to keep request-based?
Do you follow any guidelines or patterns for this?
Just trying to understand how this is handled in real-world implementations.
In SailPoint Identity Security Cloud, roles as the basic access someone needs to just get their job done without extra requests. It can assigned as birthright based on assignment criteria.
If almost everyone in a team needs something, it makes sense to include it in a role.
But for rare, temporary, or sensitive access (like admin rights), it’s better to keep it request-based so there’s more control.
I also try not to pack too much into roles, because they can quickly become confusing and hard to manage.
A simple approach that works well is having a basic role and then letting users request extra access if needed.
And if something keeps getting requested again and again, that’s usually a sign it should become part of a role.
That’s a really clear way to look at it. I like the idea of keeping roles focused on the basic access and handling the rest through requests. It feels like a good balance between usability and control. The point about frequently requested access eventually becoming part of a role also makes a lot of sense — kind of like letting usage patterns guide the design.
With my experience of role mining, access bundled in a role is identified based on the team’s structure and what is required by everyone to estimate the risks.
Access which requires a review everytime or has prerequisites like a training completion review by owner then keep it apart from the role.
Usually role mining in my case is done with validating the access with the team managers or checking manager with strong certification fatigues.
Roles are primarily designed to avoid repeated requests for the same or similar access across users within the same department, function, or position. When a set of entitlements is commonly required (e.g., Finance analysts or HR users), it is more efficient to bundle that access into a role. This allows access to be granted during onboarding or role changes, instead of raising multiple requests each time, improving user experience and ensuring consistency.
Limited, individual, temporary, or user-specific access should remain request-based. Such access typically requires business justification, approvals, and stricter governance, specifically if it is sensitive or not needed by all users in a role. Keeping this access outside roles ensures better control, flexibility, and proper audit compliance.
From what I’ve seen in real implementations, the general rule of thumb is — if everyone in a job function needs it on day one, put it in a role. If it’s occasional, sensitive, or varies by person, keep it request-based.
So things like basic AD groups, standard app access, shared drives for a department — those go into roles. But elevated permissions, admin access, or anything that needs extra approval — keep those as standalone requestable entitlements.
One pattern that works well is separating birthright roles (what you get automatically when you join) from supplemental access (what you request on top). Keeps roles clean and maintainable.
The biggest mistake I see is over-bundling — trying to put everything into roles ends up creating role explosion where you have hundreds of roles that nobody understands anymore. Less is more with roles honestly!
I like how you’ve connected roles with improving user experience and consistency, especially during onboarding and role changes. It really highlights why bundling common access makes sense.
At the same time, keeping sensitive or temporary access request-based for better control and audit also feels like a practical balance.
Just curious, how do you usually handle cases where some access is needed by most users but not all — do you still include it in the role or keep it request-based?
The distinction between birthright roles and supplemental access makes a lot of sense, especially from a maintainability point of view. It keeps things clean without overloading roles.
The point about over-bundling leading to role explosion is something I’ve been trying to understand better — it’s easy to add more into roles but harder to manage them later.
Just curious, in your experience, how do you usually identify that a role is becoming too large or complex and needs to be simplified?
With my experience inputs of managers are compared with inputs of application owners as a second layer of approval for creation of roles . This would be one time process and helps to identify what access is getting into which role bundle.
Combining inputs from both managers and application owners makes a lot of sense, especially to balance business needs with technical and security considerations.
I can see how that initial validation helps in building more accurate and stable role bundles.
A practical way to look at it is to treat roles as the “default toolkit” someone needs to do their job from day one, without having to raise requests. In SailPoint Identity Security Cloud, this typically aligns well with birthright access driven by attributes like department, job title, or location.
If a permission is consistently required by most users in a specific function, it’s usually a good candidate for a role. That keeps onboarding smooth and reduces repetitive approvals. On the other hand, access that is infrequent, elevated, or carries higher risk—like administrative privileges or temporary project access—is better handled through request workflows so you maintain tighter control and visibility.
One thing I try to avoid is overloading roles. When roles become too large, they’re harder to understand, maintain, and certify. A cleaner model is to keep roles focused and minimal, then allow additional access through requests as needed.
A useful pattern I’ve seen work well is:
Define a solid baseline role (birthright access)
Layer on request-based access for anything beyond that
Also, if you notice the same access being requested repeatedly across users, that’s often a signal it probably belongs in a role instead of staying request-based.
I like the “default toolkit” analogy — it makes it easy to think about roles as something that should just enable users to get started without extra steps.
The baseline + layered access approach also feels very practical, especially to keep roles clean and avoid overloading them.
Also agree on using repeated requests as a signal — it seems like a good way to evolve the access model based on actual usage rather than assumptions.
In this case, we implemented a control table to manage and assign roles based on users’ job names.
SailPoint IdentityIQ assigns roles according to the control table. If a user’s job name doesn’t match any entry in the control table, access must be granted through a request-based process.
Using a control table for role assignment based on job names seems like a good way to standardize and automate access for common cases.
I also like how you’re handling unmatched cases through request-based access — it keeps flexibility without overcomplicating the role design.
Just curious, how do you handle situations where job names are not very consistent or change over time? Does that impact the control table maintenance?