Skip to main content

Creating IDs for objects and events

Unique identifiers (IDs) differentiate every object and event instance within your Celonis data model. Properly constructed IDs prevent data duplication and perspective load failures in your data pools, safeguarding the integrity of downstream process metrics and KPIs.

Construct unique IDs by concatenating the specific object or event type name with the primary key fields from your source system. Enclose the type name in single quotes to define it as a string literal. For example, when defining an operational entity for an Order-to-Cash process:

'SalesOrder_' || "VBAK"."VBELN" AS "ID"

Always use standardized delimiters such as “::” when concatenating IDs to ensure clean data parsing across different layers of the query engine. For example:

SELECT <%=sourceSystem%> || '::' || "EKKO"."MANDT" || '::' || "EKKO"."EBELN" AS "ID",

The query engine references object and event IDs to partition data. Do not use random UUID source columns in isolation. Instead, concatenate UUIDs with columns shared across other tables to help the engine relate columns and optimize data retrieval speeds during component rendering.

Important

Keep the overall ID string length as short as possible. Excessive string length degrades transformation performance and slows relationship mapping across tables. Do not include unneeded expressions.

When merging data from multiple source system instances (for example, separate ERP systems for regional Accounts Payable processes), prepend the local parameter sourceSystem to prevent identifier collisions across the data pools. Celonis catalog transformations use this parameter to prefix the ID for an object type or event type.

Instead of this:

SELECT <%=sourceSystem%> || 'Contract_' || "EKKO"."MANDT" || "EKKO"."EBELN" AS "ID",

Write:

SELECT <%=sourceSystem%> || '::Contract_' || "EKKO"."MANDT" || '::' || "EKKO"."EBELN" AS "ID",

If you maintain multiple copies of the Celonis catalog transformations for the same process across different source system connections, set the sourceSystem parameter to a unique value for each instance. For custom transformations, implement a local parameter or a hard-coded source system name to achieve the same isolation.

Important

Keep source system prefixes minimal (such as a single letter) to preserve string performance limits while ensuring uniqueness across connections.

Duplicate IDs occur in the following scenarios:

Duplication case

Solution

Source Data Integrity: Duplicate records exist natively within the raw source system tables.

Apply an explicit WHERE filter or a ROW_NUMBER() window function in your extraction query to isolate valid records.

Redundant Ingestion Paths: Two separate pre-transformed data sets incorporate the same source data to generate events.

Adjust your transformation join conditions or consolidate ingestion pathways to ensure each source record maps to a single event generator.

Granularity Mismatches: Transformations extract attributes from a line-item table instead of a header table, causing unexpected cardinality expansion during joins.

Modify the SQL join to reference the primary header table, or use a DISTINCT clause when pulling header-level attributes.