Skip to main content
Workflow Studio turns a repeated handoff into a durable process. You add steps on the canvas, configure them with forms and upstream-value pills, and inspect every run in the console. This guide builds a Refund triage workflow:
You can build the complete draft without writing JSON.

​
Create The Draft

  1. Open Dashboard > Workflows.
  2. Choose New workflow.
  3. Name it Refund triage.
  4. Open the workflow in Studio.
Studio saves draft edits as you work. Publishing is a separate action, so changing the canvas does not silently change the version used by production runs.

​
Start From A Channel Message

Open the node palette and add a Channel message trigger. In the inspector:
  1. Choose the support channel registration or binding.
  2. Give the step a clear name such as New message in support.
  3. Review the Docs tab to see the fields the trigger makes available.
Later steps can use the trigger’s message and channel fields from their data-in menu.

​
Classify The Request

Add an Agent task after the trigger and name it Classify request.
  1. Choose a support or operations agent.
  2. Write an instruction such as:
  3. Insert the message text from the upstream-values menu. Studio stores the selection as a variable reference and shows it as a pill.
  4. In Returns, add these structured fields:
The declared return fields become available to every downstream step. They also appear on the node card and in its Docs view.

​
Branch On The Result

Add a Condition after Classify request.
  1. Insert Classify request > intent into Value.
  2. Set Comparison to equals and Compare with to refund.
  3. Connect the true port to the approval step.
  4. Connect the false port to the non-refund path you want, such as another agent task or a stop step.
Choose values from the menu instead of typing references such as {{ classify_request.intent }} by hand. The pill keeps the source step and field visible.

​
Ask For Approval

Add a Human approval on the refund branch.
  1. Choose the person or review destination responsible for refunds.
  2. Write the approval question.
  3. Insert the message author, order id, and sentiment as pills.
  4. Set a deadline or escalation only when the process needs one.
For example:
The run pauses at this step until the approval is resolved. Open items also appear in the workflow inbox. Add another Condition after the approval. Insert Approve refund > approved as its value and keep the comparison as truthy. Only its true path may reach the refund action; route false to a rejection message or stop step.

​
Configure The Outcome

On the approval condition’s true path, add the connected-app and notification steps your workspace supports. For a Stripe-style refund flow:
  1. Add a Connector action.
  2. Choose the connected app and refund action.
  3. Map Classify request > order_id into the order or payment field.
  4. Add a Send message step.
  5. Insert the customer, order, and approval result into the confirmation message.
Connector and outbound-action nodes currently record the fully resolved action intent without performing the external side effect. Workspace governance still evaluates the requested operation, so the run console can review the exact intent before live execution is introduced.

​
Test In The Run Console

Choose Test run and provide a representative support message. The canvas and bottom run console show the same run from two angles:
  • node state on the canvas: queued, running, waiting, done, skipped, or failed
  • the path taken through condition and switch branches
  • duration and available usage/cost information
  • a step timeline in the console
  • input and output for the selected step
  • the current wait and assignee when human input is required
Select a node on the canvas or a row in the timeline to inspect that step. If the run is waiting for approval, resolve it from the inbox, then return to the run to see execution continue. Use the run picker to load an earlier test or published run. Historical selection repaints the canvas with that run’s states without changing the draft.

​
Fix Problems Before Publishing

When a test does not behave as expected:
  1. Select the first failed or unexpected step.
  2. Compare its input with the output of the preceding step.
  3. Check that every variable pill points to an upstream field.
  4. Confirm required bindings, agents, approvers, and connectors are available.
  5. Run the draft again.
Validation errors block publishing. Warnings identify risks or setup that deserves review but may not block a test run.

​
Publish The Workflow

Choose Publish when the test path and approval behavior are correct. Publishing creates an immutable workflow version. New production runs use that version, while later Studio edits continue in the draft. This keeps run history explainable even after the workflow changes. Publishing does not silently create an external webhook, schedule, or channel listener. For those trigger types, create or update the trigger registration for the published version through your workspace’s trigger settings. Registration owns authentication, idempotency, and durable scheduling.