Another Manager correlation post

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hey! I’ve seen somewhat similar posts around but have not spotted a solution to our situation yet.
We’ve been using Okta as our authoritative source for a while now.
Now we’re switching that around (so instead of HRIS->okta->IDN, the data would flow hris->idn->okta). For the most part, the migration’s gone without issues but seemingly the previously existing Manager Correlation on the Okta source is overriding the Manager Correlation on the HRIS source.
This means that if a user does NOT have the “manager” attribute filled in on Okta, they are not mapped to their manager correctly, despite having the relevant attribute on the HRIS.
One way I’ve managed to fix it is to:

  • navigate to the “accounts” tab for a problematic identity
  • Remove their Okta account
  • Aggregate the identities HRIS account - at this point the manager mapping is created
  • Run an unoptimised Okta aggregation, their Okta account is correlated again but manager correlation is not touched

The other way would be to write the manager attribute into Okta from IDN (since it has it from the HRIS) and then correlate from there but it seems like a roundabout way of doing things.

This occurs for new records that did not pre-exist in Okta as well. What I mean is - the record was imported from WD, IDN provisioned an Okta account and manager mapping is not present. I’m mentioning this because I’m considering resetting the Okta source and running another unoptimised aggregation but looking at how this currently works, I’m not convinced that this would solve the issue for new identities.

The HRIS identity profile is higher priority than Okta, I’ve ran unoptimised aggregations multiple times and I’ve both forced identity refresh and gone through the scheduled identity refresh with no luck. Manager correlation is configured correctly on the HRIS source. I’ve ran an export of the HRIS accounts to confirm the attribute is in the expected format and it is.

Is there some hidden “source authority” priority or manager correlation priority I’m missing?

2

Hi Marten,

This particular issue is beyond my understanding of the platform, but maybe another community member can assist. In the meantime, a session with Expert Services might be the best way to get your answer.

1 Like
3

One thing to add is that resetting our Okta source, followed by unoptimised aggregation on the HRIS source did fix the problem for all existing users. Re-aggregating all the Okta identities did not cause the issue occur again, but I’ve yet to confirm if this would eliminate the issue for new identities as well.
The above would suggest that it should, but that also doesn’t explain why it occurred for new identities in the first place.

Also thank you for the suggestion @colin_mckibben, I’ll consider it if I can’t find the answer through other means

6

Necroing this thread to mention that this issue was caused due to a bug with the beta endpoint for patching identity profiles I was using at the time, using the private cc/api/identity-profiles endpoint to update the identity profile priority fixed it. The beta endpoint would update the priority, but would be overwritten by any changes made via UI since that was using the private endpoint and the priorities of identity profiles were not synced between the two endpoints.