Scheduled and Event-Triggered Workflows

A workflow you have to remember to run is a workflow that stops getting run. This lesson covers the three ways work happens without a person starting it: on a schedule, in response to a content change, and as a standing goal an agent works on by itself.

All three are set in the Cosmic dashboard. None require code.

---

Before You Start

• A workflow that already works when you run it manually. Automating a workflow you have never watched is how you find out at 3am that step 2 was broken

• Project admin access

• Scheduling and event triggers are paid features. On a free plan both the Schedule and Event Trigger sections show a Paid badge. Running a workflow by hand is not affected

---

Scheduled Runs

Open your workflow and find the Schedule section.

Describing the schedule in plain language

The default input is Describe your schedule. Type something like:

Click Generate and Cosmic converts it into a cron expression and shows you the result. Read what it produced before saving. "Every Tuesday at 9am" and "every hour on Tuesday" are one misplaced field apart, and the generated expression is the thing that actually runs.

You can also type the Cron expression directly. Cosmic uses standard five-field cron:

Set the Timezone to the one your team actually works in. Cron has no opinion about daylight saving; the timezone field is what keeps a 9am run at 9am in March.

The manual option

If cron is not how you want to think about it, click Switch to manual scheduling. That gives you a starts control (Start Now or Set Time) and a repeat control with None, Every Hour, Every Day, Every Week, and Every Month. It covers the common cases without any syntax.

Two things to know about timing

Schedules cannot run more often than every five minutes. Anything tighter is rejected.

The scheduler checks for due workflows about once a minute, so a run may start up to a minute after its scheduled time. For a daily content job this is irrelevant. It is worth knowing if you were planning to chain two schedules back to back, which you should not do anyway: use one workflow with two steps instead.

---

Event-Triggered Runs

Below the schedule is the Event Trigger section, described as running the workflow automatically when content changes.

Under Trigger Events, choose which content events start the workflow:

Then use Filter by Object Type (optional) to narrow it to specific types.

Treat that filter as required rather than optional. Without it, the workflow fires on every object of every type in the bucket, which on an active bucket means a great many runs you did not intend.

The loop you need to avoid

Here is the failure mode that catches nearly everyone the first time.

A workflow triggers on . One of its steps creates an object. That creation fires . The workflow runs again. It creates another object.

Two rules prevent this:

Never trigger on the same object type the workflow writes. If the workflow creates posts, trigger it on something else, such as a type that a human fills in. That filter is the guard.

Prefer to for review workflows. Editing happens constantly while someone works. Publishing happens once, deliberately, and is almost always the moment you actually care about.

---

Goals: Standing Work on a Single Agent

Schedules and triggers assume you know the steps in advance. Some work is not like that. "Make sure every published product has alt text" is a job with no fixed number of steps, and the agent is the one who can tell when it is finished.

That is what goals are for. Open an agent, go to the Automation tab, and find the Goals section. Click Add.

A goal has a name and a Prompt, and the prompt should describe an outcome rather than a procedure:

The agent then works toward that across multiple turns and stops when it judges the goal complete. Three fields keep that bounded:

Max steps is how many work turns it gets before stopping regardless. It defaults to 20. Each step costs real tokens, so keep this modest until you have seen the goal run.

Run on a schedule is off by default, which means the goal only runs when you ask for it. Turn it on and you get the same Schedule control described above, plus Max runs per day, which defaults to 24 and exists as a safety cap.

Enabled lets you pause a goal without deleting it. A paused goal shows an Off badge; a scheduled one shows Scheduled.

You can add up to three goals per agent. You can also run one on demand from the agent's chat with the command, which is the right way to test one before you attach a schedule to it.

One thing worth separating: the Goal field on the agent's General tab is a different thing. That is the agent's standing business objective, a line of context about what it is ultimately for. It does not run. The Goals section on the Automation tab is the one that does work.

---

Choosing Between Them

Use a schedule for work that should happen regardless of whether anything changed: a weekly content brief, a monthly link check, a daily digest.

Use an event trigger for work that is a reaction: a new brief arrives and needs a draft, a post is published and needs to be shared.

Use a goal when the work is recurring but open-ended, and the number of steps depends on what the agent finds.

The tell for the first two is whether the work has a natural clock or a natural cause. If you find yourself writing a scheduled job whose first step is "check whether anything changed," you wanted an event trigger. And if you find yourself writing a workflow whose steps are really "keep going until this condition is true," you wanted a goal.

Agents can be automated directly too, not just through workflows. The same Automation tab has a Heartbeat Schedule for sending proactive messages to a connected channel on a timer, and its own Event Trigger for running the agent when content changes.

---

A Tip on Rollout

Automation removes the person who used to notice problems. Give yourself a way to keep noticing.

Before switching a workflow to automatic, run it manually a few times at the times of day it would actually fire. A workflow that works fine on a Tuesday afternoon may behave differently at 4am, when the content it expects has not been written yet.

Then start with the least frequent schedule you can tolerate. Weekly first. If it runs cleanly for a few weeks, move to daily. It is much easier to speed a workflow up than to unwind a week of bad output.

Keep an approval gate in the chain during the first few automated runs. An unattended workflow with a gate in it produces something waiting for review. An unattended workflow without one produces published content nobody has read.

---

Going Further

A workflow can have both a schedule and an event trigger. A weekly cadence with an event trigger for urgent items is a reasonable pattern, as long as both paths can handle running while the other is mid-flight.

Every automated run creates an execution record with per-step status, the same as a manual run. Check them for the first week. Once you know what a healthy run looks like, you will spot an unhealthy one quickly.

---

Do This in Your Project

1. Open a workflow you have already run manually at least once

2. In Schedule, type a plain-language description and click Generate

3. Read the generated cron expression and confirm it means what you intended

4. Set the Timezone to your team's timezone

5. In Event Trigger, add and set Filter by Object Type to a type this workflow does not write to

6. Save, then let it run once on its own and open the execution record

Start weekly. You can always speed it up.

---

Up Next

Lesson 11: Read Your Growth Data with Cosmic Insights

You now have content being produced without anyone starting it. Lesson 11 covers finding out whether any of it is working.