Schema mapping is the quiet step during identity discovery that decides who reviews access and whether an approval can be automated at all. Why? Because no single system holds the full picture of access. HR knows job title, department, and location. AD and Entra hold accounts and group memberships. The CMDB holds application ownership as a custom attribute. The target application itself holds the roles and entitlements that actually grant power. Schema mapping is how Hydden merges all of these into one model, so governance can act on the whole picture instead of a fragment.
Every system describes the same identity differently
Take a standard accounts payable application. One person shows up under a different name and shape in every system that touches them:
- AD calls the account sAMAccountName
- HR calls the account employee_number
- Oracle calls the account USER_ID
- Application ownership sits in an AD attribute named managedBy
- The manager relationship lives in an HR field named supervisor_id
- The entitlements the account holds are stored under the application's own role names and membership keys, which Hydden maps into its model so the access both resolves correctly and reads as something a reviewer can certify
As Hydden collects from each system, automated mapping reconciles these into one accurate, complete identity record. Without that step, the same person looks like six unrelated fragments.
Once the accounts and attributes are mapped, Hydden does the same for the access itself. It maps the application's own roles and entitlements into its model, so a review reflects what the actual access rights, not just which group a person sits in. That is the difference between certifying "this person is in the AP group" and certifying "this person can post and approve payments in the ERP."
With clean roles and attributes in one place, Hydden can then see patterns. When every Accounts Payable Clerk in Switzerland holds the same access, that shared pattern becomes an automated role-based policy. Automation can then take over an approve access to related applications where the account’s peer group members are the same. Access that fits the role Hydden generated for the account reads as normal, and anything outside it stands out as an exception worth a human's attention.
This only works because the data was mapped cleanly. When title, department, or location arrive sparse or unmapped, the policies never generate, and your reviewers are back to hand-checking thousands of entitlements one row at a time.
Mapping is how Hydden automates both the routing and the approval
Because application ownership and each account's manager are mapped, reviews route to the application's real owner or the user's real manager automatically, instead of landing in a shared mailbox while access quietly lingers. And because the entitlements themselves are mapped and analyzed, Hydden can auto-approve access that matches a person's peers. When every account on the finance team holds the same entitlements across the same applications, the routine cases clear themselves and reviewers spend their judgment on the exceptions.
Map it once, govern from it continously
It is easy to underestimate mapping, because bad mapping never throws an error. It produces empty reviews, missing roles, and misrouted approvals that all look fine until an audit proves otherwise - and by then the certification is already signed.
Schema mapping is a one-time setup, not a recurring chore. Get it right during discovery and you can confidently automate the work you do by hand today, turning access reviews from a quarterly slog into an automated, policy-driven process.
Frequently asked questions
What is schema mapping in identity security?
Schema mapping is the step during identity data collection where the fields from each system (HR, AD or Entra, the CMDB, and the target application itself) are translated into one consistent identity model. It reconciles the different names and structures each system uses so the same person, account, and entitlement line up. Without it, one identity shows up as disconnected fragments across every system.
Why does schema mapping matter for access reviews?
Access reviews, certifications, and approvals all read from the mapped data, so the quality of every review is decided at ingest. If mapping is wrong or incomplete, reviews can come back empty, roles can go missing, and approvals can route to the wrong person, none of which throws an error. Clean mapping is what lets a review reflect access that actually grants power, like "can post and approve payments in the ERP" rather than just "is in a group."
How does schema mapping enable automated access approvals?
Once accounts, application ownership, manager relationships, and entitlements are mapped into one model, Hydden can route reviews to an application's real owner or a user's real manager automatically. Because the entitlements are mapped and analyzed too, Hydden can auto-approve access that matches a person's peers, so the routine cases clear themselves and reviewers spend their judgment on the exceptions.
What happens when schema mapping is done poorly?
Bad mapping does not produce an error message. It quietly produces empty reviews, missing roles, and misrouted approvals that all look fine until an audit proves otherwise, and by then the certification is already signed.
What is the difference between source data and target application entitlements?
Source systems like AD, Entra, and HR imply access through group membership, but they do not show what that access actually permits inside an application. Hydden maps the target application's own roles and entitlements into its model, so a review reflects real, usable access rather than a source-side approximation.
Is schema mapping a one-time setup?
Yes. Schema mapping is configured once during the discovery phase, and every collection afterward lands clean, correlated data automatically. Getting it right up front is what turns access reviews from a manual, quarterly effort into an automated, policy-driven process.