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 form, a new email, a file, 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. |
| You don't have permission to run this workflow | Running is a separate permission from editing. Ask your administrator. |
A run you start with Run always uses the saved state 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. It runs your latest saved edits even if they haven't been published yet — see Publishing changes.
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 details 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
A run you start from the editor shows up in the Logs dock along the bottom of the editor. Click the dock's header to open it if it is collapsed; it keeps itself up to date until the run finishes.
The first row of the dock is the run's status row. It 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.
Below it, every block that ran gets its own row; click one to read that block's Output and Input. The dock is described in full in Toolbar.
When the run ends you also get a short message wherever you are in the editor: "Run completed — open the Logs tab for the output.", "Run failed — open the Logs tab for the error." or "Run cancelled."
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 — a connection, or a person. |
Run controls
| Control | When it appears | What it does |
|---|---|---|
| Resume | While the run is Paused for a connection | Continues the run from where it stopped (shows Resuming…). It is not offered while the run waits for a person. |
| Stop | While Queued, Running, or Paused | Cancels the run (shows Stopping…). |
| × (dismiss) | Always | Hides the run from the dock. It does not stop the run. |
Resume and Stop each need their own permission; without it the button is greyed out and its tooltip says so.
The × only hides the run 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 row:
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 and the run resumes on its own. |
| 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.
When a run waits for a person
Some steps hand the run to a person and wait: the next page of a form, or an approval. The run shows Paused, and an amber banner says what it is waiting for:
| Banner | What continues the run |
|---|---|
| "Waiting for the person filling in the form, until … . Their answer continues the run." | The person sends the form page — see Forms |
| "Waiting for approval, until … . The approvers' decision continues the run." | The approvers decide — see Approvals |
There is no Resume button for these runs: only the person's answer continues them. You can still Stop the run. In the block log, the waiting step carries a Waiting for a response badge.
When a run is blocked from reaching an address
If a block tried to reach an outside address that your organization hasn't allowed, the run fails and a red banner names the cause — for example "Blocked — api.example.com is not on the allowed list" — followed by "The block was stopped before it could reach the network, so this is a permission, not a fault in the code."
Click See which addresses on the banner. It opens the Logs tab, where the failed step's error card lists every refused address. (With unsaved edits you are first asked whether to discard them.) An administrator can allow those addresses under Workflows → Packages, below the package list — see Packages.
A similar banner explains a step that couldn't read or write a file in the shared folder — see Shared Folder.
Seeing the full picture
The dock follows the run you just started. For the step-by-step detail of any run — including ones started by a schedule, a webhook, or another person — open the Logs tab on the Workflows page. See Logs.
Active vs Inactive 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 — publishes the workflow and arms every automatic trigger on it. You see "Workflow activated — triggers armed".
- Deactivate — disarms them. Schedules stop firing, webhook deliveries are dropped, and the workflow can no longer be started from chat. You see "Workflow deactivated — triggers paused".
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.
When a workflow won't switch on
Switching a workflow on publishes it, and Arketic checks it first. If a check fails, the workflow stays Inactive and a message names each problem, for example:
- an approval step that sits inside a loop or a parallel branch,
- a form that has no title or no fields,
- an API trigger that has no input schema,
- steps that are connected in a loop.
The message stays on screen until you close it. Fix what it names, save, and switch the workflow on again.
Publishing changes
Once a workflow is Active, there are two copies of it: the published version that the triggers run, and the saved draft you are editing. Saving an edit updates only the draft.
| How the run starts | What runs |
|---|---|
| Run in the editor | Your latest saved draft |
| A trigger test from the editor | Your latest saved draft |
| A schedule, webhook, API call, form, chat request, or any other automatic trigger | The published version |
To put saved edits live:
- Open the active workflow in the editor and make your changes.
- Click Save. An amber Unpublished changes strip appears next to the workflow title.
- Click Publish changes on the strip.
- You see "Changes published · version N". From now on the triggers run this version.
If a check fails, a message starting "Couldn't publish:" names what to fix, and the triggers keep running the previous version. Every control on the strip is described in Toolbar.
:::tip Edit safely while the workflow keeps running Because saved edits wait as a draft, you can rework an active workflow in several sittings, test it with Run, and publish only when it's ready. Nothing changes for the people and systems that trigger it until you click Publish changes. :::
The Copilot's edits land in the draft too. On an active workflow, publish them the same way once you are happy with what it built.
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 |
| Webhook | An outside service sends a signed request to the block's address | The request's body, headers, path, arrival time, and caller address |
| API Trigger | Another system calls the block's address with its token | The request's body, headers, and query values |
| Form Trigger | Someone fills in and sends the form — see Forms | The answers, and who sent them |
| Shared Folder Trigger | A file arrives in a watched folder of the shared folder (checked every minute) — see Shared Folder | The file's path, name, size and extension |
| Gmail Trigger | New email arrives in a connected Gmail inbox (checked every minute) | The message and its sender |
| Outlook Trigger | New email arrives in a connected Outlook / Microsoft 365 inbox (checked every minute) | The message and its sender |
| IMAP Trigger | New email arrives in a mailbox on an IMAP server (checked every minute) | The message and its sender |
| 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 |
| Chat Trigger | From a conversation with an AI assistant, after you approve | The message you sent, plus recent conversation if enabled |
| Error Trigger | Another workflow that names this one as its error workflow fails | Which workflow failed, which run, and the error |
For what each trigger block offers, see Blocks.
:::info Schedules are not a block To run a workflow on a recurring schedule, you don't add a block — you attach a schedule to the workflow on the Schedules tab. The scheduled run starts the workflow with no extra input. See Schedules. :::
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
Under 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.
Testing with a real event
You don't have to switch the workflow on to try a webhook. The panel can catch one real delivery and run your saved draft with it.
- Save the workflow.
- In the Webhook block's panel, click Listen for a test event.
- The panel shows "Listening for one test event — … left" with a countdown, and a test address. Send one signed request to that address — not to the normal one.
- When it arrives you see "Test event received — the test run started. Follow it in the editor's Logs."
The test run uses your saved draft and runs as you, whatever is published. If nothing arrives before the countdown ends, the panel says "No event arrived. Listen again when the sender is ready." — click Listen again. Stop listening ends it early. These runs are labelled Test in Logs.
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.
API Trigger
An API Trigger block gives the workflow an address that another system can call to start it — and, if you want, to get an answer back.
The address and the token
The address is created automatically the first time you open the block's panel, with a copy button beside it. Under it sits the trigger token the caller must send.
The token is shown only once — right after it is made:
Copy this token now — it will not be shown again. A new token stops the old one at once.
After that the panel shows dots and the note "The token is shown only when it is made. Make a new one if you lost it."
New token replaces it in two steps: click New token, then Confirm? within a few seconds (the × keeps the current token). The old token stops working at once, so update the caller straight away.
How a call works
The panel prints an example call you can copy. In short:
- The caller sends the token in the request's
Authorizationheader. - The request body must match the block's Input schema — the description of the data every call must carry. It is checked on every call.
- By default the call is answered immediately with the run's id. The caller can instead ask to wait up to 30 seconds for the run; if the workflow has a Response block, its answer is sent back.
- Each call runs the published version, as the person who published the workflow and with their connected accounts.
:::caution An input schema is required to publish A workflow with an API Trigger can't be switched on, or published, until the block has an Input schema. The message names the block: "API trigger … needs an input schema: the body every call must match". :::
Values from a call arrive as <input.*>. They come from outside your organization — treat them as untrusted, especially inside AI prompts.
Pausing, rejected calls and recent calls
| In the panel | What it tells you |
|---|---|
| Accepting calls / Paused, with Pause / Resume | Whether the address answers at the moment |
| An amber warning about rejected calls | Calls arrived without the current token. Check that the caller sends this trigger's current token |
| Recent calls | The latest runs started through this trigger, with status and time. "No runs started from this trigger yet." means nothing has called it |
| Listen for a test event | Catches one real call to the test address and runs your saved draft as you — the same as for a webhook |
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, Outlook and IMAP)
A Gmail Trigger, Outlook Trigger or IMAP Trigger block starts your workflow when new email arrives in a mailbox.
Gmail and Outlook
- 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 fill in Filter (optional) to narrow which emails trigger the workflow.
IMAP
Use the IMAP Trigger for a mailbox on any other mail server.
| Field | What to enter |
|---|---|
| IMAP server | The server's address, for example mail.company.com. It must be reachable from the internet; internal addresses are refused |
| Port | 993 (TLS) or 143 (STARTTLS) |
| Folder | The mailbox folder to watch, for example INBOX |
| Mailbox account | A stored user name and password — an app password where two-step sign-in is on |
| Include email body | Off by default: only the subject, sender and a short preview reach the workflow |
To try it before switching the workflow on, click Fetch the latest email in the block. It reads the newest email in the folder and starts a test run of your saved draft with it; the trigger's place in the mailbox does not move. An empty folder answers "The folder is empty — nothing to test with yet."
What all three have in common
- The mailbox is checked once a minute, and only while the workflow is Active. The block reads "Watching for new email — checked every minute." when it is working.
- One connected account drives one workflow.
- After repeated failures the block shows "This trigger was paused after repeated failures". Reconnect the account, then press Start again.
- Anyone can send email to a mailbox. Treat the message as untrusted, especially inside AI prompts.
Form, Folder and Error Triggers
Three more triggers have pages of their own, or are set up elsewhere:
| Trigger | In short | Read more |
|---|---|---|
| Form Trigger | You design a form in the block; the workflow gets a link people open to fill it in. Each sent form starts one run of the published version | Forms |
| Shared Folder Trigger | Watches one folder of your organization's shared folder and starts one run for each file that arrives | Shared Folder |
| Error Trigger | Starts when another workflow's automatic run fails. You choose which workflows report to it under Workflow settings → Error workflow in each of them | Toolbar |
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, form, 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 start the workflow again as a manual run.
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 and the API token immediately. Each is shown once. Replacing one 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
- Forms — start or continue a workflow with a form
- Approvals — steps that wait for someone's decision
- Schedules — run a workflow unattended, on a recurring schedule
- Logs — review every run, step by step