Hi all,
I observed this behavior in ISC and want to confirm if it is expected.
I have one source with both human and machine/service accounts.
Initial config:
My understanding is that Human Account Correlation decides whether the account is linked to a human identity, while Machine Account Owner Mapping only sets the owner of the machine account.
So if the same owner/contact value, like email, is used for human correlation, a service account can be correlated to the human identity instead of only being owned by that identity.
Question:
Is this expected behavior in ISC?
Is the recommendation to keep human account correlation attributes separate from machine account owner mapping attributes?
Does any official SailPoint documentation state the reason behind this behavior?
Hello Sakshi, from what you have described, this does look like expected behavior.
Human account correlation and machine account owner mapping serve different purposes:
Account Correlation determines whether an account gets linked to a human identity. If an account satisfies one of the configured correlation criteria, ISC correlates it to that identity. (Assigning Source Accounts to Identities)
Machine Account Owner Mapping identifies the human owner responsible for a machine account. It doesn’t replace or override the normal account correlation process. (Configuring Machine Accounts)
In your first configuration, Account Username = Identity Work Email matched an existing identity, so the account was correlated to that human identity. The Service Account classification didn’t prevent that correlation from happening.
When you changed the correlation to Account Username = Identity Username, the service account no longer matched the human correlation criteria, so it stayed as a machine account with its own application identity.
I would recommend keeping the attributes used for human correlation separate from those used for machine owner mapping wherever possible. Using a unique account identifier for correlation and a separate owner/contact field for machine ownership helps avoid this kind of overlap.
Regarding documentation, there isn’t a single SailPoint page that spells out the processing order between correlation and machine classification explicitly. But the behavior is consistent with the official docs on both sides. SailPoint also acknowledges that machine accounts can end up correlated to human identities by providing the Human Accounts > Classified as Machine view, along with the option to update their correlation afterward. (Managing Machine Accounts)
For accounts that were already correlated before the config change, I would run a non-optimized aggregation, such as disableOptimization=true with the Load Accounts API, so ISC has a chance to reprocess the account data. Then review any remaining mis-correlated accounts from Human Accounts > Classified as Machine and update them using Actions > Update Correlation > Machine if needed
