Skip to content

Operational Data Model

This page explains, at a high level, how the Identity Operations Platform structures identity data and combines information from multiple upstream repositories (for example OpenText Advanced Authentication, Active Directory, and LDAP).

The goal is to help customers understand how data is collected, linked, and then used for day-to-day identity operations. It is designed to provide an operational overview across all connected systems, while still processing current real-time data when an active decision is made in the platform.

Terminology

  • Operator: an authenticated person who performs actions in the platform.
  • Managed Identity: the target identity/account handled by identity operations.

Why This Matters

In most customer environments, identity data does not come from a single system. Different repositories provide different parts of the identity context:

  • account identity and login context
  • directory identifiers and hierarchy
  • group memberships
  • account status (enabled/disabled, locked/unlocked)

Identity Operations Platform consolidates these signals into a consistent operational model.

Core Data Domains

The platform organizes identity data into a small set of domains:

Domain Purpose
Tenant Scope Keeps all data logically separated per customer tenant.
User Sources Defines connected upstream systems (OpenText Advanced Authentication, Active Directory, LDAP, Microsoft Graph, etc.).
Operator and Managed Identity Records Stores synchronized identity records used by platform operations.
Group Records Stores synchronized group structures and memberships.
Source Mapping Maps one source to another when identity context is split across repositories.
Operational State Tracks synced status such as lock state, enabled state, and sync timestamps.

How Data Is Collected and Consolidated

The platform follows a repeatable synchronization model:

  1. Collect
    Identity Operations Platform connects to each configured user source and reads identity and group data in scheduled sync cycles.

  2. Normalize
    Data from different source types is normalized into a consistent internal structure (identity, identifiers, groups, and state).

  3. Map
    If identities span multiple repositories, source mappings are used to connect the records (for example an OpenText Advanced Authentication repository mapped to a specific AD/LDAP source).

  4. Consolidate
    Operator/managed identity and group context from linked repositories is merged into a single operational view.

  5. Operate
    The consolidated view is used for identity operations, policy-driven actions, and auditable administration workflows.

  6. Decision-Time Validation
    For active operational decisions, the platform can use current real-time source data so actions are based on the latest identity state, not only on previously synchronized snapshots.

Example: OpenText Advanced Authentication + AD/LDAP

A common setup is:

  1. OpenText Advanced Authentication provides the primary authentication and identity context.
  2. A mapping links the OpenText Advanced Authentication repository to a target AD or LDAP source.
  3. Identity Operations Platform resolves the corresponding directory managed identity from that mapped source.
  4. Directory attributes and group memberships are added to the operational managed identity view.
  5. Operations are executed on a consistent identity record instead of isolated source fragments.

This enables customers to operate identities centrally even when source responsibilities are split.

How the Consolidated Data Is Used in Operations

Once synchronized, the combined data model supports:

  • an operational overview across all connected identity systems
  • consistent managed identity and group operations across source boundaries
  • reliable handling of account status changes from upstream systems
  • real-time data handling when current decisions are executed in the platform
  • repeatable, tenant-scoped identity administration
  • traceability for operational and compliance reviews

Customer Planning Guidance

For stable operations, customers should define:

  • which source is authoritative for each data aspect
  • how repositories are mapped when using multi-source identity models
  • expected sync frequency and worker capacity for their environment

This keeps identity operations predictable as the environment grows. For ownership and mapping rules, see Data Ownership and Source Mapping. For deletion behavior across sync cycles, see Identity Lifecycle and Deletion Semantics.