Notifications
Clear all
Topic starter
07/06/2026 8:16 pm
TL;DR: Identity data often spans multiple systems, and Super Directory can map attributes from different sources, apply fallback precedence, and use CEL expressions to correct mismatches such as Microsoft email domains, according to ConductorOne. The governance issue is not just data quality, but whether identity matching can stay reliable when attributes are fragmented across apps.
NHIMG editorial — based on content published by ConductorOne: Take Full Control of Identity Data with Advanced Attribute Mapping in Super Directory
Questions worth separating out
Q: How should IAM teams handle identity attributes that live across multiple apps?
A: Start by defining which system owns each critical attribute, then map that precedence into the directory so matching, provisioning, and reviews all use the same source hierarchy.
Q: When do fallback mappings improve identity governance?
A: Fallback mappings help when the same user population is distributed across different systems and no single app reliably holds every required field.
Q: What do security teams get wrong about derived identity attributes?
A: They often treat transformations as a technical shortcut instead of a policy choice.
Practitioner guidance
- Define source-of-truth precedence for critical attributes Document which system owns each attribute such as title, manager, email, and employee ID, then apply that precedence consistently across matching and provisioning flows.
- Separate employee and contractor fallback rules Build explicit fallback order for populations that are stored in different apps so the directory resolves the right value without manual intervention.
- Review every derived identity expression Keep CEL expressions limited to narrow matching or normalisation use cases and require identity owners to approve changes that alter how records are constructed.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Specific Super Directory configuration patterns for mapping attributes across multiple applications.
- The exact fallback-mapping logic used to resolve user records when one system lacks a value.
- CEL expression examples for constructing additional email values from existing usernames.
- Microsoft-specific matching behaviour that explains why @corp.com and @corp.onmicrosoft.com records can diverge.
👉 Read ConductorOne's blog on advanced attribute mapping in Super Directory →
Attribute mapping in identity data: what IAM teams need to fix?
Explore further
07/06/2026 10:06 pm
Attribute mapping is becoming an identity governance control, not a convenience feature. Once attributes are used to match users, route access, or trigger lifecycle workflows, the mapping logic becomes part of the control plane. If source selection is unclear, the directory is not just inaccurate, it is making governance decisions on unstable evidence. Practitioners should treat attribute precedence as a formal identity policy surface.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity data quality problems persist at the machine layer too.
A question worth separating out:
Q: How can organisations prevent email mismatches from breaking user matching?
A: Use additional email mappings when platforms store different domain formats for the same person, then validate that the derived address actually appears in the matching logic. In Microsoft-heavy environments, domain normalization can bridge common mismatches, but it should be tested as part of onboarding and reconciliation rather than left to chance.
👉 Read our full editorial: Advanced attribute mapping changes how identity data is governed
