Skip to main content
An Engine is a pattern for a business process that advances records through states over time. It combines an orchestrator Play, transition Plays and persistent customer tables. Use it when one execution is only part of a longer process. For example, an account can move from research to review, then become ready for outreach. Research, approval and notification may happen in different runs. The Engine’s stored state connects those runs and records which transition can happen next. The workflow defines its states, allowed transitions, table layout and conflict rules. Engines use the same Play runtime and Database features as other workflows.

Business state outlives an individual execution

Business state describes where a record is in a process. Run status describes one attempt to advance or inspect it. A research run can complete while its account still needs approval. An account can remain researched when a later notification fails. These states illustrate one account-review process. Your workflow can define different states and paths. A terminal business state means this process has no next transition for the record.

The orchestrator and transition Plays have different jobs

A transition Play performs a bounded transformation, such as research, qualification or preparation of a proposed update. The orchestrator Play reads the current state, selects a transition and records an allowed result. This separation keeps useful logic reusable. The same research Play can serve an Engine and a one-time account request. The orchestrator owns the policy that decides whether accepted research advances the account. Compatible scalar transitions can run inline within the orchestrator, sharing its execution graph. An independently published scalar transition can also start a separate run, including one that waits for a human response. An admitted independent child survives parent completion or cancellation, so the workflow must track and control that child separately. Batch transitions need their own top-level runs. Play composition explains the two scalar composition methods and their supported capabilities.

Durable tables are the process’s memory

Customer tables hold the record’s current state, transition inputs and accepted outputs. A transition record can retain the business key, prior state, next state, evidence and version identities. This history explains why the record moved. A run dataset shows what one execution processed. The Engine’s tables carry business state between executions. Their different roles let you inspect a failed attempt without losing an earlier accepted business decision. For example, an account table can retain needs_review while a review queue holds the evidence. A later approval starts another run that checks the current record before moving it to ready. The platform owns Play versions, run status, credentials, Monitor configuration and billing. Engine tables contain customer business data, not replacement copies of that platform control state.

A handoff is a data-integrity problem

An accepted transition can produce an output and an input for the next state. The workflow needs to recognize both facts if execution stops between them. Deterministic transition and handoff keys, together with database constraints, let persistence logic recognize completed work and repair a missing handoff. The orchestrator also handles unknown states, forbidden moves, invalid child results and concurrent updates. A completed research Play does not by itself authorize a CRM write or a state change. An external destination has its own write contract. Destination-supported idempotency or read-back reconciliation protects that handoff. An Engine does not create a transaction across arbitrary external systems.

Waiting changes the orchestration shape

An Engine can advance several immediate transitions in one run. When a process needs a later event or review, persistent state lets another invocation continue it. The business process can remain open without keeping an agent chat open. A schedule can revisit records that need work. A webhook can bring an approval or external event. A supported SQL listener can react to a new source row. The trigger starts an attempt, while the stored business state determines which transition is allowed.

Continue learning