The visual Workflow Canvas expands beyond the classic linear form and provides these node types:
This chapter focuses on Branch, Tag Lead, and Webhook.
From the Workflows table, select the Workflow Name or Settings action to open its Canvas.
The Canvas uses connected visual nodes and preserves the Workflow's trigger configuration and step graph.
A Branch node evaluates a stored Workflow variable and selects the next path based on configured cases.
A Branch therefore normally depends on information captured earlier, such as a Question response.
Configure the Branch to evaluate the intended variable.
The variable name should correspond to a value that actually exists in the Workflow run.
If a preceding Question saves a response to a variable, that variable can be used as the basis for later branching.
A Branch can contain ordered cases.
The runtime evaluates the cases and follows the first matching path. A default case can provide a catch-all route when no earlier case matches.
Design branches so every realistic visitor response has an intentional destination.
Do not connect Branch paths in a way that creates an unintended endless loop.
The Workflow engine contains a jump guard for abnormal branch looping, but the correct operational practice is to build a clear graph with deliberate exits.
A Tag lead node adds one or more string tags to the Lead associated with the Workflow Conversation.
This lets a scripted visitor path classify or mark the Lead based on what occurred during the Workflow.
Use tags that communicate operationally useful information, for example a product interest, qualification outcome, or Workflow path.
Avoid generating unnecessary tags that make Lead review harder.
The Workflow runtime is able to attach tags to the Conversation's Lead and can create the applicable Lead record when required by the Workflow path.
Test Tag Lead behavior using a controlled Conversation before relying on tags for downstream processes.
A Webhook node sends Workflow data to a configured external URL.
The Canvas step model supports:
The Workflow engine dispatches webhook delivery through a queued job rather than holding the visitor Conversation open while an external endpoint responds.
This means webhook delivery should be treated as an external automation action rather than a visible Chat response.
Use an endpoint controlled by your organization or a trusted integration.
Verify that the endpoint is designed to accept the Workflow payload and that it does not expose sensitive data unnecessarily.
Because webhook delivery is asynchronous, a visitor-facing Workflow can continue even when an external receiver later experiences a delivery problem.
Do not design a visitor message that promises an external action succeeded unless your process has a reliable way to confirm that success.
The current classic Workflow form directly exposes Message, Question, and Escalate steps.
The visual Canvas is the user-facing editor that exposes Branch, Tag Lead, and Webhook nodes in addition to those linear step types.
Use the Canvas when the Workflow requires branching or side-effect nodes rather than attempting to force advanced nodes into the classic form.
Before setting an advanced Workflow to Active: