Gate Node

The gate node category suspends a workflow instance at a specific step until an external signal resolves it. The only palette-registered gate node today is gate.human_query, which pauses the workflow pending a human decision - an approval, a rejection, or a timeout.

When a workflow instance reaches a gate node, the DAG executor:

Writes a gate record to the Redis sorted set with an expiry timestamp.
Creates an entry in the Approvals page for the reviewer.
Suspends the workflow instance (status transitions to suspended).
Waits for either a human response via the Approvals page, or a timer expiry via the /api/cron/gate-timer cron job.

Gate resolution is idempotent - if a timeout fires and a human responds at the same moment, only one resolution is applied.

`gate.human_query`

Prompts a human reviewer with a configurable message and optional compliance template. Suspends the workflow until the reviewer submits a response or the gate times out.

Ports

Port	Direction	Type	Description
`input`	input	Any	Upstream signal that triggers the gate (payload unused - the gate suspends on entry)
`approved`	output	Object	Taken when the reviewer approves, or when `onTimeout: "approve"` fires
`rejected`	output	Object	Taken when the reviewer rejects, or when `onTimeout: "deny"` fires
`timeout`	output	Object	Taken when the gate times out and `onTimeout` is `"escalate"` or `"skip"`

The approved, rejected, and timeout ports each carry the form submission payload (if any) as a free-form object.

Gate output ports (approved, rejected, timeout) must serialize as step.branches in the workflow definition. Always use the canvas editor or canvasToDefinitionV2 - hand-editing the YAML to add gate edges can silently break routing. See Canvas Validation for details.

Config

Field	Type	Default	Description
`prompt`	string	-	Message shown to the reviewer on the Approvals page. Supports `{{ }}` template syntax.
`approvalTemplate`	string (template ref)	-	Optional compliance or SDLC template that defines the approval schema and BFSI tier. Select from your org's templates.
`timeoutValue`	number	`72`	How long before the gate times out (combined with `timeoutUnit`). Set to `0` for no timeout.
`timeoutUnit`	string	`hours`	Unit for the timeout: `seconds`, `minutes`, `hours`, or `days`.
`onTimeout`	string	`escalate`	What happens at timeout: `approve` (auto-approve), `deny` (auto-reject), or `escalate` (route to `timeout` port).

Timeout behavior

`onTimeout` value	Which port fires	When to use
`approve`	`approved`	Low-risk steps where proceeding by default is acceptable
`deny`	`rejected`	High-risk steps where blocking on timeout is safer
`escalate`	`timeout`	When you want explicit handling of the timeout case (e.g. notify a manager)

Gate timeouts are evaluated by the /api/cron/gate-timer job, which runs at minute granularity. Sub-minute precision is not currently supported.

Approvals page

When a workflow reaches gate.human_query, the platform creates a row in the Approvals page (/approvals). The reviewer sees:

The workflow name and the current node label
The prompt text from the gate config
The form defined by approvalTemplate (if set)
Approve / Reject buttons

Submitting the form resumes the workflow and routes to the appropriate output branch.

YAML example

steps:
  - id: model_risk_review
    type: gate
    nodeId: gate.human_query
    config:
      prompt: |
        A new model profile is being deployed to production.
        Issue: {{ $trigger.data.issueIdentifier }} - {{ $trigger.data.issueTitle }}
        Please review the model risk assessment and approve or reject this deployment.
      approvalTemplate: "tpl://bfsi/model-risk-v1"
      timeoutValue: 48
      timeoutUnit: hours
      onTimeout: escalate
    branches:
      approved: next_step
      rejected: notify_rejected
      timeout: notify_escalation

Wiring pattern

[upstream action]
    │
    ▼
gate.human_query
    ├── approved ──→ [continue workflow]
    ├── rejected ──→ [handle rejection]
    └── timeout  ──→ [escalate / notify]

Gate system internals

For developers building custom tooling around gate behavior:

Gates are stored in a Redis sorted set keyed by expiry timestamp. The cron job calls processTimeouts() every minute.
A resumed gate pre-populates the executor's completed-step map from both Redis and the database before re-running the DAG from the interrupted tier.
Multiple concurrent instances of the same workflow each maintain independent gate records - they do not share state.
Gate records are cleaned up after resolution (both timeout and human response paths).

For the full gate runtime documentation, see Runtime: Gates and Suspension.

BFSI compliance gates

In BFSI-mode workflows (sdlc-bfsi, sdlc-bfsi-model-risk), gate.human_query is used with SR 11-7 compliant approval templates that enforce multi-level reviewer sign-off. The approvalTemplate field pins the gate to a specific BFSI template that defines required reviewer roles, data retention requirements, and audit trail fields.

See BFSI Compliance: Approval Gates for the BFSI-specific gate bridge documentation.

Runtime: Gates and Suspension - gate system internals, Redis sorted set, resume-from-gate
Canvas Validation - gate handle serialization as branches (important footgun)
BFSI Compliance: Approval Gates - multi-tier approval gates for regulated workflows
Condition Nodes - linear.issue.predicate, rensei.value.switch for routing before a gate

On this page