Skip to main content

Helper objects

Helper objects are technical components of the Celonis object-centric data model that centralize complex calculations, logical expressions, and performance optimizations. Instead of acting as direct business-facing KPIs, these objects serve as foundational building blocks for downstream analytics.

In complex business processes like Order-to-Cash or Procurement, data modelers use helper objects to unify shared technical definitions—such as standardized cycle times or multi-conditional rework thresholds—to ensure execution speed and consistency across all dashboards.

Data modelers and analysts create helper objects during the data modeling phase. Implement these objects using one of the following structural types:

  • Helper Tables: Database tables or views generated during transformations to execute heavy calculations (e.g., master data pre-aggregations) before runtime.

  • Helper Columns: Calculated fields added to existing data tables to evaluate row-level logic natively within the data model.

  • Helper KPIs: Shared PQL metrics built to store intermediate values or common mathematical denominators used across multiple analytical views.

  • Helper Views: Dynamically computed layers leveraging advanced PQL functions to serve customized slices of data without duplicating storage.

When to use helper objects

Use helper objects when:

  • Multiple KPIs, filters, or analyses require identical logic.

  • Calculations are complex, performance-intensive, or difficult to maintain inline.

  • The result represents an intermediate data value rather than a final business metric.

  • Multiple downstream analyses depend on a shared technical definition.

When not to use helper objects

Do not use helper objects when:

  • The logic is simple or used only once.

  • The object represents a direct, business-facing metric or dimension.

  • No clear consuming component (KPI, analysis, or table) exists.

  • The object adds technical complexity without clear performance or reuse benefits.

Examples of helper objects with PQL

Review these architectural patterns for implementing helper objects using PQL:

Pattern one: Helper table – Case duration (Order-to-Cash Bottlenecks)

Use a helper table to pre-calculate case cycle times once and reuse the value across multiple downstream KPIs. This pattern optimizes performance when tracking average cycle times, identifying SLA breaches, or executing trend analyses on invoice processing delays.

TABLE _HELP_CASE_DURATION AS
SELECT
  CASE_KEY,
  MIN(EVENT_TIME) AS CASE_START,
  MAX(EVENT_TIME) AS CASE_END,
  DATEDIFF('day', MIN(EVENT_TIME), MAX(EVENT_TIME)) AS CASE_DURATION_DAYS
FROM EVENT_LOG
GROUP BY CASE_KEY

Pattern two: Helper column – Rework flag (Procurement Order Changes)

Use a helper column to simplify repeated logic within filters and KPIs. This pattern flag isolates purchase orders that undergo multiple quantity corrections, reducing code duplication in analytics tracking operational friction.

CASE
  WHEN COUNT_TABLE(EVENT_LOG.ACTIVITY = 'Rework') > 0
  THEN 1
  ELSE 0
END

PQL operators that use reference tables

These PQL operators use reference tables configured as helper objects:

  • FACTORY_CALENDAR: Requires a calendar table containing ID, start date, and end date columns. This configuration filters out non-working days for accurate SLA calculations.

  • WEEKDAY_CALENDAR: Requires a calendar table containing ID, weekday, and shift start/end times to adjust cycle times based on operational shift patterns.

  • WORKDAY_CALENDAR: Requires SAP’s TFACS table to synchronize standard factory calendars directly from SAP source systems.

  • QUANTITY_CONVERT: Requires a conversion rates table containing source unit, target unit, and rate parameters to standardize disparate inventory units across global systems.

  • CURRENCY_CONVERT: Requires an exchange rates table containing currencies, dates, and rate types to unify multi-currency financial records into a single reporting currency.

  • CURRENCY_CONVERT_SAP: Requires SAP’s TCURR, TCURF, and TCURX tables to apply native SAP exchange rate and translation rules to financial data components.

Create custom helper objects to look up long lists of values, such as match lists for the IN operator.

Related topics