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. Pick a timezone and the schedule follows that clock, daylight saving included; without one it runs in UTC. For example 0 9 * * 1 is 9am every Monday. You can also press Run to fire it immediately. |
| 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 in Production. The body can be plain text or HTML. Demo, sandbox, and training datasets run the step without sending email. | |
| Create tasks | Creates one or more project tasks. Only the name is required; dates, priority, estimate, and assignee are optional. |
| Notify | Posts a comment on a task. |
| Update fields | Updates allowed fields on a project or task. It cannot set a project’s status to archived (archiving is a permission-gated action in the app), and archived projects reject updates. Moving a project to a done, completed, or cancelled status applies your organisation’s default incomplete-task handling; if the policy blocks the change, the step fails and the reason appears in the run trace. |
| 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. |
| Ru task | Gives Ru, the Runnit assistant, a goal to complete on its own, such as reviewing project health or researching before creating follow-up work. Ru’s answer passes to later actions. See Ru tasks below. |
| 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. The placeholder {{app.baseUrl}}
always holds your workspace’s own address, so an email can link straight to a
page, for example {{app.baseUrl}}/projects/… for a project. Dates from the
date() and datetime() placeholders follow the automation’s timezone: the
schedule trigger’s timezone when one is set, otherwise your organisation’s
timezone. {{date(now)}} in a 7am Sydney run gives Sydney’s date, and
{{app.timezone}} holds the timezone name. 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.
Use a name-only Create tasks action to capture meeting follow-ups as backlog work. It stays visible under Unscheduled in Project Gantt and does not consume capacity until dates are added.
Ru tasks
Section titled “Ru tasks”A Ru task action asks Ru, the same assistant you talk to in chat, to complete a goal without anyone watching. Write the goal like a short work brief: what to do, what to look at, and what the final summary must contain. Pair it with a Schedule trigger for recurring jobs such as a weekly agency health check, a project review with a summary emailed to you, or research that ends in a new task on a project.
Choose what Ru may do while it works:
- Read-only (the default) lets Ru research, review, and report. It can read projects, tasks, schedules, clients, assets, and public web pages, and write report files into the run’s own output collection, but it cannot change anything else.
- Standard also lets Ru create and update projects, tasks, milestones, comments, brief drafts, and asset files. With standard access Ru can also place “ask Ru” links in emails it drafts, for example next to each item in a daily briefing. Clicking one opens the app on the related record with the suggested request ready in a new Ru chat: you review it first, then send it as is, edit it before sending, or dismiss it. Nothing runs until you choose. The link works only for the person the briefing was made for.
Ru runs as the automation’s executing user, and every tool call is checked against that person’s permissions. Deleting things, generating images or video, and calling external integrations are never available to a Ru task, whichever option you choose.
You can also scope the task to a project or client so Ru starts with that context, and set a step budget for how much work it may do. Each automation can contain one Ru task, it cannot sit inside a Loop, and a scheduled automation with a Ru task must have its runs at least 15 minutes apart. A single run is limited to about five minutes.
Every execution stores the full conversation as a read-only transcript, linked from the run’s execution trace, so you can read exactly what Ru looked at, what it did, and why. You cannot send new messages into an automation transcript; start a normal chat to follow up. Ru’s final summary is available to later actions as the step’s text output, so you can email it, post it as a comment, or feed it into another step.
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. Model selection is available to Runnit’s platform operators because it applies across organisations.
Manual and schedule automations also have a Run button in the editor header. Run performs the automation for real, exactly as its trigger would, and opens the execution so you can watch the result. If a previous run is still in progress, wait for it to finish before running again. Event and webhook automations cannot run on demand because they need the real event or request that triggers them; use a dry-run to check those instead.
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.