We need to change our correlation rule from userPrincipalName to a new attribute in Active Directory.
I’d like to understand the best approach for making this change in a Production tenant while minimizing the risk of impacting existing account correlations.
What are the recommended steps?
Do you typically update the correlation configuration and perform an unoptimized aggregation to allow accounts to be re-correlated?
Are there any specific precautions or best practices to avoid creating duplicate links or worse remove links?
When changing the correlation attribute in a Production tenant, I’d recommend treating it as a planned migration rather than just a configuration change.
Some best practices that have worked well are:
Ensure the new AD attribute is populated, unique, and immutable for all existing accounts before updating the correlation configuration.
Validate the correlation logic in a non-production environment first, using representative data if possible.
Export or document the current source configuration so you have a rollback point.
After updating the correlation configuration, run an unoptimized account aggregation. This forces ISC to re-evaluate all existing accounts using the new correlation rule.
Once the aggregation completes, verify a sample of identities to confirm accounts are still correctly correlated before resuming any provisioning or governance activities.
If any accounts fail to correlate, resolve the underlying attribute values before proceeding, rather than manually linking accounts unless absolutely necessary.
Following these steps minimizes the risk of orphaned accounts, duplicate account links, or unexpected correlation changes in Production.
Hello Torry. @ssowmya567 and @j_place covered the main points well. A couple of things I would add. Instead of swapping UPN out directly, add the new attribute as the first criteria and keep UPN as temporary fallback. ISC evaluates criteria in the configured order, so you get a safer transition. Once results look clean, remove UPN.
Use the Test option before saving, and confirm the new value is populated and unique on both sides. If the identity attribute is custom, it must be searchable and you will need to process all identities before aggregating.
Unoptimized aggregation via API (UI always runs optimized): POST /beta/sources/{sourceId}/load-accounts form-data: disableOptimization=true
Changing correlation config won’t create another account in AD. The real risks are accounts going uncorrelated or mis-correlating if the new value is blank, duplicated, or incorrect. Also keep in mind ISC has a default fallback that compares source Account Name with identity name when none of your configured criteria match.
Finally, check for manuallyCorrelated=true accounts (includes accounts provisioned through ISC). Those links are retained during unoptimized aggregation and won’t move based on the new criteria.