Workflow Builder
Use the Studio canvas to build a real operating system: customer trigger, editable nodes, AI or data decisions, CRM or webhook action, channel response, logs, analytics, and publish controls.
Read the canvas as the operating system: a customer signal enters, Studio sends or prepares the right response, routes by behavior, and hands work to a teammate or external system.
How to read a workflow.
Start at the trigger, follow nodes in order, then review conditions, API calls, logs, and Draft/Live state before publishing.
Use the Draft and Live controls as the production gate. Edit in Draft, test with realistic events, then publish only when the workflow behavior is verified.
Read the canvas as the operating system: a customer signal enters, Studio sends or prepares the right response, routes by behavior, and hands work to a teammate or external system.
Use Intent Trigger when the agent flow should start from a classified user intent, then keep the next node focused on what that intent means operationally.
What the Workflow Builder is
Workflow Builder is the visual canvas in Studio where a business operation becomes a production system. Each workflow is a connected sequence of nodes, and each node should have one visible job.
Read the canvas as customer work: a trigger starts from a message, webhook, schedule, or CRM change; middle nodes clean data, call an agent, route, or update records; final nodes send a message, notify a teammate, call a webhook, or stop safely.
Workflow surfaces
Builder is the canvas. This is where you add nodes, connect the path, edit prompts or actions, and decide what happens when a branch succeeds or fails.
Logs is for real executions. Use it only when there is run history to inspect: trigger payload, node input, node output, status, and errors.
Analytics is for production health once the workflow has traffic: run volume, failures, completions, credit usage, and which branches are being used.
Incoming Webhooks are the entry point when the event starts outside Frontline. Use a webhook when another system should send Frontline a payload that starts the workflow.
Node palette
Triggers start the path. In agent flows, Intent Trigger starts a branch when the agent recognizes a user intent. In workflows, Event Trigger and Scheduled Trigger start from product events or time-based jobs. Incoming Webhook starts from an HTTP payload sent by another system.
AI & Intelligence nodes do the reasoning work. AI Agent is for analysis, extraction, classification, or response generation. Agent Capture collects structured fields from the conversation. Say sends controlled copy when you do not want model-generated text.
Data & Logic nodes make the process inspectable. Conditional Routing branches on stable values such as intent, score, status, reply behavior, or captured fields. Data Action and Table Action read or write structured records.
Integration nodes connect the process to systems outside the canvas. API Call and Outgoing Webhook should have a clear input, a clear success path, and a failure path that a teammate can inspect in Logs.
Incoming webhook checklist
Use an Incoming Webhook when a form, backend job, billing system, support tool, or other external service needs to start the workflow.
Before going Live, confirm the webhook URL, expected payload fields, example payload, authentication or secret handling, retry behavior, and the fallback branch for missing fields.
The first node after the webhook should make the payload readable: normalize IDs, map the customer or record reference, and stop safely when the external system sends incomplete data.
How to read a workflow on the canvas
Start at the trigger and ask: what real event starts this workflow? In Lead Re-engagement, the customer conversation becomes idle, so the workflow prepares follow-up instead of waiting for a rep to remember manually.
Follow the path node by node. A Send Message node can prepare a WhatsApp follow-up, a Conditional Routing node can branch based on whether the person replied, and an Outgoing Webhook can hand the lead to Sales or another system.
Check the outcome for each branch: message sent, CRM updated, webhook fired, task created, teammate notified, or safe stop. If you cannot name the outcome, the workflow is not clear enough to publish.
Creating a new workflow
Open Workflows in Studio and create a new workflow. Name it after the operational job it performs — 'Lead Qualification', 'WhatsApp Support Triage', 'Appointment Follow-up' — not after the technology it uses.
Add the trigger node first. Everything else in the workflow flows from what the trigger provides. If the trigger does not carry enough context for the workflow to make a decision, fix the trigger before building the rest of the path.
Add nodes one at a time, test after each addition in the Logs view, and keep the canvas readable. A workflow that is too wide or deeply nested to understand at a glance is a workflow that will be hard to debug in production.
A simple build order
1. Choose the trigger and write down what data it provides.
2. Add one AI, capture, data, or routing node that transforms that input into a useful decision.
3. Add the operational action: send a message, update a record, call an API, notify a teammate, or stop safely.
4. Add the failure branch before publishing. Missing context, no match, API error, or ambiguous intent should create an inspectable outcome.
Publishing and managing workflow state
Draft is the editing state. Use it while changing nodes, message copy, routing rules, webhook payloads, or CRM updates.
Live is the production state. Switch to Live only after the trigger, node outputs, failure path, Logs, Analytics, and customer-facing messages have been reviewed.
When making a risky change, return to Draft or pause execution first. Do not test a half-edited workflow on real customers.
Examples worth building first
Lead qualification: trigger from an inbound channel or form, capture intent and company context, qualify with an AI Agent node, then update CRM or hand off to Sales.
Support triage: trigger from WhatsApp or a ticket event, classify urgency, check open tickets, route urgent cases to a teammate, and send controlled confirmation copy.
External event intake: start from an Incoming Webhook, normalize the payload, look up the related record, branch on missing context, and call an external API only after the record is clear.
Workflow design rules
Every node should have one job. If a node both decides, writes data, and sends a customer message, split the work so Logs are easier to read.
Branch on stable values: intent, status, score, reply behavior, payload fields, or captured variables. Avoid branching on long generated text when a structured value is available.
Debugging order
When a workflow fails, inspect the trigger first, then the first node with unexpected input, then branch conditions, integration permissions, API response, and the final action.
If the canvas looks correct but the output is wrong, use Logs to find the exact node that introduced the bad value before editing prompts or adding more nodes.
Workflow guidance
A production workflow should have a clear trigger, explicit node responsibilities, readable branching, useful logs, and a fallback path when payloads, integrations, or AI output are incomplete.
Use the builder canvas as the operating procedure: every node should explain what the workflow knows, what it does next, and where the team can inspect the result.
FAQs
What makes the Workflow Builder operational?
The builder exposes the operating procedure: the customer signal that starts work, the nodes that decide or act, the channel or CRM outcome, the execution logs, the analytics, and the Draft/Live production state.
When should this be a workflow instead of a manual process?
Use a workflow when the same operating path happens repeatedly, needs clear ownership, or depends on AI, routing, integrations, messages, or external events. Keep manual review when judgment or approval is still required.
How do integrations connect to workflow nodes?
Integrations give workflow nodes permission to read context or take action in another system. API Call, Outgoing Webhook, Send Message, and Table Action nodes should each map to a specific operational reason.
What should I check first when a workflow does not run?
Start with the trigger or incoming webhook, then inspect run logs, node status, payload shape, branch conditions, integration permissions, and any AI output used by later steps.
How do I keep AI workflow steps trustworthy?
Give AI nodes narrow jobs, pass only relevant context, prefer structured output, route decisions explicitly, and use logs so teammates can see what input produced which action.
What is the best practice for branching logic?
Branch on stable values such as intent, status, score, reply behavior, payload fields, or captured values. Include fallback paths for missing data and human handoff for ambiguous cases.
How should teams monitor production workflows?
Use logs for individual run debugging and analytics for patterns: trigger volume, failure rate, completion rate, branch distribution, handoff rate, and repeated integration errors.