Running Workflows
Building a workflow is only half the job — the other half is running it and watching what happened.
A run is one single execution of a workflow, from its trigger block all the way to the last step. You can start a run yourself from the editor while you're still building, and you can let the workflow start itself from a schedule, a webhook, a chat conversation, or an external request.
This page covers both: how to run a workflow by hand, and how to set up the ways it can start on its own.
Running It Yourself
The fastest way to test a workflow is to run it from the editor.
- Open the workflow.
- Click Run in the side panel header — or press Ctrl/Cmd + Enter.
You'll see the message Run started — see it in the Logs tab. The run continues in the background, so you can keep editing, switch tabs, or leave the page entirely.
When Run is greyed out
Run only works when a few conditions are met. If the button is dim, hover it — the tooltip tells you exactly which one is missing.
| Tooltip | What to do |
|---|---|
| Save your changes first | The canvas has unsaved edits. Click Save (or press Ctrl/Cmd + S), then run. |
| Add at least one block first | The canvas is empty. Add a block — see Creating Workflows. |
| Copilot is building — please wait | The Copilot is editing this workflow right now. Wait for it to finish. |
A run always uses the saved version of the workflow, not what is currently on screen. That's why unsaved edits block the Run button — so what runs is always what you can see.
While a run is in progress the Run button turns into Stop (and shows Stopping… while it cancels).
Providing Inputs
Most workflows need some starting data — a customer name, a report date, a message to process. That data comes from the trigger block, and every later block can read it.
Defining inputs on the Start block
The Start block carries an Input section. It lives under Show additional fields in the block's configuration view (double-click the block, or use Open details in its hover tray).
Add one field per piece of data you need:
| Field | What it's for |
|---|---|
| Name | The name later blocks use to read this value (placeholder field_name). |
| Type | How the value should be read: string, number, boolean, object, or array. |
| Value | A test value used when you click Run in the editor (placeholder Test value). |
Use the + button to add another field, the trash icon to remove one, and the chevron to collapse a field you're done with.
There is no separate "run" dialog. The Input section is the form — clicking Run sends whatever you typed into the Value boxes. Fields left without a Name are ignored.
Reading inputs in later blocks
Anywhere in the workflow, reference a trigger input by its name:
<input.NAME>
So a field named customerEmail is read as <input.customerEmail>. The same syntax works no matter how the run started — a manual Run, a webhook delivery, a schedule, or a chat request all fill the same <input.*> slot.
Values arrive as the Type you picked: choose number and 42 arrives as a number; choose object or array and JSON text is read as structured data.
Inputs are only one of the three things a block can reference. You can also read an earlier block's result with <blockName.field> (for example <agent.content>) and a stored workflow variable with <variable.NAME> — see Variables.
Watching a Run
As soon as a run starts, a thin status strip appears under the panel header and keeps itself up to date until the run finishes.
The strip shows:
- The current status as a coloured badge.
- {n} steps recorded — how many steps have completed so far.
- The duration, once the run has finished.
- The error message, if the run failed.
Run statuses
| Status | Meaning |
|---|---|
| Queued | Accepted and waiting to begin. |
| Running | Steps are executing right now. |
| Completed | Finished successfully. |
| Failed | A step failed — the message tells you what went wrong. |
| Cancelled | You stopped it. |
| Paused | Waiting on something before it can continue. |
Run controls
| Control | When it appears | What it does |
|---|---|---|
| Resume | Only while the run is Paused | Continues the run from where it stopped (shows Resuming…). |
| Stop | While Queued, Running, or Paused | Cancels the run (shows Stopping…). |
| × (dismiss) | Always | Hides the strip. It does not stop the run. |
The × only hides the status strip from your screen — the run keeps going in the background. Use Stop if you actually want to cancel it.
When a run pauses for a connection
If a step needs a connection that is missing, rejected, or expired, the run pauses instead of failing outright, and an amber banner appears under the status strip:
Credential required — {provider}
What you can do next depends on the connection type:
| Situation | What the banner offers |
|---|---|
| An API key connection that can be fixed in place | An Update key button. Enter the new key, then click Resume — the run picks up where it left off. |
| The connection can't be matched to the block | A prompt to re-select a credential on the named block (the block name is a link that opens it), then run again. |
| A connected account (sign-in based) | A note that reconnecting from here isn't available yet — reconnect the account under Connections and run again. |
See Connections for how connections are added, tested, and repaired.
Seeing the full picture
The status strip is a glance, not a report. For the step-by-step detail of any run — what each block received, what it returned, and exactly which step failed — open the Logs tab. See Logs.
Active vs Paused Workflows
A manual Run from the editor always works, whatever state the workflow is in. Automatic triggers are different: they only fire when the workflow itself is Active.
On the Workflows page, hover a workflow card and use the toggle:
- Activate — arms every automatic trigger on that workflow.
- Deactivate — disarms them. Schedules stop firing, webhook deliveries are dropped, and the workflow can no longer be started from chat.
Building a workflow is not enough to make it run on its own. Until you activate it, a schedule will tick past it and a webhook delivery will be discarded — silently, because the sender is never told.
Ways a Workflow Can Start
Add the trigger you want as the first block in your flow. A workflow can have more than one entry point.
| Trigger | How it starts | What it gives the workflow |
|---|---|---|
| Start (manual) | You click Run in the editor | The test values you typed into its Input fields |
| Schedule | Automatically, on a recurring schedule — see Schedules | Nothing extra; the workflow runs unattended |
| Webhook | An outside service sends a request to the block's address | The request's body, headers, path, arrival time, and caller address |
| Chat Trigger | From a conversation with an AI assistant, after you approve | The message you sent, plus recent conversation if enabled |
| API Trigger | An external request calls the workflow | The request's body, headers, and query values |
| Telegram Trigger | Your Telegram bot receives a message | The message, its sender, and the update details |
| Slack Trigger | Your Slack app receives an event you subscribed to | The message, its sender, channel, and event details |
| WhatsApp Trigger | Your WhatsApp Business number receives a message | The message, its sender, and the number it arrived on |
| Gmail Trigger | New email arrives in a connected Gmail inbox (checked periodically) | The message and its sender |
| Outlook Trigger | New email arrives in a connected Outlook / Microsoft 365 inbox (checked periodically) | The message and its sender |
For what each trigger block offers, see Blocks.
Webhook Triggers
A Webhook block lets an outside service start your workflow — a form submission, a payment event, an alert from another tool.
Open the Webhook block's configuration to find everything you need in one panel.
The address
The webhook's address is created automatically the first time you open the block's panel — there's no "generate" button to remember. It appears in a copy-ready box with a copy button next to it. Paste it into the sending service.
The signing secret
Next to the address sits the signing secret, which proves a request really came from the service you expect.
The signing secret is shown only once — right after it's created or rotated:
Copy this secret now — it will not be shown again. Rotating invalidates the old secret immediately.
After that the panel just shows dots and the note "The signing secret is shown only when created or rotated." If you lose it, rotate to get a new one.
Rotate replaces the secret. It's a deliberate two-step action: click Rotate, then click Confirm? within a few seconds (an × cancels, and the confirmation disarms itself if you walk away). The old secret stops working the moment you confirm — update the sending service straight away.
Requirements for a delivery to be accepted
Every incoming request must be signed by the sender, using the recipe printed at the bottom of the panel: a timestamp header plus a signature header built from your signing secret. Requests that aren't signed, or that are more than 5 minutes old, are dropped.
Webhook data comes from outside your organization. Treat every <input.*> value as untrusted — especially when you feed it into an AI prompt.
Pausing a webhook
The panel shows the webhook's own state — Active (green dot) or Paused (grey dot) — with a Pause / Resume button next to it.
A paused webhook quietly drops everything it receives. Resuming it starts accepting deliveries again and clears the rejected-delivery counter.
Rejected deliveries
Senders are never told when a delivery is refused, so this panel is where you find out. When requests are being rejected, an amber warning appears:
{n} rejected deliveries since the last accepted one (last: …). Check the sender's signature, timestamp and IP.
That usually means the sender is signing with the wrong secret, its clock is off, or it is calling from an address that isn't allowed.
Recent deliveries
Under Recent deliveries you'll see the latest webhook-started runs, each with its status and time — the quickest proof that a delivery actually arrived and did something. "No webhook-triggered runs yet." means nothing has reached the address so far.
Slack Trigger
A Slack Trigger block starts your workflow when your Slack app receives an event you've subscribed to — a new message, a mention, a reaction, and more.
Setting it up
- Create a Slack app at
api.slack.com/appsand copy its Signing Secret (Basic Information → App Credentials). - In the block, pick (or add) a connection holding that Signing Secret. The block then shows a Request URL automatically — there's no "generate" button.
- In your Slack app, open Event Subscriptions, turn it on, and paste in the Request URL. Slack verifies it instantly.
- Under Subscribe to bot events, add the events you want (for example
message.channels,app_mention,reaction_added), then Save Changes and reinstall the app.
Once the Request URL exists the block reads Trigger ready — Slack has no ongoing "connected" status to check, so that message is as far as the confirmation goes; matching events start the workflow from that point on.
:::note One app, one workflow Each Slack app connects to a single workflow. If the Signing Secret changes, the block shows a Reconnect button to re-issue the Request URL. :::
Slack events come from outside your organization. Treat <input.message.text> as untrusted, especially inside AI prompts.
WhatsApp Trigger
A WhatsApp Trigger block starts your workflow when a message arrives on your connected WhatsApp Business number.
Setting it up
- In the block, enter your Meta app's App ID and pick a connection holding its App Secret.
- Activate the workflow. Unlike Slack, you don't paste a URL anywhere — the block registers itself with Meta automatically once both values are set and the workflow is active.
- The block shows a status: Connected once Meta confirms the subscription, or a failure notice if it couldn't.
If the App ID or App Secret changes, reconnect from the block to re-register the subscription.
WhatsApp messages come from outside your organization. Treat trigger data as untrusted, especially inside AI prompts.
Email Triggers (Gmail and Outlook)
A Gmail Trigger or Outlook Trigger block starts your workflow when new email arrives in a connected inbox.
- Connect your Google or Microsoft account under Connections — this is the same sign-in used by other Google/Microsoft blocks.
- Pick that connection in the trigger block.
- Optionally turn on Include email body (off by default) to receive the full message text, and add a search filter to narrow which emails trigger the workflow.
Neither checks instantly — the inbox is checked about once a minute. Outlook sometimes reacts sooner, when Microsoft can give it a head start.
Running from Chat
A workflow that has a Chat Trigger block can be started straight from a conversation:
"Run the weekly sales report workflow"
The assistant never runs it silently. It shows a confirmation card headed Action Requires Approval, with the note "This will run one of your workflows on your behalf.", the Workflow it picked, and any Inputs it wants to pass. Nothing happens until you click Approve — Cancel rejects it.
What gets passed in
You don't need to repeat yourself. The message you just sent is handed to the workflow automatically, and if the Chat Trigger has Include chat history turned on, recent conversation goes with it — but only when the workflow is your own (or you're an admin), so your conversation never travels into someone else's workflow. Anything extra the assistant passes is readable inside the workflow as <input.NAME>, exactly like a manual run.
What has to be true first
| Requirement | Why |
|---|---|
| The workflow contains a Chat Trigger block | It's the workflow author's opt-in — without it, the workflow can't be reached from chat. |
| The workflow is Active | Chat is an automatic trigger. An inactive workflow is refused with a message telling you to activate it on the Workflows page. |
| Your admin allowed workflow running for the assistant | Running workflows is an admin-controlled assistant capability. |
| You have permission to run that workflow | You only ever see workflows you're allowed to start. |
| You approve the card | The final confirmation is always yours. |
See Using Tools for how the assistant asks for approval in general.
After the Run
Every run — manual, scheduled, webhook, or chat — is recorded. Open the Logs tab to review it:
- Filter by workflow, status, or trigger to find the run you want.
- Open a run to see each step's input and output, and jump straight to the step that failed.
- Use Re-run to run it again with the same starting data.
See Logs for the full walkthrough.
Most failed runs aren't broken blocks — they're data problems. A reference like <input.email> or <agent.content> pointed at something that wasn't there. The per-step input and output in the run detail is the fastest way to spot exactly where the value went missing.
Tips
- Test with the Run button first. Get a clean manual run before you attach a schedule or hand the address to an outside service.
- Fill in test values. A Start block input with no Value means your test run starts with nothing, and downstream references come up empty.
- Remember to activate. A workflow that runs perfectly from the editor still won't fire on its own until it's Active.
- Name your blocks clearly. Block names are what you read in the run detail — and what you type in
<blockName.field>references. - Copy the webhook secret immediately. It's shown once. Rotating is easy, but it means updating the sender too.
- Check the Logs tab after each run to confirm the workflow did what you expected, not just that it finished.
Related Pages
- Creating Workflows — build the flow you're about to run
- Blocks — what each trigger and step does
- Variables — store and reuse values across a run
- Connections — set up and repair the connections a run needs
- Schedules — run a workflow unattended, on a recurring schedule
- Logs — review every run, step by step