Questions regarding new roles on users with existing entitlements on source system

Hello Everyone,

I have a quick question regarding how Roles work under the hood with existing users being added to a new role with an access profile attached.

The specifics are as follows:

Onboarding a Salesforce integration with the onboarding of users handled by a script that adds the users automatically to an AD group “A”.

I have created a role that uses the assignment of AD Group “A” as a criteria to provision a read-only entitlement which forces account creation to Salesforce source. The entitlement specifically sets the profileId to read-only on the Salesforce side which is a field that only allows a single selection.

It gets replaced by their true role manually by our admins on the Salesforce side.

Were I to enable the access policy tied to the role would that automatically provision that read only role to everyone in the role? What if they have an existing account on the source?

Further question, if a user gets created with the read only role successfully & our admins change it to a different profileID then aggregate. They will be in a state where they are in the are in the role but not have the entitlement tied to the access profile. Will this force push that read only again?

Thanks for your time.

1 Like

Hi @tylarroy,

Since your IDN role is tied to the Read-only SF profile, IDN would always try to assign the SF Profile to the user satisfying the role criteria (users holding the AD group A). This applies for existing and new users.

As the SF Profile is a single valued attribute, this would create a conflict if someone manually modifies it from the SF side. This can happen when you initially create the role and enable it as it will revert all the matching users’ SF Profile ID to the read-only profile that you specify in the IDN role.

So, using a role might not best fit you here. You may want to look into the possibility of using a workflow (with a provisioning completed trigger for the AD group or a search criteria to trigger the WF) and calling the HTTP operation to creation SF accounts.

1 Like

Thanks,

I suspected this was the case & noticed the behavior in my dev environment. Looks like if I were to use a role the only way to have it work would be to have them removed from said role after an aggregation by nature of it not meeting the criteria (e.g. having a long list of criteria saying if they are in this profileId they don’t belong in the role.)

I will look into the workflow portion.

Thanks for your help.

1 Like