Stages

Stages are the building blocks of a workflow — each one represents a step that participants complete. You connect stages with transitions to define the path through your workflow.

Every stage has settings that control who participates, how data is captured, and when the stage is considered complete. You can access stage settings by clicking a stage on the builder canvas and opening the settings panel.

Completion Policies

Completion policies control when a stage is considered done when multiple people are assigned to it. By default, the first person to complete the stage completes it for everyone. Completion policies let you require more participants to finish before the stage progresses.

You can set a completion policy in the stage settings panel. Open the Completion Policy settings and choose a mode:

How participants experience it

When a stage has an All or Threshold policy, participants see a progress banner at the top of the stage showing how many people have completed so far (e.g., "2 of 5 complete").

• When you finish your part, click Mark as Done. Your data is saved, but the stage stays open for others.
• After marking done, you'll see a "Done — waiting for others" indicator. The progress banner updates in real time as others complete.
• You can still edit your responses after marking done, until the stage itself completes.
• Once enough people have completed (all, or the threshold percentage), the stage automatically progresses to the next stage.

Things to know

• Read-only roles don't count. If a role is assigned to a stage with can progress turned off, those assignees are excluded from the completion count. Only roles that can progress contribute to the policy.
• Threshold uses a percentage, not a count. This means the policy adapts to however many people are assigned. With a 50% threshold and 6 assignees, 3 must complete. With 10 assignees, 5 must complete.
• Removing an assignee can trigger completion. If an admin removes a participant who hasn't completed, the reduced denominator may satisfy the policy — the stage will automatically progress.

Start Policies

Start policies control when a stage activates when it has multiple incoming paths. This is relevant at merge points — stages where two or more parallel branches converge.

You can set a start policy in the stage settings panel:

How participants experience it

When you complete a stage that feeds into an "all predecessors" merge, and other branches haven't finished yet:

• You'll see a Complete and Wait button instead of the usual "Complete and Next."
• A confirmation dialog explains that the next stage will activate once all parallel branches are done.
• After completing, the session dialog closes — there's nothing to navigate to yet.
• When the last branch completes, the merge stage activates and all assignees are notified.

If you happen to be on the last branch to finish, you'll see the normal "Complete and Next" button — your completion unblocks the merge and the next stage is ready immediately.

Things to know

• Start policies only matter at merge points. If a stage has only one incoming transition, the policy has no effect. The builder will show a note if you set a policy on a stage with no merge.
• A stage with a start policy also shows a merge icon on the builder graph, so you can see at a glance which stages are gated.
• Conditional transitions and start policies are independent. If a predecessor completes but its transition rule doesn't pass, the predecessor is still counted as "arrived" for the start policy. Transition rules control which path is taken; start policies control whether the target is ready.

Activation Timing

By default, stages activate immediately when a preceding stage is completed. Activation timing lets you delay a stage — keeping it locked until a specified date and time.

You can set activation timing from the stage settings panel or by clicking the clock icon on a stage node in the builder. Choose between:

How participants experience it

When a participant completes a stage that leads to a time-locked stage, they'll see a Complete and Wait button with a note about when the next stage will become available.

• A confirmation dialog shows the scheduled activation time.
• After completing, the session dialog closes — the next stage isn't available yet.
• The time-locked stage appears on the session graph with a dashed border, a clock badge, and the scheduled date and time.
• When the scheduled time arrives, the stage activates automatically and assignees are notified.

Things to know

• Activation timing is set on the stage, not the transition. A stage has one activation time regardless of how many paths lead to it.
• If the scheduled time has already passed, the stage activates immediately — there's no unnecessary delay.
• Activation has up to one minute of precision. The system checks for due stages every minute, so activation may occur up to a minute after the scheduled time.
• Start stages cannot have time locks. The first stage in a workflow always activates immediately when the session begins.

Transitions

Transitions are the connections between stages — they define the paths participants can take through the workflow. You create transitions in the builder by dragging from one stage to another.

Conditional transitions

By default, a transition is unconditional — it always fires when the source stage is completed. You can add a rule to a transition to make it conditional.

Click on a transition arrow in the builder to open the edge editor, where you can set a condition. Conditions reference sheet columns and compare their values:

• "If Status equals Approved, go to the Approved stage"
• "If Score is greater than 80, go to the Advanced track"
• "If Category is not empty, go to the Review stage"

You can combine multiple conditions with and / or logic for more complex rules.

Branching and merging

• Branching — A stage with multiple outgoing transitions creates a fork. If the transitions have conditions, only the paths whose rules are satisfied will fire. If multiple rules pass, multiple next stages activate simultaneously.
• Merging — A stage with multiple incoming transitions is a merge point. Use a start policy to control whether the stage waits for all predecessors or activates on the first arrival.

Things to know

• If no transition rules pass, the workflow stops at that stage. Make sure your conditions cover all expected cases, or include a fallback transition with no condition.
• Transition rules are evaluated against the current session data. The values in the sheet at the moment of completion determine which paths are taken.
• Transition rules are independent of start policies. If a predecessor completes but its transition rule doesn't pass, the predecessor is still counted as "arrived" for the target's start policy. Rules control paths; policies control readiness.

Per-Participant Stages

By default, stages are shared — all assigned participants see and work with the same data. Per-participant stages flip this: each participant gets their own private copy of the inputs, and each person's responses are saved as a separate row in a dedicated sheet.

This is useful when you need independent contributions before group work — brainstorms, individual submissions, proposals that will be discussed or voted on later.

When to use this

The classic pattern is independent input followed by group deliberation:

1. Stage 1 (Per-participant): Each participant submits their own proposal, idea, or response — independently, without seeing what others have written
2. Stage 2 (Shared): The group reviews all submissions together using a sheet section, then discusses via a discussion block
3. Stage 3 (Shared): The group votes on the proposals using a poll with data-sourced options

Per-participant stages handle Step 1. Each participant produces one row in the stage's sheet, and downstream stages can display and act on that collected data.

Setting up a per-participant stage

1. Click a stage on the builder canvas to select it
2. Open the stage settings panel
3. Under Stage Mode, switch from Shared to Per-participant
4. Select or create a dedicated sheet for the stage — this is where each participant's row will be stored
5. Add blocks to the stage as usual — they will automatically bind to the dedicated sheet

When you switch to per-participant mode, the completion policy is automatically set to All (all participants must complete before the stage progresses). You can adjust this in the completion policy settings.

What participants experience

Participants on a per-participant stage see the same interface as any other stage — form fields, content blocks, and a progress button. The difference is invisible to them: they only see and edit their own data, not anyone else's.

Once all participants have completed, the stage progresses and the next stage can access everyone's responses — for example, through a sheet section that displays all rows, or a poll whose options are sourced from the collected data.

Things to know

• Dedicated sheet required. Each per-participant stage needs its own sheet. It cannot use the workflow's default sheet or share a sheet with another per-participant stage.
• Polls and discussions aren't available. These are group collaboration blocks — they belong on shared stages where participants interact with each other's contributions, not on per-participant stages where everyone works independently.
• Switching modes archives blocks. If you change a stage from shared to per-participant (or vice versa), existing blocks on that stage will be archived, since they are bound to a different sheet.
• Data persists. Once a participant submits their data on a per-participant stage, it is saved as a row in the dedicated sheet and persists for the rest of the session.