Waits and approvals

Waiting is part of work

A Flow can wait for a decision, information or event. The wait has an identity and retained state. Closing the interface does not turn a wait into failure or lose its continuation point.

Wait	Expected value	Continuation
Approval	Decision by an authorized member	Apply the corresponding branch
Information	Declared data or result	Recheck conditions
Event	Recognized signal for this run	Continue the relevant step
Deadline	Declared time policy	Signal or perform the admitted effect

Example: manager review

After drafting, the proposal waits for review. The manager checks the result, sources and criteria. Approve permits finalization; Request changes returns work to the affected scope. The decision retains author and context.

Avoid ambiguous continuations

A late response must not apply to a new request version without checks. Repeated events must not finalize a quote twice. The engine checks wait identity, version and any recorded decision.

Choose a record or result

A reference input uses the wait’s declared Query to offer eligible records or results. For Clients/Quotes, a review can require a result from the selected proposal rather than a pasted identifier. Surface resolves the Query’s parameters from the execution context; the interface does not supply private parameter values.

Choosing an item retains its exact Revision. Surface rechecks eligibility, current access and the wait before accepting the signal. A changed or no-longer-eligible choice must be reviewed again. An input requiring a result also checks its native Task and Action evidence: a record with a similar type or text is not a substitute. Approval and expiration cannot both decide the same wait.

Show the next action

Progress identifies what is awaited, who can act and what happens next. An unexplained wait resembles a blockage; a clearly presented wait lets people advance the work.

Applied examples : Wait for a decision

An approval event resumes work; expiration remains explicit and bounded.

Configuration

Fragment placed in flowBlueprints[].composition.steps[]. Properties and accepted values.

{
  "key": "review",
  "kind": "wait",
  "inputs": [],
  "arrival": "active-only",
  "ordering": "first-committed",
  "eventKey": "quote-approved",
  "recipient": "initiator",
  "timeoutMilliseconds": 86400000,
  "onExpiration": "fail"
}

Variation and connection

Fragment placed in flowBlueprints[].composition.inputs. Properties and accepted values.

[
  {
    "key": "client",
    "type": "surface-reference",
    "provenance": "caller",
    "minimum": 1,
    "maximum": 1
  },
  {
    "key": "need",
    "type": "text",
    "provenance": "caller",
    "minimum": 1,
    "maximum": 1
  }
]

UI layout example

The illustrative layout below places this configuration in the Clients/Quotes app. Insert each fragment at the stated location, with Field, Query and Action references matching the Model declarations.

1. Qualify need
2. Prepare proposal
3. Wait for decision
4. Retain result

SurfaceClients / North StudioExample

Waits and approvalsWait for a decision

Clients

✓

Qualify needCompleted

✓

Prepare proposalCompleted

03

Wait for decisionDecision required

04

Retain resultUpcoming

Preparation is awaiting a decision

The proposal and its sources remain available while waiting.

Review proposal