Automating recurring work with Triggers and Runs

When to automate a task, and when not to

Not everything that repeats should run unattended. A good candidate for a Trigger has three things in common: it happens on a predictable schedule or in response to a clear event, the steps involved don't require judgment calls a person would want to weigh in on every time, and someone specific is willing to be the owner who gets notified if it needs a human.

A daily competitor pricing check is a good fit. Drafting your quarterly board deck is not — not because AI can't help, but because that's exactly the kind of work where a live, collaborative session (with people actually in the room) serves you better than something running in the background.

Setting up your first Trigger

From any workspace, go to Runs → New Trigger. You'll choose one of three types:

• Schedule— runs on a recurring cron schedule (“every day at 8am”)
• Webhook — runs when an external event arrives (a new support ticket, an inbound form submission)
• API — runs when called directly from another system you already use

Whichever type you pick, you'll assign it an owner— the person who gets notified if the run needs a human. This doesn't have to be whoever created the Trigger; it should be whoever actually wants to be the one making that call.

Watching it work: the Runtime Console

Once a Trigger fires, it creates a session just like any other — the only difference is nobody had to click “New Session” to start it. You can open it directly from the Runs list, or watch everything happening across every session at once from Runtime Console in the left nav.

Anyone in the workspace watching a run can pause it, approve or reject a pending action, or take it over entirely — same controls as a session someone started manually.

Getting the approval policy right

Every Trigger has a default approval policy that governs what its agent can do without asking first. Two mistakes are common when people first set this up:

The setting that works for most teams: let the agent handle read-only and low-stakes actions on its own, and require approval specifically for anything with an external effect — sending a message, publishing something, spending money. That's also Orvoq's default.

What happens if nobody's watching

This is the part people forget to plan for. If a scheduled run hits something that needs approval and its owner doesn't respond, you have three options, set per Trigger:

1. Notify and wait (default) — nothing happens until the owner responds, however long that takes
2. Escalate after a timeout— notify a fallback approver if it's been unresolved for a set period
3. Auto-reject after a timeout — cancel the pending action rather than let it sit indefinitely