Topic starter
07/06/2026 8:16 pm
TL;DR: C1.ai explains that identity data often spans multiple systems, so Super Directory uses attribute mapping, fallback precedence and CEL expressions to keep user profiles and matching consistent when values such as job titles or email domains differ across apps. The governance issue is not only data quality but whether identity resolution remains reliable when authoritative attributes are fragmented.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “Take Full Control of Identity Data with Advanced Attribute Mapping in Super Directory”.
Key questions
Q: How should IAM teams handle attributes that exist in multiple source systems?
A: They should assign a single authoritative source for each important attribute, then define fallback sources only where business logic requires them.
Q: What is the risk of using automatic identity matching without attribute governance?
A: Automatic matching can create false joins or missed matches when email domains, usernames or identifiers differ across systems.
Q: When should teams use fallback mappings instead of manual fixes?
A: Use fallback mappings when the same attribute may legitimately live in more than one system and the source priority is stable enough to be documented.
Practitioner guidance
- Define attribute ownership by source system Document which system is authoritative for each identity attribute such as job title, manager, email and employee identifier.
- Set explicit fallback precedence rules For attributes that can exist in more than one app, define the order in which sources are checked and the conditions under which a fallback source should populate the profile.
- Review transformation logic as governed policy Treat CEL expressions and similar mapping rules as controlled logic with clear owners, change review and testing, especially when they generate alternate email formats or derived identifiers.
Bottom line: Identity data fragmentation creates governance risk when teams cannot tell which source should win for a given attribute.
What's in the full article
C1.ai's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact Super Directory mapping workflow for combining attributes from multiple apps into one profile
- The fallback mapping logic used when one source system does not contain the required attribute
- The CEL expression example that reconstructs a Microsoft-compatible email value
- The list of identifiers C1 uses for automatic user matching across connected applications
👉 Read C1.ai's article on advanced attribute mapping in Super Directory →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
07/06/2026 10:06 pm
Attribute mapping is now an identity governance control, not a data convenience feature. Once identity records span multiple systems, the quality of mapping logic determines whether the IAM programme can trust its own source data. That shifts attribute ownership, fallback order and transformation rules into governance territory, where they belong. The practitioner takeaway is that reconciliation logic should be treated as part of the control plane, not a back-office integration detail.
A question worth separating out:
Q: Why do transformed email values help identity matching in Microsoft environments?
A: They help when one system stores a primary email and another expects a different domain format for the same person. A controlled transformation can create a matching value from existing identity data, reducing misalignment without changing the underlying account identity.
👉 Read our full editorial: Advanced attribute mapping changes how identity data is governed
This post was modified 4 days ago by NHI Mgmt Group