> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superember.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Build a workflow

> Build, test, and publish a workflow in Studio using guided configuration and the run console.

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:

```text theme={null}
Channel message
  -> Agent task: classify the request
  -> Condition: is it a refund?
  -> Human approval
  -> Condition: was it approved?
     -> true: Connector action -> confirmation
     -> false: Rejection message -> stop
```

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](/reference/workflow-node-reference#trigger-channel-message).

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](/reference/workflow-node-reference#agent-task) after the trigger and name it **Classify request**.

1. Choose a support or operations agent.

2. Write an instruction such as:

   ```text theme={null}
   Classify this support request. Identify the intent, sentiment, and order id.
   ```

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:

   | Field       | Type   | Purpose                                    |
   | ----------- | ------ | ------------------------------------------ |
   | `intent`    | string | The request category, such as `refund`.    |
   | `sentiment` | string | The customer's tone.                       |
   | `order_id`  | string | The order identifier found in the message. |

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](/reference/workflow-node-reference#flow-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](/reference/workflow-node-reference#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:

```text theme={null}
Customer [message author] requested a refund for [order id].
Sentiment is [sentiment]. Approve the refund?
```

The run pauses at this step until the approval is resolved. Open items also appear in the workflow inbox.

Add another [Condition](/reference/workflow-node-reference#flow-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](/reference/workflow-node-reference#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](/reference/workflow-node-reference#action-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.

## Related Pages

* [Workflow concepts](/concepts/workflows)
* [Workflow node reference](/reference/workflow-node-reference)
* [Run history and approvals](/operations/run-history-and-approvals)
* [Approvals, review, and inbox](/product/approvals-and-inbox)