Build a workflow
Build a Studio workflow from trigger to action: routing, AI or data steps, CRM updates, channel messages, logs, analytics, and Draft or Live publishing controls.
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.
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 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.
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.
Summary
Build a Studio workflow from trigger to action: routing, AI or data steps, CRM updates, channel messages, logs, analytics, and Draft or Live publishing controls.
Concepts covered
Step breakdown
- Define the triggerChoose the event that starts the workflow and the sample payload used for testing.
- Build the pathAdd action, routing, CRM, channel, API, handoff, and activity nodes in the order the operation needs.
- Verify logsInspect inputs, outputs, errors, and branch decisions before publishing.
- Publish intentionallyKeep Draft while editing and switch to Live only after the sample and failure paths pass.
What you will build
You will build a repeatable workflow path that starts from a clear trigger, runs the right action nodes, records the outcome, and leaves logs that an operator can inspect.
Use a sample lead or support event so the workflow can be tested without customer data.
When to use it
Use Workflow Builder when an operation needs repeatable logic: route a message, qualify a lead, create or update a record, call an API, notify a teammate, or escalate a case.
A workflow is appropriate when the same decision path should run every time a trigger occurs.
Before you start
Define the trigger, the data the trigger provides, the CRM or table record to update, the message or handoff the user should receive, and the failure path.
Prepare sample payloads with placeholder values and no credentials, tokens, private URLs, or customer data.
Step-by-step implementation
Open Studio, then Workflow Builder, and choose an existing workflow to inspect or create a new workflow for the operation.
Confirm the trigger first. It may come from a channel event, a CRM change, a schedule, an Incoming Webhook, or another configured source.
Add or review each node in order: AI step, data lookup, conditional routing, CRM update, channel message, API Call, Outgoing Webhook, teammate assignment, or Max Activity.
Name branches by the decision they represent, such as Qualified, Needs human review, Missing context, or API failed.
Use Logs to inspect node inputs, outputs, and errors. Use Analytics to verify run volume, completion rate, failures, timing, and credits.
Keep the workflow in Draft while editing and move it to Live only after the sample path and failure path are verified.
Which node to use
Start with the node palette. It is the menu of building blocks: triggers, AI & Intelligence, Data & Logic, and Integration nodes.
Use Incoming Webhook when an external product, backend job, form, billing system, or support tool should start the workflow with an HTTP payload.
Use AI Agent when the step needs reasoning, extraction, classification, or response generation.
Use Agent Capture when the agent must collect structured information before the next step can run.
Use Say or Send Message when the copy should be controlled and easy to review.
Use Conditional Routing when the next action depends on a stable value such as status, intent, captured field, reply state, or API result.
Use API Call or Outgoing Webhook when the workflow must talk to another system. Always include a failure path and inspect the payload in Logs.
How to verify it worked
Run the workflow with a sample event and confirm the expected record, channel message, assignment, log entry, and analytics update all appear.
Verify the failure branch too: missing context, invalid payload, API failure, no owner, or ambiguous intent should not disappear silently.
Common mistakes
Do not publish before testing both the happy path and the failure path.
Do not branch on unstable text if a status, intent, score, or structured field is available.
Do not hardcode credentials in nodes; use secure workspace configuration for secrets and placeholders in examples.
Troubleshooting
If the workflow never starts, check the trigger, channel connection, Incoming Webhook payload, and Draft or Live state.
If the workflow starts but takes the wrong branch, inspect node outputs in Logs and confirm variable names match the routing rule.
If the user or teammate sees no result, check the final message, CRM update, assignment, and Max Activity nodes.
Clear next step
Create one sample run, review Logs and Analytics, then document what must happen before switching the workflow from Draft to Live.
Implementation path
1. Open Studio Workflows.
2. Choose the business system to build or inspect, such as Lead Re-engagement.
3. Confirm the trigger: what event starts the workflow and what context enters?
4. Inspect each node: message, agent step, data transformation, conditional route, webhook, table action, or CRM update.
5. Edit one node at a time so the canvas remains debuggable.
6. Test with Logs. Check input, output, status, and failure behavior for each node.
7. Review Analytics for runs, completions, failures, pending work, credits, and timing.
8. Keep the workflow in Draft while editing. Publish Live only after the path has been verified.
What this workflow does operationally
Lead Re-engagement exists so a quiet WhatsApp lead does not disappear. Studio can prepare a follow-up, route based on whether the person replied, and hand off to Sales through a webhook or downstream system.
The workflow is useful because the business outcome is visible: who triggered the path, which message was prepared or sent, which branch ran, whether Sales was notified, and how the team can inspect the run afterward.
Publishing and review
Draft means the workflow is being edited or tested. Live means the workflow can affect production events.
Use Logs as the evidence layer before publishing. Use Analytics after publishing to see whether the system is actually operating well.
Transcript
Open searchable transcript
FAQs
What should I build first?
Start with the trigger and one verified output. Add routing and integrations after the basic path is observable in Logs.
How should I handle API failures?
Create an explicit failure branch, log the error, avoid silent retries, and route to a teammate when the operation needs review.
When should a workflow use an AI agent?
Use an agent when the workflow needs reasoning, extraction, summarization, or a conversational response that rules alone cannot handle.
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.