16.3 Configuring Identity Attribute Mappings
Key Takeaways
Identity attributes are configured on gear icon > Global Settings > Identity Mappings; name, manager, email, firstname, and lastname are required by IdentityIQ.
Sources are checked in order from the top (the primary source), falling to the next source when a value is missing; a source can be an application attribute, an application rule, or a global rule.
Edit Mode controls UI edits: Read Only, Permanent (refresh does not overwrite), or Temporary (a new aggregated value overwrites).
Target mappings push an identity attribute to application accounts (attribute synchronization), triggered by direct edits or by refresh with Synchronize Attributes.
Mapping the same application attribute as both source and target creates a circular reference that changes values on every synchronization.
Configuring Identity Attribute Mappings
Objective 7.3 asks you to configure identity attribute mappings. Identity attributes such as department, location, manager, and employee number drive almost everything else: correlation, populations, role assignment, lifecycle events, policies, scopes, and certifications. The mapping defines where each value comes from, and optionally where it is pushed.
The Identity Mappings Page
Go to gear icon > Global Settings > Identity Mappings. The list shows each attribute, its Primary Source Mapping (the first source), and key Advanced Options. Add New Attribute creates one, and right-click deletes one. Deleting an attribute also deletes group factories that reference it.
Required attributes: IdentityIQ needs the identity ID (name), manager, email, firstname, and lastname to work correctly. Manager is also a system attribute configured for grouping.
For bot and RPA governance, identities have three standard attributes. Type has the defaults Employee, Contractor, External / Partner, RPA / Bots, and Service Account, and more can be added in XML. Version is the bot's software version. Administrator is the bot's owner and certifier, used instead of manager.
Creating or Editing an Attribute
- Attribute Name is the name used in rules and filters. Display Name is the UI label. You cannot reuse an existing identity attribute name for an extended attribute, and renaming can orphan previously aggregated values.
- Advanced Options:
| Option | Meaning |
|---|---|
| Attribute Type | String, or Identity (a drop-down of identities, used for owner-style attributes) |
| Edit Mode | Read Only (no UI edits), Permanent (UI edits are kept; refresh does not overwrite), or Temporary (UI edits are overwritten when aggregation brings a new, changed value) |
| Searchable | Filterable in searches. Needs a database column (section 2.3). The default is ten searchable attributes. |
| Multi-Valued | Stored as a list |
| Group Factory | Creates groups for analytics, such as groups by department |
| Value Change Rule / Value Change Workflow | Runs a rule or business process whenever aggregation detects a change to this attribute, for example to notify someone, require approval, or launch a certification |
| Sync with Workflow | Route this attribute's synchronization through a business process |
-
Source Mappings. Choose Add Source:
- Application Attribute: an application and one of its schema attributes.
- Application Rule: a rule that applies only to that application's accounts.
- Global Rule (all apps): a rule applied to every application that has the attribute.
Order the sources with the arrows. The top one is the primary source. When aggregation and refresh collect the attribute, IdentityIQ checks the primary source first and moves down the list until it finds a value.
-
Target Mappings (available on identity attributes, not on account attributes): Add Target with an application, the attribute on it, an optional transformation rule (for example, "Full" becomes 1), and Provision All Accounts. Without that option, someone is asked which of several accounts to update.
Attribute Synchronization
Synchronization pushes identity attribute changes, such as a name change from HR, to other systems. It is triggered in two ways:
- Direct edits to the identity in the UI (View Identity or the Edit Identity QuickLink) synchronize immediately, possibly after an approval.
- Aggregation changes synchronize when an Identity Refresh runs with Synchronize Attributes selected.
With Lifecycle Manager, the Attribute Sync business process can handle synchronization with approvals and notifications. Choose it on IdentityIQ Configuration > Identities and either check Always Sync using workflow or enable Sync with Workflow on individual attributes. Enable Attribute Sync under General Actions in Audit Configuration to audit it.
The Circular Reference Trap
If an attribute's source and target are the same application attribute, values can change on every synchronization. The risk is greatest when a transformation rule changes the value without first checking whether it was already transformed.
When Mapped Values Change
| Step | What happens |
|---|---|
| Aggregation | Account attributes are stored on Links. The identity is marked as needing refresh. |
| Identity Refresh with Refresh identity attributes | Source mappings are evaluated and identity attributes are updated. |
| Same refresh with Process Events | Lifecycle events on changed attributes fire (section 5.1). |
| Same refresh with Synchronize Attributes | Target mappings push values to accounts. |
| Refresh with Refresh assigned scope | Scopes based on the attribute are recalculated (section 3.3). |
Choosing Sources Wisely
- Put the most trusted source first. HR normally owns name, department, and manager. Directory systems may be better for email or phone.
- Use an application rule when a value needs reshaping for one source only, such as parsing a manager DN from AD. Use a global rule when the same logic applies wherever the attribute appears.
- Avoid frequently changing attributes such as last login date. They mark identities as changed on every aggregation and weaken delta refresh (section 13.1).
- Decide on edit modes deliberately. Read Only protects HR data. Permanent suits data maintained in IdentityIQ itself.
Worked Example
Map department with the source Workday.DEPT_NAME (primary), then AD.department (fallback). Mark it Searchable and Group Factory, set Edit Mode to Read Only, and add a target mapping to Salesforce.Department with Provision All Accounts. Add a Value Change Workflow that notifies the new department's manager. Then schedule HR aggregation, followed by refresh with Refresh identity attributes, Process Events, and Synchronize Attributes.
The department identity attribute has two sources: Workday.DEPT_NAME at the top and AD.department below it. An identity has no department value in Workday. What does IdentityIQ use?
Nothing, because only the primary source is ever read
The AD.department value, because IdentityIQ moves down the source list until it finds a value
The combined values of both sources
The value last entered in the UI
A help desk agent corrects an identity's phone number in the UI, and the change must survive later refreshes even if HR sends a different value. Which Edit Mode achieves this?
Read Only
Permanent
Temporary
Searchable
A new job title arrives from the HR aggregation, but the title is not pushed to the AD account even though a target mapping exists. What is most likely missing?
A Value Change Rule on the attribute
Group Factory on the attribute
The Searchable flag
An Identity Refresh with the Synchronize Attributes option after the aggregation
The mail identity attribute uses AD.mail as a source and also as a synchronization target, and its value keeps changing on every sync. What is the problem?
The same application attribute is both source and target, creating a circular reference.
mail must be marked multi-valued.
AD must be marked authoritative.
The Value Change Workflow is missing.
Sections you finish are checked off in the contents.