I’m currently working on a Salesforce connector and have a requirement that I’m trying to address.
Salesforce aggregates permission sets (entitlement type: PermissionSet) and roles (entitlement type: Role). I created an Access Profile that encapsulates both permission sets and roles, and then tied it to a SailPoint Role. This setup is working as expected.
Separately, we also have permission sets for “Authority Level” that are not part of the Access Profile and thus not tied to a Sailpoint Role. These are configured as standalone, requestable entitlements.
Here’s the challenge:
When an access request for an “Authority Level” permission set is approved and provisioned, the user’s Salesforce Role should be updated accordingly (for example, from User to Admin).
To achieve this, I implemented a Before Provisioning Rule, and it does update the role correctly. However, since the User Salesforce Role is included in the SailPoint Role, SailPoint reverts the role back to User after provisioning. As a result, the account briefly switches to Admin and then immediately back to User.
I tried removing the Salesforce Role from the SailPoint Role, which resolved the issue (the role stayed as Admin). However, this introduces another challenge: I would now need to provision Salesforce Roles outside of the SailPoint Role, which impacts over 1,000+ accounts.
Does anyone have suggestions on how to prevent SailPoint from reverting the role while still keeping Salesforce Role management within the SailPoint Role structure?
Hello Ibrahim, I think the issue here is that SailPoint is getting two different instructions for the same thing. Your SailPoint Role is still granting Salesforce Role = User, but the BP Rule changes it to Admin. That creates a conflict, and ISC can reapply the role-granted User value later.
Also, Salesforce Role is single valued, so User and Admin cannot both exist on the same account. It is better to model Salesforce Role directly in the access model instead of overriding it in a rule.
Here is what I would do:
Remove the Salesforce Role entitlement from the common SailPoint Role.
Create separate access profiles for each Salesforce Role:
Salesforce Role - User
Salesforce Role - Admin
When a user gets Admin Authority Level, grant:
Admin permission set
Salesforce Role = Admin
When a user gets User Authority Level, grant:
User permission set
Salesforce Role = User
After this change, SailPoint has only one clear instruction for each user, so no Before Provisioning Rule is needed. For the existing 1,000+ users, do a one time cleanup after the new model is in place. You can use Apply Changes to recalculate access, or use the access request API if you want more control over the bulk migration.
Hey Harish,
Thanks for the reply.
Yeah, that was my initial thought too. Let me simplify it a bit.
In our setup, Salesforce roles more or less match our SailPoint roles (which are based on job titles). But it’s not just simple roles like “User” or “Admin” — we’ve got 50+ roles like Teller, Senior Teller, Banker, etc.
The idea is to automatically assign:
The right Salesforce role, and
The related permission sets
based on someone’s job title. So, for example, if someone is a Banker, they get the Banker role in Salesforce plus all the permission sets tied to it.
The problem comes in when someone requests elevated access, like:
“Authority Level: Admin” (permission set, not a role), or
“Authority Level: Org Admin”
If that gets approved, the expectation is that their access basically shifts from something like Banker to Admin. That doesn’t really fit cleanly with the current role-based setup.
One option is to stop assigning Salesforce roles through SailPoint roles. That would make handling these “Authority Level” permission set requests easier. But then the question is—how do we still automate all the normal role assignments like Teller, Senior Teller, Banker, etc.?
So yeah, the challenge is:
keeping automation for standard roles
while still allowing flexible elevated access when needed