Is anyone actually provisioning access to Salesforce?

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Is anyone actually provisioning access to Salesforce from ISC? If so, how are you handling the order-of-operations challenges posed by PermissionSets, PermissionSetGroups, and PermissionSetLicenses?

We built a SailPoint Workflow to handle access removal for individually-assigned entitlements to ensure they’re removed in the correct order (first PermissionSets, then PermissionSetGroups, then PermissionSetLicenses, and then everything else), but this only works on termination/deactivation for individually-assigned (or manually assigned within Salesforce) entitlements. For role removals (on termination or on job changes), there’s no way we can find to ensure that we are removing entitlements in the correct order.

How are you handling this?

I see multiple posts about this over the past 5 years (including from IIQ users), but no follow-up to share resolutions:

  1. Salesforce : Entitlement Priority (PermissionSetLicence and PermissionSet)
  2. Potential bug in the Salesforce direct connector (8.1p2+)
2

If you were using IIQ, I would say use a BeforeProvisioning Rule to remove the PermissionSet (and other secondary provisioned items) on the create/remove and store it as a plan attribute, then in the AfterProvisioning, check that the provisioning succeeded and if so, provision the PermissionSet in the AfterProvisioning Rule and update the returned plan. This is how AD OU moves have had to be handled for as long as I can recall.

For ISC, are you removing all or just some of them? Can you use a customizer to handle them?