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

# Workflows

> Create and monitor dashboard automations that run from events, AI requests, or HTTP calls.

Workflows let you automate multi-step processes in Remark. A workflow starts from a trigger, passes data through connected steps, and records each run so your team can review what happened.

Use workflows when a process needs more structure than a single [action](/dashboard/actions). For example, a workflow can prepare data, call an integration action, branch around missing context, or reuse another published workflow.

<Note>
  Workflows appear only for workspaces where the feature is enabled. Available triggers, steps, production run controls, and integration actions can vary by workspace configuration.
</Note>

## Workflow list

Open **Workflows** in the Dashboard to view existing workflows.

From the list, you can:

* Search by workflow name
* Filter by **Draft**, **Published**, or **Disabled**
* Create a workflow
* Edit a workflow
* View workflow runs
* Duplicate a workflow
* Delete a workflow

Each workflow also shows whether it has run before. Published workflows show the most recent published run when available.

## Create a workflow

1. Open **Workflows**.
2. Select **Add workflow**.
3. Enter a name.
4. Add one or more triggers to the **Start** node.
5. Add steps from the step panel and connect them in the order they should run.
6. Configure each step's inputs, conditions, mocks, and outputs as needed.
7. Test the workflow with mock input.
8. Publish the workflow when it is ready to run from its configured triggers.

The editor autosaves draft changes. Publishing promotes the latest saved draft so it can be used by live triggers.

## Workflow statuses

| Status    | Meaning                                                                      |
| --------- | ---------------------------------------------------------------------------- |
| Draft     | The workflow has not been published, or it was unpublished back to draft.    |
| Published | The workflow can run from its configured triggers.                           |
| Disabled  | The workflow remains published, but triggers are paused until it is resumed. |
| Archived  | The workflow is read-only and no longer active.                              |

Use **Pause runs** to stop triggers from firing for a published workflow. Use **Resume runs** to allow triggers to fire again. Draft and archived workflows cannot be paused or resumed.

## Triggers

Triggers define when a workflow starts. Configure triggers from the **Start** node.

| Trigger type | Use it for                                                                                                                                                                                |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Event        | Run from supported Remark events, such as conversation started, reopened, closed, escalated, message sent, internal note added, product recommended, idle warning, or escalation failure. |
| AI           | Let the AI assistant invoke the workflow during a chat when the trigger instructions match the shopper request.                                                                           |
| HTTP         | Start a published workflow from an external system with a POST request.                                                                                                                   |

Each trigger can include:

* A name
* Optional conditions that decide whether the workflow should run
* Input mapping that transforms trigger data into the workflow input
* Trigger-specific configuration, such as AI instructions or the selected event

HTTP triggers use the endpoint shown in the trigger panel:

```bash theme={null}
curl -X POST 'https://api.withremark.com/api/v1/workflow/<workflowId>/execution' \
  -H 'Authorization: Bearer <VendorApiKey>' \
  -H 'Content-Type: application/json' \
  -d '{}'
```

The vendor API key must include the **Triggers workflows** permission. The JSON body is available to the trigger input mapping.

## Steps

Steps are the work a workflow performs after it starts. Add steps from the **Steps** panel, then connect them on the canvas.

Available steps can include:

| Step type           | What it does                                                                                                                                                |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Integration actions | Runs workflow-supported [actions](/dashboard/actions) from connected integrations. The exact actions depend on the integrations enabled for your workspace. |
| Transform           | Converts workflow data into a new shape for later steps.                                                                                                    |
| HTTP                | Sends an HTTPS request and returns the response status, success flag, and response body.                                                                    |
| LLM                 | Generates text or structured JSON from a prompt.                                                                                                            |
| Workflows           | Runs another published workflow as a sub-workflow.                                                                                                          |
| Note                | Adds documentation to the canvas. Notes do not run.                                                                                                         |

Some workspaces can also have browser-session steps for conversation-specific workflows. Use those only when the workflow is explicitly designed around an active shopper conversation.

## Step configuration

Most runnable steps have the same configuration concepts:

| Section    | Use it for                                                         |
| ---------- | ------------------------------------------------------------------ |
| Notes      | Document what the step is meant to do.                             |
| Conditions | Run the step only when specific data is present or a rule is true. |
| Inputs     | Build the data passed into the step.                               |
| Outputs    | Describe or configure the data the step returns.                   |
| Mocks      | Provide sample output for safe test runs.                          |

The **Start** node can also define the workflow input shape and mock input. Use these fields to make tests realistic before the workflow is published.

## Test and run

Use **Test** to run the latest draft with mock data and no real side effects. Test runs are useful for checking input mapping, step order, conditions, and expected outputs.

Use **Run** only when you want a production-style manual execution with real side effects. Run controls appear only when production workflow execution is enabled for the workspace. A workflow must be published before it can run with real side effects.

## Runs

Open the **Runs** tab to review workflow executions.

Runs can have these statuses:

| Status    | Meaning                                                        |
| --------- | -------------------------------------------------------------- |
| Pending   | The run has been created and is waiting to start.              |
| Running   | The workflow is currently executing.                           |
| Completed | The workflow finished successfully.                            |
| Failed    | The workflow stopped because a trigger, input, or step failed. |
| Cancelled | The run was cancelled before completion.                       |

The run detail view shows the trigger type, trigger data, workflow input, workflow output, duration, errors, and per-step results. Select a step in a run to inspect its input, output, status, duration, error message, and retry attempts when available.

## Troubleshooting

### A workflow did not run

Check that the workflow is published, not disabled, and has at least one trigger configured. If the trigger has conditions, confirm the trigger data satisfies those conditions.

### An HTTP trigger returns an error

Confirm the request uses `POST`, sends `Authorization: Bearer <VendorApiKey>`, and uses a vendor API key with **Triggers workflows** permission. The workflow must be published and have an HTTP trigger.

### A run failed

Open the run detail and inspect the failed step. Check the step input, output, error message, and any trigger data shown on the Start node. For integration actions, also confirm the connected integration is healthy and the action supports workflows.

### A step did not run

If a step is skipped, review its condition and the outputs from earlier steps. Notes are canvas-only and never appear as executed steps.

## Related pages

* Use [Intents](/dashboard/intents) when the AI needs a customer-facing playbook for a shopper scenario.
* Use [Actions](/dashboard/actions) to understand the single-step capabilities that intents and workflows can call.
* Use [Inbox](/dashboard/inbox) to review the conversations that can trigger AI or event-driven workflows.
* Use [Playground](/dashboard/playground) to test AI behavior before relying on it in live conversations.
* Use [Custom Integrations](/integrations/custom-integrations/overview) when a workflow depends on external commerce, support, sizing, or order data.