What is Data Mapping in IAM?
Data mapping is an IT process in which data from one system is linked to corresponding fields in another system. It ensures that information transfers correctly and consistently between applications or databases, regardless of differences in field naming or format.
Where IT standards exist, systems can exchange data directly. Where a standard is absent or a vendor uses a proprietary format, data mapping must be configured first.
A Concrete Example
Consider a date of birth stored across two different databases:
Database A | Database B | |
|---|---|---|
Field name | birth_date | date_of_birth |
Format | 12-10-1998 | 12oct1998 |
The underlying information is identical. Data mapping defines the relationship between these two fields so that data moves accurately between systems despite the difference in format and labelling.
Other Types of Mapping in IT Systems
Not every form of mapping in IT involves data mapping. Two related but distinct types are:
Network and address mapping: converts technical network addresses from one format to another. A common example is Domain Name System (DNS) mapping, which translates domain names into IP addresses.
Function or process mapping: translates a broadly defined function or process into a specific system implementation. The same function, deployed across different systems, should consistently deliver comparable output.
Data Mapping in Identity and Access Management
Data mapping plays a central role in Identity and Access Management (IAM) environments. Most IAM platforms use source data to determine automatically which accounts and access rights each user should receive.
That source data typically comes from an HR application. Many organisations, however, draw from multiple source systems. A contractor management application or a student administration system in an educational institution are common examples. Each source system stores data in its own format, while the IAM platform must process all of it in a single, uniform way. Data mapping is therefore required.
Once accounts and access rights have been determined, that data must be passed on to target systems. These include directory services, identity providers, and business applications. Each target system has its own data requirements, making correct mapping between the IAM platform and each connected system essential.
How HelloID Handles Data Mapping
Within HelloID, data mapping occurs at two levels: source mapping and target mapping. The automated provisioning process that sits between them works as follows:
Source data is retrieved. An HR application or other source system provides personal data, contract details, role information, and department assignment for each user.
Business rules are applied. HelloID evaluates that data against configured business rules to determine the correct accounts and access rights. A sales employee might receive an Active Directory account, a Microsoft 365 licence [LINK: Microsoft 365 integration], and CRM access.
Target systems are configured. HelloID activates the relevant accounts and rights in each connected target system.
Changes are monitored. HelloID queries source systems one or more times per day. When a change is detected, business rules are re-evaluated and target systems are updated accordingly.
Departures are processed. When employment ends, HelloID revokes access rights automatically, preventing former employees from reaching sensitive data after leaving.
Mapping type | Direction | Purpose |
|---|---|---|
Source mapping | Source system → HelloID | Normalise and consolidate incoming identity data |
Target mapping | HelloID → Target system | Format and deliver account and access data to each connected system |
Source Mapping: From Source Systems to HelloID
Source mapping determines which fields from each source system are stored and used within HelloID. This includes personal data, employment relationships, management hierarchies, job roles, and department assignments.
Different HR systems structure this data differently. Organisations running multiple source systems must ensure that all incoming data is consolidated without ambiguity. HelloID supports this through its identity vault [LINK: HelloID identity vault], a centralised store of normalised identity data.
Source mapping also future-proofs your IAM environment. If your organisation moves to a new HR system, the existing source mapping ensures that incoming data is processed identically, keeping all downstream integrations intact without reconfiguration.
Administrators retain full control over which data is processed. The HelloID attribute mapper [LINK: HelloID attribute mapper] allows administrators to define precisely which fields from connected systems may be stored in the HelloID database, keeping the platform fully aligned with your organisation's privacy and security policy.
Target Mapping: From HelloID to Target Systems
Once HelloID has determined the correct accounts and access rights for a user, that data must reach each target system in the exact format it requires. HelloID handles this through connectors [LINK: HelloID connectors overview], with over 200 standard integrations available.
Each connector performs target mapping, translating HelloID data into the format expected by the target system. Connectors also include additional validation logic to ensure a reliable integration.
Each connector is built against the target system's published API. Tools4ever maintains connectors and updates them whenever a vendor changes their API, so capabilities can expand over time. Some vendor APIs initially support only basic account creation; as the API is extended, the connector is updated to support more detailed configuration directly from within HelloID.
Getting Started with Data Mapping in HelloID
Within HelloID, data mapping covers two flows: from source systems into HelloID, and from HelloID out to target systems.
For source mapping, see our introduction to mapping source data.
For target mapping, refer to the documentation for each individual connector, or our connectors we have ready to use.