Skip to main content
Question

When use events, when history Table

  • Nov 1, 2026 3:42 PM UTC
  • 1 reply
  • 20 views

DominicMutzhas
Level 3
Forum|alt.badge.img+5

Hi Everybody,
I have a question about modeling to visualize historical attribute-values over time. 

Often Celonis connects to systems like SAP that already has obejcts where only events/changes are stored instead of daily Snapshots.
An example would be a price change on an Order for example.

In more custom processes though, like for example in the supply chain, we often have daily snapshot tables from which we derive events via a snapshot comparison with a lag().

Now for my question:
lets say I have a Part and a supplier and a daily snapshot of the per supplier with attributes like  “demand_quantity” for different parts.
I want to visualize the demand per grain “part|supplier” over time on a line-plot.

i now have multiple options to model this in objects and events:
1.I cerate an object type “Part” and an object type with grain “supplier|part” with an event “demand changed” PLUS an object with grain “supplier|part|date” that holds the snapshot history.

2.  I cerate an object type “Part”  and an object type with grain “supplier|part” with an event “demand changed” that has atttributes “new_value”/”old_value”

3. I cerate an object type “Part” with an event “demand changed” that has atttributes “supplier” and “new_value”/”old_value”


To visualize as a heatmap:
1. with option 1 its very straightforward...i can simply use the attributes from the history table and events are not needed for the visual.

2. with option 2  I have one object less, but I would have to use timeline_column() to reconstruct a daily value from the “demand-changed” in the event log of the “part|supplier” object. i 

3. with option 3 I have two objects less, but I no longer have the grain “part|supplier” and an object, so i guess i would have to visualize aggragated per “part” instead of “part|supplier” or constuct some temporary table with grain “part|supplier” ( if thats possible)

Now i am wondering which of these options is best practice or recommended, and also why?
Note that I already get a snapshot table from the source system ( unlike in most SAP systems).

I hope this is not too long and i would be grateful for any insight!
 

1 reply

gagan1
Level 12
Forum|alt.badge.img+7
  • Level 12
  • Nov 1, 2026 6:53 PM UTC

Hi ​@DominicMutzhas ,

I'd recommend option 1, with one change.

On your title question, I'd keep it simple. Need the demand on a given day? That's the snapshot. Need to know when demand changed and from what to what? That's a change table on the pair. Need the change to show up as a step in your process, say before a PO goes out? Only then make it an event.

 

Option 2 costs more than it looks. In an OCPM perspective event tables are only reachable through CREATE_EVENTLOG with a lead object, and TIMELINE_TABLE only gives you the day buckets. A PU function fills the days with a change and leaves the rest empty, so you'd still carry the last value forward yourself.

 

Option 3 has the problem you already spotted. On the temporary table, DOMAIN_TABLE can build one at part|supplier grain, but it only holds the combinations that actually occur, so you're back to filling the gaps yourself, in every query. The pair should just be an object.

 

For option 1, I'd keep the current demand as an attribute on the part|supplier object and give the snapshot object a concatenated ID plus a relationship to the pair. A daily snapshot isn't a textbook business object, so call it the pragmatic option, but the chart stays a plain query on one object.

 

The change is the "demand changed" event. Put the change history on the pair itself. OCDM has change tables for that (c_o_ tables with an old and new value per row, joined straight to the object table), filled by the optional Changes script in the pair's transformation. If you also want it as a step in the process flow, derive the event from those changes, which is the same pattern Celonis uses in its own pipeline. Your LAG output feeds either.

 

Volume is the thing to watch, since the snapshot grows with pairs × days. Load weekly or just the last few months if daily is more than the chart needs.

 

The Object-Centric Modeling Best Practices course in the Celonis Academy goes deeper on these decisions.