Academy
6. Automating with Schedules and Triggers
Attach a schedule or an event-based trigger (webhook, watcher) to a Live Artifact so it runs autonomously, with each event's data mapped to inputs.
A Live Artifact doesn't have to wait for you to press "Run." Once forged, you can attach automation rules so it fires on its own. There are two mechanisms:
• Schedule — a recurring calendar rule such as "every Monday at 8 AM" or "daily at 18:00." When the clock hits the mark, a new run starts automatically. • Trigger — an event-based rule. A trigger can be a webhook (a call from another tool or system) or a watcher (e.g., a new email matching a rule, a change detected in a connected service). When the event fires, the artifact runs.
In both cases, the event's data is mapped to the artifact's declared inputs. A schedule might always use the same defaults; a webhook passes a payload whose fields fill the input form. Each automated run has its own budget, can be cancelled, and appears in the full run history with its inputs, cost, and verdict.
Input mapping is the key to useful automation. When you declared your artifact's inputs (a file, a date range, a keyword list), you told OUPI what changes between runs. Automation sources must supply those values:
• A schedule can use fixed defaults you set (e.g., "last 7 days" for a date range) or dynamic values like the current date.
• A webhook trigger receives a JSON payload from an external tool. You map payload fields to artifact inputs — for example, the webhook's attachment_url field maps to the artifact's "file to process" input.
• A watcher trigger extracts data from the detected event (email subject, sender, attachment) and maps it to inputs.
Inputs are still validated on every automated run: types are checked, required fields must be present, and files must resolve in your file space. A run that receives invalid data will fail fast rather than produce garbage.
Wake-ups: the shared control panel. Schedules and watchers — whether attached to a Live Artifact or a Studio task — are managed from the same place: the Wake-ups section of the Assistant. From there you can:
• Pause an automation without deleting it (useful during holidays or maintenance). • Arm it again when you're ready. • Try once to test the automation with real data before letting it run unattended. • Review history — every past firing is logged with its inputs, deliverables, cost, and verification verdict.
This gives you a single dashboard for all autonomous work, whether it's a Live Artifact running "every Friday at 17:00" or a watcher reacting to incoming invoices.
Always use "Try once" before arming a schedule or trigger. It fires one real run so you can verify that the event data maps correctly to your inputs and that the deliverables land where expected — without committing to recurring runs. Check the run's cost and verdict in the history before going live.
Budget every automated run. Because each firing costs credits proportional to the work done, set a per-run budget on the artifact. This prevents a misconfigured trigger (e.g., one that fires on every email instead of a filtered subset) from draining your balance. Cancelled or budget-exceeded runs still appear in history so you can diagnose the issue.
When sharing an automated artifact with your team, remember: each member gets their own instance with their own schedule or trigger, their own inputs, and their own run history. Runs are billed to the member who owns the instance, not to you. This makes it safe to distribute automated workflows across a team without centralizing cost or risk.
Go to your Live Artifacts list. Pick an artifact you've already run manually. Open its settings and attach a schedule (e.g., weekly) or a trigger (e.g., a webhook URL). Map the event data to the artifact's inputs, then use "Try once" from Wake-ups to validate the run. Check the history for the run's inputs, cost, and verdict.
Live Artifacts become autonomous through schedules (time-based) and triggers (event-based: webhooks, watchers). Each event's data is mapped to the artifact's declared inputs and validated before the run starts. All automations are managed from Wake-ups: pause, arm, try once, and review history. Set a per-run budget to control costs, and always test with "Try once" before going live. When shared, each team member owns their instance and their runs.