The Sync Block groups a sequence of workflow steps into a single, immediate execution unit. Normally, each step in a workflow is processed in the background one at a time — the Sync Block changes this by running all the steps inside it instantly and without interruption, returning the result before the workflow moves on. It appears on the canvas as a container with a Start node and an End node, similar to the For Each Loop and While Loop.

Use a Sync Block when the workflow must complete a set of steps in real time and the result is needed immediately.

When to Use

Use a Sync Block when your workflow needs to:

Populate dynamic dropdowns in real time — a user opens a dropdown in a form, the Sync Block calls an external API, transforms the response, and returns the list of options instantly.
Validate form input instantly — the user submits a form, and the block validates the data against a database or external service, returning success or error messages before the page refreshes.
Perform an immediate calculation and return the result — execute a Function Node or a chain of Function and Update Data Nodes that compute a value the form needs right away.
Run a short integration call that requires user context — some connections require user-level OAuth authentication (where the end-user's own credentials are used). These connections are only permitted inside a Sync Block because the user is actively present in the session.
Guarantee ordering for a critical set of steps — when the workflow must ensure that Step A finishes before Step B starts, and both must complete before anything downstream runs.
Build a fully synchronous utility workflow — applications like dynamic dropdown utilities or list-view utilities use a Sync Block that spans the entire workflow, turning the whole application into a request-response endpoint.

How It Appears on the Canvas

When you add a Sync Block, two nodes are created automatically:

Node	Role
Sync Block (Start)	The entry point of the block. Marks the beginning of the synchronous execution scope.
Sync Block (End)	The exit point of the block. When execution reaches this node, the synchronous scope closes and the workflow resumes normal background processing for subsequent nodes.

An edge is automatically created from the Start node to the End node. You place the steps you want to execute synchronously between the Start and End nodes on the canvas.

Both the Start and End nodes are created with the following defaults:

Property	Default
Can Duplicate	No — you cannot duplicate a Sync Block node individually.
Can Delete	Yes — deleting the block removes both the Start and End nodes and all connecting edges.
Is Node Configured	Yes — the block is considered configured upon creation (no additional setup required).

Configuration

The Sync Block is a structural container rather than a configurable logic node. It has no condition, no iteration settings, and no special parameters. Its behavior is determined entirely by its position in the workflow graph and the nodes placed inside it.

Progress Path

You can configure visibility settings for the Sync Block in the progress tracker:

Setting	Description
Hide	Completely hides the Sync Block from the end-user's progress path.
Hide if Skipped	Hides the block only if it was skipped during execution.

When visible, all node executions within the block are grouped under the Start node in the progress path, creating a nested view similar to how loop iterations are displayed.

How It Works at Runtime

Here is the step-by-step execution flow:

1. Workflow reaches the Sync Block (Start) node. The execution engine detects this is a synchronous block.

2. Execution mode switches to synchronous. Instead of placing each step on the background queue (the normal path), the engine runs all steps inside the block immediately, one after another, in a single uninterrupted process.

3. Nodes execute sequentially. For each node inside the block:

The engine determines the correct node type and runs its logic.
The node reads from and writes to the Data Center as normal.
The result is recorded for auditing and progress tracking.
The next node in the sequence is processed immediately.

4. Failure handling. If a node inside the block fails:

The block can be configured to stop immediately, preventing further nodes from running.
Alternatively, the block can continue processing by following the failure output of the failed node.

5. Execution reaches the Sync Block (End) node. The block completes and returns its result.

6. Workflow resumes normal execution. The next node after the Sync Block is processed through the standard background queue as usual.

Supported Nodes Inside a Sync Block

The following node types can be placed inside a Sync Block:

Node Type	Notes
Action	Calls an external API. User-level OAuth connections are only permitted inside Sync Blocks. Timeout limits are stricter within a Sync Block to prevent long waits.
Function	Executes custom JavaScript code.
Decision	Routes execution based on conditions. The chosen path continues synchronously.
Update Data	Modifies Data Center values.
Mapper	Transforms data structures.
Branch / Merge	Splits and re-joins parallel paths within the synchronous scope.

Nodes that inherently pause execution — such as Input, Approval, Delay, and Async Callback — should not be placed inside a Sync Block, because the block is designed to execute without interruption.

Validation Rules

Start node:

Must have an incoming edge from the preceding workflow node.
Must have an outgoing edge into the block body (to the first node between Start and End, or directly to the End node).

End node:

Must have an incoming edge from the last node in the block body.
Must have an outgoing edge to the next node in the workflow after the block.

Action Nodes inside a Sync Block must have a single outgoing edge. Unlike background Action Nodes — which require separate "Success" and "Failure" output handles — synchronous Action Nodes use a single output because the block's overall success or failure is managed at the block level.

Data Center Output

The Sync Block itself does not produce dedicated Data Center output fields like the For Each Loop or While Loop do (such as index or isFirst). Instead, each node inside the block writes its own output to the Data Center as normal, and those outputs are available to subsequent nodes both inside and outside the block.

Progress Path

All node executions within the Sync Block are grouped under the Start node in the progress tracker, creating a clean, nested view. This makes it easy to expand the block and see the status of each individual step for debugging and auditing purposes.

Retriggering

The Sync Block is eligible for retriggering. If any node inside the block fails or stalls, an administrator can retrigger the Sync Block's Start node. The retrigger flow:

Clears execution records for downstream nodes within and after the block.
Re-enqueues the Sync Block Start node for processing.
The engine re-enters the synchronous execution path, re-executing all nodes in the block from the beginning.

Sync Block vs. Normal (Background) Execution

Aspect	Sync Block	Normal (Background) Execution
Execution model	All nodes run sequentially in a single, uninterrupted process.	Each node is queued and processed independently in the background.
Response timing	The workflow waits until the entire block completes before continuing.	The workflow continues immediately after queuing; nodes execute later.
Failure behavior	A failure can optionally halt the entire block immediately.	A failure in one node does not prevent other queued nodes from executing (unless explicitly configured).
User-level OAuth	Supported — the user is actively present.	Not supported — no active user session is available.
Timeout limits	Stricter, shorter timeouts to prevent blocking.	Longer timeouts allowed for background processing.
Typical use cases	Dynamic dropdowns, real-time validation, instant calculations, short integration calls.	Long-running API calls, scheduled tasks, approvals, delayed notifications.

Whole-Workflow Synchronous Execution

A special case exists where the entire workflow is synchronous. If the workflow follows this exact structural pattern — Trigger Input → Sync Block (Start) → … → Sync Block (End) → End — the system classifies the whole application as synchronous, allowing incoming triggers to be handled as standard request-response calls that return a result in the same HTTP response.

This pattern is commonly used for:

Dynamic dropdown utility applications — the workflow fetches and returns dropdown options in a single round-trip.
List-view utility applications — the workflow queries, maps, and returns list data synchronously.

Best Practices

Keep the block small and fast. Every node inside a Sync Block runs in the same process, blocking the response. Place only the steps that absolutely must execute in real time inside the block. Move setup, cleanup, and non-critical steps outside.
Use stricter timeouts for Action Nodes. Since the entire block (and potentially the user's request) is waiting, set aggressive timeouts on any API calls. A single slow external call will delay the entire response.
Avoid placing human-interaction nodes inside the block. Input, Approval, Delay, and Async Callback nodes pause execution, which defeats the purpose of a synchronous block. These nodes belong in the normal portion of the workflow.
Leverage Sync Blocks for user-level OAuth connections. If an integration requires the end-user's own credentials (user-level OAuth), it must be inside a Sync Block where the user session is active. Attempting to use such connections in background nodes will result in a configuration error.
Design for failure at the block level. Consider what should happen if any node in the block fails. If the block contains a critical operation where partial completion is unacceptable, ensure the block is configured to halt immediately on failure.
Use the progress path grouping for debugging. When troubleshooting a failed Sync Block, expand the block in the progress tracker to see the execution status of each individual node.
Don't nest Sync Blocks. Placing one Sync Block inside another is not supported. If you need sequential execution within a larger synchronous scope, place all the nodes in the same block.