Data models
System data model guide
Choose the identity data NIM collects, identify each record reliably, and define how records belong together.
Every system has a data model. It tells NIM how to interpret the data collected into the Vault, making that data available to filters, mappings, roles, and reporting.
Tables and columns
Choose the records and attributes NIM needs to collect from this system.
Understand data tables →Keys
Assign stable, unique identifiers so NIM can recognize each record and connect it to related data.
Understand keys →Relations
Model how records inside one system relate, such as employees, departments, and managers.
Understand relations →Build a data model in this orderDirect link to Build a data model in this order
- Choose tables to collect that contain the people, accounts, groups, or organizational data your workflow needs.
- Choose columns to collect, including the attributes you need for matching, filters, and provisioning.
- Assign primary keys using a stable identifier that uniquely identifies each row.
- Specify intra-system relations to connect related records within the system.
- Collect the system and review the result before building filters or mappings.
The three building blocksDirect link to The three building blocks
| Building block | Purpose | Example |
|---|---|---|
| Data tables | Define the records NIM collects from a system. | An HR connector provides employees, departments, and job_titles tables. |
| Keys | Identify a unique row and provide a reliable destination for relations. | employee_id uniquely identifies a record in employees. |
| Intra-system relations | Connect tables in the same system using their key values. | An employee’s department value points to the matching department record. |
These three parts describe data within one system. To connect data between different systems—for example, an HR employee to an Active Directory account—create inter-system relations after both system models are configured.
Make choices that remain reliableDirect link to Make choices that remain reliable
- Prefer identifiers that are stable and unique, such as a permanent employee ID or directory object ID. Do not use a display name, email address, or organizational unit unless it is guaranteed to stay unique and unchanged.
- Include the columns needed to join related data before configuring relations. A relation cannot work if its foreign-key column is not collected.
- Review automatically detected relations. Connector naming can suggest likely matches, but only you can confirm that the relationship represents your organization’s data.
- Recollect after changing tables, columns, keys, or relations so the Vault reflects the current model.
If a filter cannot find expected records or a relation item is unavailable, check the data model first: verify that the required tables and columns are collected, the key is correct, and the relation has been saved.
Next stepsDirect link to Next steps
Start the guided configuration at Configure a system’s data model. When the model is ready, use filters to select and shape identity data, then use mappings to apply supported changes to target systems.