Yesterday I noticed, after running operations and making updates related to entitlement aggregations and manager correlations for a source, that I was seeing a different (and incorrect) result set when attempting to kick off an access item certification campaign shortly thereafter.
Essentially, what I had done was link an identity to another (service account) identity using identity profile and manager correlation updates. After seeing that this correlation was now correctly in place for the given source, I tried to start an access item certification campaign to get validation that the service account correlation had happened. I saw that it had happened, but the manager to whom this service account was linked was now no longer appearing as an identity to be validated by their own manager. There was no indication to me why this should be the case, other than perhaps some underlying data relationships that were not visible to me had changed.
I tried again today, and then noticed that with the same campaign template, the service account’s manager was properly re-appearing as an identity to be validated by its own manager. This seemed like a further indication that some sort of background identity processing task needed to run before the data could be “solid” again.
Has anyone else run into this, or established their own workaround protocols?
try to run your authoritative source aggregation too after applying these changes.
if it’s only isolated to one identity, remove the whole source under the account tab and re-aggregate the source again, hope it helps.
Hi, Thanks for the reply! I’m experiencing this behavior again and attempted these steps with no luck still. In fact, in removing an account from an identity, I was having trouble even getting the account to re-aggregate after that fact without using the /reset endpoint (I made a post about it here).
I’m not really sure where to go with this, it would be sub-optimal to need to wait for an unknown amount of time before being able to reliably expect manager correlations to be reflected in certification campaigns.
Thank you, I can see a comment from an expert ambassador about disabling optimization. that could also work.
or, how is the UAT for this source going, did you encounter the same problem in UAT?
also, is the campaign done via search? usually, when making changes to identity/aggregations, it doesn’t get reflected to search instantly, usually 24 hrs. As per support, they said something about indexing.
I did not have any different results doing a disabled optimization aggregation.
I did encounter it in our lower environment as well.
I think you’re right on the money that this is an indexing issue, and I had long forgotten that note in the docs search FAQ page… triggering a search “re-index” would probably be something a) well-suited to be available to trigger via API or otherwise (though I understand it’s probably a burdensome operation, at least for me right now, iterating on search-based certification campaign strategies could be much quicker and less confusing) and/or b) probably warned against more visibly in the search UI or when completing various operations that will not reflect in search for X amount of time.
Is there any visibility one can have into when / how the overnight indexing of search takes place?
Is there any discrete confirmation one can find to the effect of if a manager correlation has been successful? It seems to me the only way to fully confirm is to just see that the expected results occur in a certification campaign with managers as reviewers. The “Manager Name” and “Manager Display Name” identity properties can be mapped manually from a data source, but that doesn’t seem to confirm if the Manager Correlation logic for a given source is working for a given identity.
You can perform a search to see if the results have been updated. I have to do this often when I change something before running a process that relies on search to be updated.
I realized that a) I forgot about using the GET /public-identities endpoint as a means of more closely examining if a Manager Correlation has successfully happened (by looking at the manager: {} blob in the response, that is the tell if a Manager Correlation has successfully happened) and b) I fat-fingered my identity profile mapping for Manager Name (instead accidentally setting Manager Email), and Manager Name HAS to be set for a Manager Correlation to happen.
So a bit of the beginner blues. I really appreciate the input from everyone, thanks again! Definitely some solid pointers to keep in mind regardless of this particular issue.
