We have manager correlation configured in our authoritative sources as following and they are working now without any issues.
Identity Attribute
Account Attribute
Employee Number
manager_employee_id
Now we want to use manager_email from our authoritative source instead of manager_employee_id for the correlation logic. so, we changed the manager correlation as this.
Identity Attribute
Account Attribute
Work Email
manager_email
After the change, when we aggregate the authoritative source, the new identities are having manager tagged only if both the authoritative source attributes (manager_employee_id and manager_email) are having values. The manager correlation is not working with only manager_email value.
Can anyone help us on this? Aren’t we supposed to change the manager correlation logic?
I tried to run “Aggregate source without optimisation” on authoritative source and it did not work. Our authoritative source is configured with “full Aggregation” always.
Here is what happened.
Initially the manager correlation logic is this: Identity Attribute - Account Attribute
Employee Number- manager_employee_id
When we aggregate the authoritative source, the identity created for that source account has been tagged with manager. (manager correlation was success). Please find the result.
Source Account
manager_employee_id
manager_email
Manager correlation success?
Source Account 1
108
Yes
Source Account 2
226
Yes
Source Account 3
1457
Yes
We changed the manager correlation logic to
Identity Attribute - Account Attribute
Work Email - manager_email
Now we aggregated the source without optimization and the source also has the following records as the input . The first 3 accounts which already got aggregated has the manager_email populated along with ,manager_employee_id now and next three accounts are only populated with manager_email and the following are the test results.
After we did the “Aggregate source without optimization” (We are doing through VS Code), we don’t see the manager tagged for the source accounts (4,5,6).
@Vijitha, To my understanding, you cannot fix the account correlation automatically on the source which already had another pre-existing correlation logic and user accounts were already aggregated and correlated. Rather what you need to do is perform a remove all accounts API on your source and then perform full account aggregation again so that your new correlation criteria on manager email is re-evaluated and changes are reflected rightly.
@Arshad, In production environment, Its not a wise decision to remove the accounts from source to complete the aggregation and correlation. This may cause unexpected issues that may disrupt their business. I’m sure there will be another solution without removing the accounts. Just my two cents.
@jkalle I am definitely with you on the point that this might not be the best solution on PROD systems . But these are workarounds to the unusual behavior of the tool.
And be rest assured, if you’re resetting the accounts on a source, they will not be propagated back to the actual end target application. We’re just resetting the accounts on source level on ISC side only. Which has no connection whatsoever with provisioning. Once you re-aggregate the source, correlation in ISC system is re-evaluated and fixed as needed. I have had this same experience on a staging environment and had to do this process to overcome the behavior mentioned by the author.
But definitely, SailPoint has to bring in more flexibility in terms of config changes and reflecting those changes on the tenant for such edge cases.
