Use snapshots for flow and events for audit

Event facts answer how many payments or shipments occurred each day. Accumulating snapshots answer how many orders are currently stuck and average cycle time.

Important processes commonly retain source events and a flow-oriented snapshot.

Declare the lifecycle entity grain

A row can represent an order, line, fulfilment, ticket, or application. Split shipments may make fulfilment the correct entity.

Wrong grain makes milestones and duration ambiguous.

Update milestones and durations explicitly

Create the row with known dates, then populate payment, ship, and receipt as events arrive, calculating planned and actual intervals.

Distinguish first and final dates and define reopen or repeated events.

Require idempotency and historical evidence

Out-of-order, duplicate, and corrected events must not regress milestones or double-count. Use event identity and version.

If users need yesterday’s known state, add periodic snapshots or change history because the accumulating row shows the latest state.

Accept abnormal flows

Test normal, skipped stage, partial shipment, cancellation, reopen, late, and duplicate events, reconciling backlog and duration.

BuildTable can be evaluated for fact design; incremental update, deduplication, and historical snapshot orchestration require confirmation.

Choose grain from the lifecycle entity

One row must represent a stable process instance. Split shipments may require fulfilment or order-line grain rather than order grain. Draw states and events before selecting the entity.

Declare the grain in documentation and uniqueness tests. Keep whole-order and line measures from mixing on the same row.

Use event, accumulating, and periodic facts for different questions

Immutable events support audit and occurrence counts; accumulating rows support current backlog and cycle time; periodic snapshots support historical in-process stock.

Mature designs often retain events and derive both projections. An accumulating row alone cannot reproduce yesterday’s known state.

Make milestone updates idempotent and order-aware

Use event identity, source version, business time, and ingestion time. Duplicates must not reapply, late events may fill gaps, and corrections need explicit rules.

Define first and last repeated milestones, reopen behavior, and negative-duration quarantine. Replay must produce the same snapshot.

Add planned milestones for process performance

Store promised or target dates alongside actuals and decide whether initial, current, or change history matters. Overwriting commitment loses drift evidence.

Define backlog stages with entry, exit, timeout, and exclusion rules so KPI logic matches the state machine.

Test abnormal flows and verify BuildTable scope

Exercise normal, skipped, partial, repeated, cancelled, reopened, duplicate, late, corrected, and replayed events. Reconcile event, process, state, and duration.

BuildTable may be assessed for fact design, while merge, deduplication, state machines, periodic snapshots, and backfill orchestration require verification. Highly cyclic workflows may need event-first projections instead.

Should an order lifecycle use transaction facts or an accumulating snapshot?