Study guide
17.2 Relationships Between Common Data Object Models
SailPoint Certified IdentityIQ Engineer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: The IdentityIQ Engineer Exam
1.1 Exam Format, Official Blueprint, and Study Strategy
2 Chapter 2: Infrastructure, Installation, and Extended Attributes
2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them
3 Chapter 3: Build, Deployment, Patching, Access, and Email
3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection
4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows
4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows
5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup
5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations
6 Chapter 6: Certification Campaigns and Certification Rules
6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules
7 Chapter 7: Policies and Policy Violations
7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations
8 Chapter 8: Reporting, Advanced Analytics, and Auditing
8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing
9 Chapter 9: Rules, Rule Libraries, and the SailPoint API
9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods
10 Chapter 10: Workflow Development
10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows
11 Chapter 11: Email Templates, Branding, and Localization
11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI
12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation
12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings
13 Chapter 13: Data-Loading Tasks and Application and Connector Rules
13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types
14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console
14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging
15 Chapter 15: Debug Pages and the Administrator Console
15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging
16 Chapter 16: Role Model and Identity Attribute Mappings
16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings
17 Chapter 17: Data Objects, Relationships, and Group Types
17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types
17.2 Relationships Between Common Data Object Models
Key Takeaways Explain This Topic AI
One Identity has many Links; each Link belongs to exactly one Application and at most one Identity; a Link with no identity is an uncorrelated account.
A Link's entitlement values correspond to ManagedAttributes of the same application, attribute, and value, and group aggregation creates those catalog entries.
Identities reference roles in two ways: assigned roles (from rules or requests) and detected roles (from matching IT role profiles to Link entitlements).
Roles relate to other roles through required, permitted, and inheritance links, and to entitlements through Profiles tied to an Application.
Governance and process objects (certifications, violations, requests, work items) always point back to an Identity and are driven by refresh, certification, and workflow processes.
Last updated: September 2026
Relationships Between Common Data Object Models
Objective 7.6 asks you to understand the relationship between common data object models . Section 17.1 named the objects. This section connects them, which is what scenario questions test: if X changes, what else changes, and which process makes it happen?
The Core Identity-Account-Entitlement Chain
Loading diagram... Core object relationships
- Relationship Cardinality Created or maintained by
- Application → Link One application, many accounts Account aggregation
Identity → Link One identity, many accounts. Each Link belongs to at most one identity. Correlation (configuration or rule), creation from authoritative sources, manual correlation
Application → ManagedAttribute One application, many catalog entries Account group aggregation , Promote managed attributes , catalog import
Link entitlement value → ManagedAttribute Matched by application + attribute + value Aggregation, with the schema's Managed flag (section 12.2)
Identity → IdentityEntitlement One identity, many entitlement records Aggregation and refresh (connected state), requests, certifications
Identity → Manager (Identity) Many identities, one manager Manager correlation , and the manager identity attribute
Correlation Results
Authoritative application account with no match : a new Identity is created (Creation rule) and the Link is attached.
Non-authoritative account with no match: the Link stays uncorrelated until correlation logic improves or someone manually correlates it. Manual correlation is permanent (section 12.1).
Aggregation actions such as Correlate Reassign show a Link moving from one identity to another.
The Role Relationships
Relationship Meaning
Identity → Bundle ( assigned ) Business roles granted by assignment rules (refresh), requests (LCM or batch), or administrators
- Identity → Bundle ( detected ) IT roles whose Profiles match the identity's Link entitlements (refresh)
- Bundle → Bundle ( required / permitted ) Business-to-IT links that drive provisioning or pre-approval
- Bundle → Bundle ( inheritance ) Deeper roles inherit shallower ones of the same type
- Bundle → Profile → Application Profiles define entitlement filters for one application
How a change ripples: a new assigned business role leads, through required IT roles and profiles, to a provisioning plan for missing entitlements. Once the entitlements exist on the target, the next aggregation updates the Link , and refresh records the IT role as detected . Provisioning alone does not update role detections. A refresh is needed.
Governance and Process Relationships
From To Notes
CertificationGroup → Certification → CertificationEntity → CertificationItem Nested Items reference the identity, Link, role, entitlement, or violation under review. Revocations create provisioning plans through Perform Maintenance or Process Revokes Immediately.
Policy → PolicyViolation → Identity Many violations per policy Created by refresh or aggregation with Check active policies
- IdentityRequest → WorkflowCase → WorkItem One request, one case, many work items LCM requests (section 4.3)
- TaskDefinition → TaskResult One definition, many runs Tasks, reports, and workflows
Identity (workgroup) → member Identities Many-to-many Workgroups share ownership, work items, capabilities, and scopes
Capability / Scope → Identity or workgroup Many-to-many Rights and visibility (section 3.3)
ObjectConfig → a class's extended attributes One per class Identity, Link, Application, Bundle, ManagedAttribute, CertificationItem
Ownership and References
Many objects point to an owner , which is always an Identity , either a person or a workgroup :
Application owner and revoker receive certifications, entitlement approvals, and revocations (section 12.1).
ManagedAttribute owner approves entitlement requests and reviews entitlement owner certifications.
Bundle owner approves role changes and role requests and reviews role certifications.
Policy owner and policy violation owner maintain policies and act on violations (section 7.1).
Because these are references, deleting or deactivating an identity can leave objects without a working owner . That is why Rapid Setup's leaver process can reassign artifacts (applications, workgroups, policies) and identities (service accounts and bots) owned by a departing user, and why the Prune Identity Cubes task protects owners, managers, and identities with capabilities from deletion.
Reading Relationships in XML
In object XML, relationships appear as references by class and name or ID, for example <Reference class="sailpoint.object.Application" name="Active Directory"/> inside a Link or a Profile. When objects move between environments, references by name survive but database IDs do not. That is why -clean and -noids exist (section 3.1).
Walking a Scenario Through the Model
HR moves Maria from Sales to Finance.
HR aggregation updates Maria's HR Link attributes and marks her identity as needing refresh.
Identity Refresh promotes the new department to her Identity through the identity mappings (section 16.3).
The same refresh re-evaluates assignment rules : the Sales Rep business role is removed and Finance Analyst is assigned.
With Provision assignments , a ProvisioningPlan adds the Finance IT roles' entitlements and, unless retention options apply, removes Sales entitlements. Plans compile per Application .
Process Events fires a mover lifecycle event , launching a WorkflowCase with a WorkItem for her new manager.
Check active policies may create a PolicyViolation if old and new access conflict.
The next aggregations confirm the target changes on her Links , and the next refresh updates detected roles and IdentityEntitlements .
Each step touches a different object, and each object relationship is maintained by a specific process. That is the core idea behind objective 7.6.