An automation starts work without anyone asking for it each time. It runs on a schedule, or when something happens: a pull request opens, an issue is filed, a check or a deployment fails.
Every automation is listed in the factory under Automations, with what starts it and what it does. Create one in New Work: choose Automation, then when it runs and what it does, in your own words.
- ScheduleTime
- Event automationSomething happens
An ordinary task
Specification, plan, build, verify, review. Uses an agent slot; give it a lower priority.
P2P3A pull request
It cannot merge itself or commit to your base branch.
You approve
Two kinds of trigger
| Trigger | Runs | Example |
|---|---|---|
| A schedule | Every few hours, or every day, week or month | Ask Sentry for new errors every hour and open a task for each |
| Something happens | When GitHub or Coroid sends the event | When a task fails, find out why and open a task that fixes it |
Use a schedule when the trigger really is time, or when the thing to watch lives in another system that does not send Coroid events, such as Sentry or Jira. The schedule asks that system through your MCP servers and opens work for what it finds. See Schedules.
Use an event when Coroid can be told the moment it happens. It does less pointless work than a schedule that keeps asking.
Events you can choose in New Work
From GitHub, which needs the GitHub App:
- a pull request is opened, updated or merged
- an issue is opened
- a comment mentions Coroid; it counts only when its author has write access to the repository
From Coroid:
- a task, a plan, a Quality check, a deployment or a deployment health check fails
- a deployment succeeds
- a release is rolled back
Events your own systems fire need a service account, and Slack, Telegram and Jira events need a filter: change an automation's event in its editor. See Hooks.
What it does
An agent follows your instructions. It can read the project's code and open tasks, and it changes nothing directly. Work it opens goes through the same specification, plan, build, verify and review path as anything else, and ends in a pull request you approve.
On a schedule, an automation can instead run your browser tests against a test surface.
Standing automations that Coroid writes for you are switches in Quality Control, not something to create in New Work:
- Reviewing pull requests. Quality Control's Pull requests group runs the project's checks on every pull request (Coroid Quality Control) and has Coroid Review comment on it.
- Turning messages and issues into requests. Slack and Telegram messages, GitHub comments that mention Coroid and new Jira issues become requests when their source is switched on in Quality Control, under Before work starts. See Issue trackers for Jira.
- Following up on failures. A failed task, a failed deployment and a rolled-back release each have a switch under When something breaks.
- Cleaning up existing debt. A project's Weekly debt cleanup is a switch on its Anti-slop row.
An automation a switch manages says so on its page in Factory, with a link to the switch. Pause it there or switch it off; change its instructions and it becomes your own, after you confirm.
Automations created earlier that file requests keep running, and are listed under Automations. Automations that reviewed pull requests were paused when Quality Control took over Coroid Review.
New Work's templates
New Work used to offer templates. Their jobs moved to the switches above, and the two that posted to Slack can be written in your own words, naming the channel. They post through an MCP server you connect in Settings, under Connections: a schedule can use it, and an event automation can once you allow MCP tools in its editor in Factory. Automations you created from a template keep running as they are. An old link to a template opens the switch that replaced it, or New Work.
Watching an automation
Open an automation in the factory to see each run: when it ran, what it cost, what it opened, and why a run did not finish. From there, owners and admins can pause it, test it, edit it or delete it. Everyone in the organisation can see automations and their runs.
Keeping automations useful
Work an automation opens competes for the same agent slots as everything else. One that fires often can quietly use up your capacity.
- Give it a lower priority than work people asked for.
P2orP3. - Make the trigger specific. "A check failed" fires constantly on a busy repository. "This check failed on the base branch" fires when something is actually wrong.
- Look at what it produced. If an automation opened twenty tasks and you merged two, it is producing noise and spend, not value.
The honest measure of an automation is how much of the work it opens gets merged, not how often it fires.
Sentinel
Earlier versions of these docs described Sentinel, a monitor that watches for a condition. It is not a separate feature. A condition is either an event, which an automation can run on, or something a schedule checks.