# Requestable roles vs entitlements **URL:** \ **Category:** SHF Discussion and Questions\ **Tags:** identity-security-cloud\ **Created:** [April 24, 2026, 5:05am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358 "2026-04-24T05:05:23Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![asaxena](https://avatars.discourse-cdn.com/v4/letter/a/ea5d25/32.png) [@asaxena](https://developer.sailpoint.com/discuss/u/asaxena)\ **Post date:** [April 24, 2026, 5:05am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/1 "2026-04-24T05:05:23Z")
Currently in our ISC setup, for each new app that is onboarded, the ISC admins create 1 new role per requestable entitlement (so there is a 1:1 mapping between role and entitlement) and that role is made requestable. There is another role per app that assigns the user with the relevant app’s Entra SSO group. This role has an assignment criteria on it to assign the role automatically. For example, it the app name is Salesforce, all requestable roles will have a name that starts with “Salesforce -” and the role that assigns Entra group will have an assignment criteria that looks at Identity attribute → Assigned Roles → Starts with “Salesforce -”. It also has an assignment criteria that checks if the user has an Entra account. This way, the user automatically gets the SSO group of the application if they have requested for any entitlement of that application. I don’t like the design of 1:1 mapping between roles and entitlements. It is not the best use of SailPoint roles and they should not be setup in this way. So I am trying to change that by making entitlements requestable. But the challenge that is that I am unable to find a standard way to setup assignment criteria for the Entra SSO group role. A few options are: 1. Use Entitlement assignment criteria and enter all requestable entitlements in the criteria - the issue with this is that it is not scalable if there are let’s say 100 requestable entitlements in an application. 2. Use any other account attribute such as status - but that cannot be a standard and will differ per app. We might even not be able to find such an attribute for some apps. 3. Not make entitlements requestable and keep using roles but instead of having a separate role for Entra SSO group, add the SSO group entitlement in the same role as the requestable entitlement of the application. Using this, we won’t be able to use the criteria to make sure the user has an Entra account (and would need to assess any other implications of potentially adding them to an SSO group before the account is created). I am looking for suggestions and ideas on what do you think is the best way to deal with this based on how you might have setup requestable items in your solution. Thanks very much. ---
**Author:** ![Gxurav713](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/gxurav713/32/35922_2.png) [@Gxurav713](https://developer.sailpoint.com/discuss/u/Gxurav713)\ **Post date:** [April 24, 2026, 5:33am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/2 "2026-04-24T05:33:39Z")
Hi, I agree with your concern — 1:1 mapping between roles and entitlements doesn’t feel like the best use of roles, especially from a scalability and maintenance perspective. Making entitlements requestable sounds like a cleaner approach, but I can see the challenge around handling the SSO group assignment in a consistent way. One thought could be to decouple the SSO group logic slightly from individual entitlements and instead tie it to the application context. For example, if there’s a way to identify that a user has any access related to a specific application (even at a higher level like access profile or app-level grouping), that could be used to trigger the SSO group assignment. Maintaining a list of all entitlements in assignment criteria definitely doesn’t scale, so avoiding that seems like the right direction. Curious to know if others have handled this using access profiles or some kind of grouping rather than individual entitlements. Thanks for bringing this up — interesting design challenge. ---
**Author:** ![utkirjonkamiljanov](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/utkirjonkamiljanov/32/36695_2.png) [@utkirjonkamiljanov](https://developer.sailpoint.com/discuss/u/utkirjonkamiljanov)\ **Post date:** [April 24, 2026, 5:46am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/3 "2026-04-24T05:46:49Z")
> [@asaxena](#): > > Currently in our ISC setup, for each new app that is onboarded, the ISC admins create 1 new role per requestable entitlement (so there is a 1:1 mapping between role and entitlement) and that role is made requestable. There is another role per app that assigns the user with the relevant app’s Entra SSO group. This role has an assignment criteria on it to assign the role automatically. > > For example, it the app name is Salesforce, all requestable roles will have a name that starts with “Salesforce -” and the role that assigns Entra group will have an assignment criteria that looks at Identity attribute → Assigned Roles → Starts with “Salesforce -”. It also has an assignment criteria that checks if the user has an Entra account. > This way, the user automatically gets the SSO group of the application if they have requested for any entitlement of that application. > > I don’t like the design of 1:1 mapping between roles and entitlements. It is not the best use of SailPoint roles and they should not be setup in this way. So I am trying to change that by making entitlements requestable. > > But the challenge that is that I am unable to find a standard way to setup assignment criteria for the Entra SSO group role. A few options are: > > 1. Use Entitlement assignment criteria and enter all requestable entitlements in the criteria - the issue with this is that it is not scalable if there are let’s say 100 requestable entitlements in an application. > 2. Use any other account attribute such as status - but that cannot be a standard and will differ per app. We might even not be able to find such an attribute for some apps. > 3. Not make entitlements requestable and keep using roles but instead of having a separate role for Entra SSO group, add the SSO group entitlement in the same role as the requestable entitlement of the application. Using this, we won’t be able to use the criteria to make sure the user has an Entra account (and would need to assess any other implications of potentially adding them to an SSO group before the account is created). > > I am looking for suggestions and ideas on what do you think is the best way to deal with this based on how you might have setup requestable items in your solution. Thanks very much. 1:1 role-to-entitlement mapping is definitely too much overhead. For the SSO group assignment challenge, an approach was shared in this thread that I think sounds very similar to your use case, SSO entitlement nested in a role with assignment criteria based on the entitlements from the app: > [@Should I use access profiles or roles?](https://developer.sailpoint.com/discuss/t/should-i-use-access-profiles-or-roles/65046): > > Hello everyone, I’m building a role model from entitlements to allow users to request access, but I’m not sure whether I should use access profiles or roles to define the access for the sources. The only differences I see are: Roles can contain access profiles Access profiles can be requested via applications (which can allow finer management to define approvers) Roles can be assigned via automatic assignments Access profiles are discoverable and roles are not discoverable What is the state … ---
**Author:** ![asaxena](https://avatars.discourse-cdn.com/v4/letter/a/ea5d25/32.png) [@asaxena](https://developer.sailpoint.com/discuss/u/asaxena)\ **Post date:** [April 29, 2026, 1:39am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/4 "2026-04-29T01:39:14Z")
Thanks @utkirjonkamiljanov . This is one of the options but as I mentioned in the original post, it doesn’t scale well if an application has a lot of entitlements. It might be difficult to manually add all of them in the assignment criteria and if there are new entitlements in the future, we need to keep make sure the assignment criteria is up to date. ---
**Author:** ![j\_place](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/j_place/32/19181_2.png) [@j\_place](https://developer.sailpoint.com/discuss/u/j_place)\ **Post date:** [April 29, 2026, 7:50am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/5 "2026-04-29T07:50:37Z")
Hi @asaxena Throwing this out there un-tested as-is: Potentially you can mark one of the source attributes as an Entitlement (with an associated Entitlement Type where necessary for clarity) to indicate that the Identity has an account on that source and then add it to the SSO Role criteria. Eg. In Salesforce there is a userType attribute. Make userType=Standard an Entitlement called (for instance) Salesforce - Standard User, then add to the SSO Role. For scaling up, I can see that each application would need the attribute identified on a case by case basis. ---
**Author:** ![j\_place](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/j_place/32/19181_2.png) [@j\_place](https://developer.sailpoint.com/discuss/u/j_place)\ **Post date:** [April 29, 2026, 8:11am UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/6 "2026-04-29T08:11:45Z")
Re-reading the OP; this is similar to your option 2, but it standardises the SSO Roles ---
**Author:** ![davidtrn](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/davidtrn/32/19752_2.png) [@davidtrn](https://developer.sailpoint.com/discuss/u/davidtrn)\ **Post date:** [April 29, 2026, 4:25pm UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/7 "2026-04-29T16:25:23Z")
Hello, I am mostly using your option 2 in my org. - For applications for which the account object has a status, then we have a single role that will grant the Entra group for SSO based on this. That covers most of our applications. ![image](https://global.discourse-cdn.com/sailpoint/original/3X/5/4/5436fc4ca7f8100d885363974dc2f2f114ad024c.png) Even if your application does not have an active attribute, you can rely on something else like : ![image](https://global.discourse-cdn.com/sailpoint/original/3X/6/9/69e6e6cae9fbd69ce186661c2c8c19e9959a7ae3.png) The logic being that if a user has an account on the source Adyen, then he should have access to the SSO. ---
**Author:** ![asaxena](https://avatars.discourse-cdn.com/v4/letter/a/ea5d25/32.png) [@asaxena](https://developer.sailpoint.com/discuss/u/asaxena)\ **Post date:** [May 25, 2026, 11:55pm UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/8 "2026-05-25T23:55:21Z")
Thanks for your response - unfortunately I did not get a chance to test this out but if someone else has, please do let us know on this post. ---
**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\ **Post date:** [July 24, 2026, 11:56pm UTC](https://developer.sailpoint.com/discuss/t/requestable-roles-vs-entitlements/205358/9 "2026-07-24T23:56:09Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.