We have an integration with salesforce application using webservice connector which is a source for some users.
We have configured the account aggregation operation and the beforeOperation and AfterOperation Rule. Based on a criteria “SailPoint_sync_status” = “Sync Required” the accounts are aggregated into IIQ and the create onboard workflow is triggered for target application provisioning. Also, once the provisioning is completed an attribute named “SailPoint_sync_status” has to be updated back to salesforec as synced.
But later we observe some of the identities the account attributes have been removed from IIQ for the same user and only 3 attributes remains as below. We have verified no aggregation has run for this user and the account is salesforce is unchanged.
We are unable to identify what might be causing this update in IIQ account attribute.
It looks like after updating the “SailPoint_sync_status” during the verification (a single account aggregation is performed) the account is not aggregated anymore.
The 3 attributes are most likely the ones defined in the Update Provisioning Policy.
Can you check if the Identity Attribute and the Native Identity are the same?
Identity Attribute from the schema and the Native Identity from the provisioning plan to update the “SailPoint_sync_status” back to SalesForce.
Also check if the new “SailPoint_sync_status” value is also aggregated back (next to “Sync Required").
Is the attribute SailPoint_sync_status an identity attribute? It looks there is some action is occurring on the accounts, the attributes present in the Link is from the provisioning policy. Why are you performing Aggregation on certain accounts only?
We haven’t specifically coded for Single Account aggregation anywhere in the Onboard workflow. Although, the usual aggregation is scheduled to run every hour and should only pick up users marked as “SailPoint_sync_status” = “Sync Required”.
The only attribute in the Update Provisioning Policy is for “SailPoint_username__C” to encrypt the value as to not be visible in IIQ UI.
The schema Identity Attribute is “Id” and the plan for setting the “SailPoint_sync_status” back to salesforce has the same value as native identity as we are getting it from the link object.
No, only sync required value from salesforce is aggregated back. But when we update the value as Synced to SF, the application account in IIQ is also updated.
SailPoint_sync_status is not an Identity Attribute. The attribute “Id” is an identityAttribute for Salesforce.
We use the SailPoint_username to create the identity in IIQ with the username provided by SF.
And the aggregation is performed based on “SailPoint_sync_status” = “Sync Required” set by SF.
Something which we noticed recently. The Onboard workflow is completed and the synced status is sent to SF back and the workflow has ended. The Identity request looks like below:
After running the “Perform Identity request maintenance” task, the completion date is added to the request and the SF account attributes get removed and only the 3 attributes remain.
My advice would be to add “SailPoint_sync_status” as an attribute in the account schema and to aggregate SF when the “SailPoint_sync_status” = “Sync Required" OR “synced”
With not aggregation the "SailPoint_sync_status” = “synced”, the account looks to be removed (looks like option Detect deleted accounts is enabled in the aggregation task, which is a good thing). By allowing the “synced” accounts to be aggregated too, these will not be removed.
Creating Identities is based on the Display Attribute in the Schema, so this can be set to username. For the Identity Attribute in the schema I would advise to use id. Like:
Looks like we might have found a solution. Just wanted to post here.
The Identity Request created from the workflow had the salesforce application has the attributeRequest. We modified the plan to send application IIQ instead and so far the Salesforce account attributes are not being removed after running PIRM task.
