Salesforce OOTB Provisioning Behavior on Modify

Hi everyone,

We’re currently working with the Salesforce connector in SailPoint IdentityNow and would appreciate some insights.

Our use case involves multiple Access Profiles (APs), each combining various entitlements like Permission Set Groups (PSGs), Managed Packages (MPs), and Roles. For example:

  • AP1 = Role1 + PSG1 + MP1
  • AP2 = Role1 + PSG1 + PSG2 + MP1

As you can see, AP1 and AP2 share some entitlements but also include unique elements.

Our goal is to support account modification on AP access request approvals, ensuring the resulting entitlements are correctly applied — ideally as a union of required access without duplication or conflict.

We’re looking to understand:

  • What is the out-of-the-box (OOTB) behavior of the Salesforce connector in this scenario?
  • How are overlapping vs. unique entitlements handled when provisioning or modifying an account?

Appreciate any guidance or experience you could share.

I don’t see any problem user will have both AP1 and AP2 and will have Role1+PSG1+MP1+PSG2

Just to let you know if both AP have different role and you will see only the AP will is added later .

Thank you for the response @vishal_kejriwal1

I had a quick follow-up question.

How would the behavior vary if the Access Profile (AP) composition changes to the following structure:

Scenario 1:

  • AP1 = Profile1 + Role1 + PSG1 + MP1
  • AP2 = Profile2 + Role2 + PSG1 + PSG2 + MP1

In this case, there are still shared entitlements (PSG1 and MP1), but now the Profile and Role differ across APs.

Scenario 2:

  • AP1 = Profile1 + Role1 + PSG1 + MP1
  • AP2 = Profile2 + Role1 + PSG1 + PSG2 + MP1

In this case, there are still shared entitlements (Role1, PSG1 and MP1), but now only the Profile differ across APs.

Scenario 3:

  • AP1 = Profile1 + Role1 + PSG1 + MP1
  • AP2 = Profile1 + Role2 + PSG1 + PSG2 + MP1

In this case, there are still shared entitlements (Profile1, PSG1 and MP1), but now only the Role differ across APs.

Would this difference in Profile and Role impact how the Salesforce connector performs during a MODIFY operation

User can have only one profile and role at a time . Though profile and role are entitlement but they are single valued attribute .

User will have the latest role and profile with all other entitlements .

1 Like

@vishal_kejriwal1

Out of the box, does ISC handle this scenario, or is it correct to assume that a BeforeProvisioning rule is required to support such logic?

If a BP rule is indeed necessary, how can we bring both the currently provisioned Access Profiles and the Access Profile composition present on the target source user account into the rule context given that the requested Access Profile is already present in the provisioning plan?

User can have only one profile and role at a time . Though profile and role are entitlement but they are single valued attribute .

This is Salesforce application property , so you can’t change this one even if you write any rule

That makes sense, thank you.

If a user already has AP1 (Profile1 + Role1 + PSG1 + MP1) and then requests AP2 (Profile2 + Role1 + PSG1 + PSG2 + MP1), how does ISC handle this scenario?

Since Salesforce only allows a single profile per user, we need to remove Profile1 before assigning Profile2 to avoid conflicts.

I understand this can be handled using a BeforeProvisioning rule, but how do we bring the current AP1 composition (already provisioned to the identity) into the rule context?

From what I’ve seen in other forum posts, using the REMOVE_ENTITLEMENT action inside a rule on a multi-valued attribute (like permissionSets or permissionSetGroups) can wipe out all values, not just the one we want to remove.

In this specific example, our intent is to:

Remove only Profile1

Retain Role1, PSG1, and MP1

Add Profile2 and PSG2

Is there a way within the rule to selectively remove or append values to specific entitlement types (Profile, Role, PSGs, etc.) without disrupting other parts of the existing AP composition that are intentionally reused?

You don’t have to write any rule , ISC will take care of this assignment . I would recommend you to test this out . it will work with any additional rule.

I’ll test and update soon, thank you