Currently, our Organizational and Geographical roles are dynamic roles. If we mark these roles as Common Access, they will be excluded from future Role Discovery and Access Request recommendations.
Before proceeding with this approach, I want to understand:
What are the key benefits of declaring these dynamic roles as Common Access?
What are the potential disadvantages or risks, especially during future implementations or audits?
How might this decision impact role governance, role mining, and access request accuracy?
Are there any best practices or lessons learned from similar implementations?
Looking for inputs to help evaluate whether this is the right long‑term strategy.
When you declare certain automated roles as common access, you’re basically calling the accesses under these roles to be “common” for all, or birthright access.
As such, you’d ideally not want birthright access to be part of mining exercises you’re going to carry out for creating more specialized roles, or for finding further common access, say at a department or a LOS level.
To ensure anything you have classified as birthright does not skew your further mining, you can mark the role as common access. There are no risks or disadvantages to it that I can think of, but a lot of upside.
Thanks for the suggestion—this makes sense. I’ll also gather other perspectives to check if there are any long‑term disadvantages before finalizing the approach.
Honestly, I wouldn’t flag all of them. I would look at each role & decide.
Here’s how I would think about it. Common Access is meant for the kind of access everyone in a group just gets by default. Like every US employee getting Workday self-service, or every India employee getting the payroll portal. That’s true birthright. Flagging those is fine because they don’t add anything useful to future role mining, and you don’t want them showing up as recommendations in the Request Center either.
But not every org or geo role is that simple. Some of them carry access that could actually be useful later, when you start mining specialized roles by country, site, BU, or department. If you flag those too, you lose that signal. Your future role discovery ends up looking cleaner than reality, and that hurts you in later phases.
On the audit and governance side, don’t worry. The flag doesn’t change provisioning, certifications, or the audit trail. It only changes how Access Modeling and the Request Center treat the role.
One thing I would test in sandbox before rolling this out: per the SailPoint docs, the exclusion only applies to entitlements directly assigned to the role, not access coming through access profiles. Most dynamic roles are built with access profiles, so confirm the behavior first.
So my take: for each role, ask yourself, “is this just baseline access this population always gets, or could it still teach me something useful later?” If it’s the first, flag it. If it’s the second, leave it alone.
Thanks, this is really helpful and makes a lot of sense. I like the way you’ve framed it around true birthright vs roles that may still be valuable for future mining.
Second point – One thing I would test in sandbox before rolling this out: per the SailPoint docs, the exclusion only applies to entitlements directly assigned to the role, not access coming through access profiles. - I will test this point in the sandbox
Good question — this is more of a design decision than a technical one.
Marking dynamic org/geographical roles as Common Access can help reduce noise in role discovery and access request recommendations, especially if those roles are already broadly assigned and not really “decision points” for access.
The benefit I see is cleaner recommendations and less confusion for users, since these roles are more like baseline access rather than something users should request.
On the flip side, the risk is that you’re effectively taking them out of visibility in certain processes like role mining or recommendations. Over time, that could make it harder to reassess whether those roles still make sense or if they’ve grown beyond their intended scope.
From a governance perspective, it might also reduce scrutiny during reviews if they are treated as “always allowed” access.
Personally, I’ve seen teams treat these kinds of roles as baseline/birthright access and manage them separately, but still keep some periodic review in place to avoid drift.