Workflow Automations
Workflow Automations let you set up work that runs on its own. An automation is a trigger (what starts it) plus an ordered list of actions (what it does). You build one by describing it in chat, or by setting it up in the Trigger panel and the action list.
Automations are a Runnit Studio artifact type, built and listed alongside your pages, widgets, and forms.
Build with the agent
Section titled “Build with the agent”Open the automation editor and describe what you want in the chat panel, for example “every Monday at 9am, email me a summary of all active projects”. The agent builds the trigger and the actions for you and shows them on the canvas.
You can keep refining in chat (“change it to Tuesdays”, “also create a task”, “send it to the project owner instead”). Each change updates the canvas and the panels straight away. If a conversation gets very long, start a fresh chat from New in the chat panel for the cleanest result.
You can also build by hand: choose a trigger in the Trigger panel, then use the Add action buttons to place actions and connect them on the canvas.
Triggers
Section titled “Triggers”Choose how the automation starts in the Trigger type list.
| Trigger | When it runs |
|---|---|
| Event | Automatically, when something happens in Runnit (for example a brief is approved or a project is created). You can add a filter so it only runs for matching events. |
| Manual | On demand. You press a Run button, or run it from chat. It can collect inputs first. |
| Schedule | On a recurring cron schedule, in UTC. For example 0 9 * * 1 is 9am every Monday. |
| Webhook | When an external system sends a signed HTTP request to the automation’s inbound URL. |
Schedule and webhook automations run without a person triggering them, so they need a user to run as. Runnit sets the person editing the automation as the default, and you can change this in the trigger settings.
Inbound webhooks
Section titled “Inbound webhooks”When you choose the Webhook trigger and publish, the editor shows the inbound URL, the accepted HTTP methods, the authentication method, and the signing secret. You can choose how callers authenticate (a signature, a token header, HTTP basic, or none), copy a ready-made example request, send a test call, and rotate the secret. The request body and query string arrive as data your actions can use.
Actions
Section titled “Actions”Add one or more actions and connect them in the order you want them to run.
| Action | What it does |
|---|---|
| Sends an email. The body can be plain text or HTML. | |
| Create tasks | Creates one or more tasks on a project, with dates, priority, and assignees. |
| Notify | Posts a comment on a task. |
| Update fields | Updates allowed fields on a project or task. |
| System tool | Runs a reviewed Runnit action (for example reading projects, costs, or assets, or writing to an asset collection). |
| HTTP request | Calls an external system over HTTP, with optional authentication from a stored credential. |
| AI step | Sends a prompt to the workspace AI and passes the response to later actions. The prompt can include values from earlier steps, and you can request structured fields instead of plain text. |
| Loop | Repeats its inner actions once for each item in a list. |
| Branch | Routes to different actions based on conditions (if / else). |
Actions can pass data to each other, and you can insert values from the trigger
or earlier actions using {{ }} placeholders. Each action runs under the
permissions of the user the automation runs as, so an automation can never do
more than that person could do by hand.
Publish and make changes
Section titled “Publish and make changes”An automation runs the published version, not your working draft.
- Set the trigger and actions.
- Use Validate and Dry-run to check it.
- Press Publish to make it live.
A dry-run previews what each action would do without doing it, including the prompt an AI step would send. A test run performs the actions for real, including calling the AI. AI step usage is recorded on the AI Usage page, where administrators can also choose the model it uses.
After you edit a published automation, press Publish changes to push your edits live. Until you do, the live version keeps running the previously published setup.
See what ran
Section titled “See what ran”Switch to Executions to see every run, including scheduled and event runs. Select a run to inspect each step, its status, and its inputs and outputs, so you can confirm an automation did what you expected or see exactly where it stopped.
Turn it on and off
Section titled “Turn it on and off”Use Disable to pause a published automation without deleting it, and Enable to resume. A disabled automation does not run on its trigger.