Single value attribute issue - SalesForce connector

Administration & Troubleshooting
, , ,
1

Hello,

We’ve been having a problem with the SalesForce connector, specifically with the attribute ProfileId, of type group. It’s a single value attribute on the application side, and has been configured as such in the source’s account schema.

The problem is that ISC doesn’t seem to know what to do with it. When it has 2 access requests for entitlements of that type it keeps going back and forth between the 2 instead of the newer request replacing the older one. It sounds so obvious to me that that should be the behaviour, but it somehow isn’t.

Can I accomplish that with a simple change in the source, in the case it’s misconfigured, or is it really a limitation of the platform?

Thanks.

2

Could you provide a bit more context about this issue? Specifically:

  1. Is ProfileId configured in the account schema or entitlement schema?
  2. Have you done an entitlement aggregation?
  3. What does the entitlement catalog look like for your SalesForce source?
  4. Is this only happening for entitlements on your SalesForce source?
  5. Were entitlement requests working as expected before adding the SalesForce source?
3

Hello!
SailPoint is doing this because ProfileID is a unique field, so the application only allows the user to have one at a time.
Most likely, two requests happening simultaneously cause SailPoint to apply the first one, and when it checks whether the user still has it, the second request has already been applied.

This happens because if the Access Request is of type Entitlement, it follows the ISC rule that Entitlements are sticky—meaning ISC will always try to apply the entitlement again if it detects that the user does not currently have it.

What you can do is change the Salesforce Access Request to work only with Access Profiles. With this approach, only the most recent Access Profile requested by the user will be applied to the account, and SailPoint will no longer attempt retries.

Also be careful when assigning ProfileID inside Roles, because Roles are also sticky.