Automation rules
A rule watches for something happening in your workspace and reacts to it. Every rule has the same three parts:
- When — the trigger that starts it: an event from a package, a schedule, or a manual run.
- If (optional) — conditions narrowing which occurrences count.
- Then — one or more actions, run in order.
Rules run on the server. They fire whether or not you have the app open, on any device, including none. A rule that files newsletters keeps filing them while your laptop is shut.
Where rules live
Open Settings → Rules. Two segments:
- My rules — yours alone. Anyone can create personal rules.
- Organization — shared rules everyone can see, but only admins and the owner can create, edit, or delete. Everyone else sees them read-only.
Packages may also offer a filtered view of the same rules. Mail’s sidebar has a Rules entry that shows only mail-triggered rules and creates new ones with a mail trigger preselected. It is a filtered lens on the same records, not a separate system — anything you make there also appears in Settings → Rules → My rules.
Building a rule
New rule opens a builder that walks the three parts in order.
Pick a trigger first. Choosing one resets the conditions and actions below it, because both depend on the trigger’s fields.
Conditions appear only for triggers tied to a record — “Run manually” and “On a schedule” carry no data to filter on. You get one level of grouping: conditions inside a group combine with all (AND) or any (OR), and the groups themselves combine the same way. Available operators depend on the field’s type:
| Field type | Operators |
|---|---|
| Text | contains, does not contain, equals, starts with |
| Number | equals, does not equal, greater than, less than |
| Boolean | is true, is false |
| Date | before, after, within the last N days |
| Relation, select | is, is not, is empty |
Then add actions. Text parameters accept {{ }} placeholders — the builder’s
{{ }} button inserts the trigger’s available fields, and they are filled in
with real values when the rule runs. So a notification can say
New mail from {{sender_email}} rather than just “you have mail”.
Saving without a name, a trigger, or at least one action tells you exactly what is missing.
Personal and organization rules behave differently
This is the distinction that most often surprises people, and it matters most on anything shared.
Personal rules act only for you. On a shared mailbox, a personal rule that archives a message archives it in your view; everyone else still sees it in their inbox.
Organization rules act for everyone the event touches, and run with admin authority — their actions behave as though an admin performed them, whoever triggered the run. An org rule archiving spam on a shared mailbox archives it for the whole team. That is deliberate: a shared rule that tidied only its author’s inbox would be surprising. If you want something that affects only you, make it personal.
Test before you rely on it
Test against recent items runs the rule’s conditions against your most recent matching records and reports how many would have matched. No actions run.
Some triggers cannot be scoped to “recent items you can see” — a shared mailbox’s messages don’t belong to any single member. On those, a non-admin gets a message explaining that an organization admin needs to run the test from the Organization segment instead. This affects only the preview; the rule itself still runs normally.
Run now, in a rule’s overflow menu, fires a manual or scheduled rule immediately, enabled or not. Use it to confirm the actions do what you expect.
Run history
Every firing writes a run record. Open a rule’s overflow menu → Run history to see:
- Whether the run matched — conditions satisfied, actions ran — or Didn’t match, meaning the trigger fired but conditions filtered it out. Non-matching rows are expected and useful: they prove the rule is watching even when there is nothing to do, which is how you debug a rule that seems inert.
- How long it took, and each action’s result.
Personal-rule history is visible to its owner. Organization-rule history is restricted to admins and the owner — tighter than the rule itself, because a run record can quote data belonging to other people.
Ordering, and stopping early
Rules run in the order shown, which you set by dragging. Organization rules always run before personal ones.
Stop processing further rules halts the chain. On an org rule it stops everything downstream. On a personal rule it stops only that owner’s later rules — so on a trigger that reaches many people, whoever happens to sort first cannot switch off everyone else’s automation.
When a rule disables itself
A rule whose actions keep failing — around twenty consecutive fully-failed runs — is disabled automatically and its owner notified, so it stops generating errors indefinitely. Check its run history for the cause (a deleted label, a revoked permission), fix it, and re-enable the rule from the list.
Rules also cannot run away. A rule never re-fires on its own write, chains of one rule triggering another are capped at three levels deep, and a rule that sends email is limited to 20 messages an hour — enough that an exchange with someone else’s auto-responder stops on its own. Hitting the cap is recorded in run history.
What you can build with
Available triggers and actions depend on which packages are installed. Anything from a package you don’t have simply won’t appear.
Always available
| On a schedule | Trigger: run on a repeating schedule |
| Run manually | Trigger: run only when you ask |
| A user joins | Trigger: a new account is created on the server. Make it an org rule — a new user belongs to nobody, so personal rules never match |
| Send me a notification | Action: the in-app bell |
| Send an email | Action: to any address, with a subject and body you write |
| Post to a webhook | Action: POST the trigger’s fields as JSON to a URL you give, optionally signed with a secret so the receiver can verify it came from you |
| Apply label | Action: attach a label to the record that started the rule |
| A message arrives | Trigger: genuinely inbound mail only — never drafts, sends, or bounces. Filter on subject, sender, sender name, attachments, alias |
| A message bounces | Trigger: something you sent didn’t arrive, or was marked as spam |
| Move to folder | Action: file the thread in Archive, Trash, Spam, or Inbox |
| Mark as read | Action |
| Star the message | Action |
| Forward the message | Action: send a copy elsewhere |
| Send a message | Action: new mail with a subject and body you write |
Moving, marking read, and starring are independent — combine them freely. A rule cannot send to its own mailbox or aliases, so a forward pointed at itself cannot feed itself.
Calendar
| An event is added | Trigger: any new event on a calendar you belong to. Filter on From a subscribed feed to ignore bulk imports from an external feed |
| An event is rescheduled | Trigger: the start or end time changed — editing a title or location does not count |
| An event is removed | Trigger |
| A calendar feed fails to sync | Trigger: a subscribed calendar could not be fetched. Without a rule this is silent — the calendar just quietly stops updating |
| Create an event | Action: scheduled as an offset from now (starts in N days, duration, all-day, reminder) |
Drive
| A file is added | Trigger: anything new — an upload, a document, a folder. Filter on name, type, size, and destination folder |
| I’m mentioned in a comment | Trigger: an @-mention anywhere — documents, spreadsheets, and files alike, in one rule |
| A file is shared with me | Trigger: someone grants you access |
| A public link is created | Trigger: best as an org rule, to notice things being published outside the organization. As a personal rule it means “when I create a link” |
| Move to folder | Action: moves the file that started the rule |
Boards
Boards is an optional package; these appear once it is installed. Every card trigger fires on any board you belong to, not only your own cards, and can be filtered by board, list, assignees, priority, and estimate.
| A card is created | Trigger |
| A card moves to another list | Trigger: a change of list. Reordering within a list is not a move |
| A card is completed | Trigger: the card moved into a list whose status is done. Separate from “moved” because whether a list counts as done is a property of the list, not the card |
| A card is canceled | Trigger: the card moved into a list whose status is canceled |
| A card is assigned | Trigger: the assignees changed |
| A card’s priority changes | Trigger |
| A card’s estimate changes | Trigger |
| A card’s dates change | Trigger: the start or due date, or the due time |
| A card becomes overdue | Trigger: the due date passed. Fired by the server’s due-date sweep, so it works while nobody has the board open |
| A card is due soon | Trigger: the due date is within the board’s due-soon window |
| A card is archived | Trigger: archiving only, never a restore. The auto-archive sweep counts |
| A card’s parent changes | Trigger: a card became a sub-task, or stopped being one. Filter on the parent to tell them apart |
| A card’s sprint changes | Trigger |
| A sprint starts / A sprint completes | Triggers: filter on the sprint’s name, goal, dates, or board |
| Someone reacts to a comment | Trigger: filter on the emoji, who reacted, or the card |
| A linked pull request opens / is up for review / is approved / All linked pull requests merge | Triggers: from the GitHub integration, once a repository is attached to the board |
| Move the card to a list | Action: moves the card that started the rule |
| Assign the card to someone | Action: adds a person to the card’s assignees, keeping the existing ones |
| Add a label to the card | Action: adds one of that board’s labels, keeping the existing ones |
| Set the card priority / Set the card estimate | Actions |
| Make the card a sub-task | Action: sets its parent card |
| Move the card to a sprint / Move the card into the active sprint / Move the card to the backlog | Actions |
| Move the due date | Action: shifts it by a number of days from the current due date, or from today if it has none |
| Create a card | Action: a new card with a title, in a list you pick |
Contacts
| A contact is added | Trigger: created by you, an import, or another rule |
| A contact changes | Trigger: name, email, phone, company, job title, notes, or favorite. Deliberately ignores bookkeeping — a CardDAV sync assigning an internal identifier, or a move to the trash, is not a change |
| Add a contact | Action: first name, last name, email, company, each accepting placeholders |
Adding contacts does not check for duplicates. A rule saving everyone who emails you will save the same person once per message. Add conditions to narrow it, or merge afterwards.
Documents and spreadsheets
| A comment is added to a document | Trigger: anyone commenting on a document you can see. Filter on the text, the quoted passage, the author, and which document |
| A comment is added to a spreadsheet | Trigger: same, and because sheet comments anchor to a cell you can also filter by sheet, row, and column — enough to watch one region of a model |
Both are broader than drive’s mention trigger, which fires only when someone addresses you. Neither package contributes actions: document and cell contents are collaborative edit operations rather than fields a rule could set. A rule that starts from a comment can still do anything another installed package offers.
Some things to build
File newsletters. When a message arrives, if the sender contains
newsletter@, move it to Archive and mark it read. Never touches your inbox,
still searchable.
Auto-file invoices. When a file is added, if the folder is Inbox and the
name contains invoice, move it to Invoices.
Turn a message into a reminder. When a message arrives, if the subject
contains invoice, create an event titled {{subject}} starting in 3 days
with a 60-minute reminder.
Notice a broken feed. When a calendar feed fails to sync, send yourself a notification. Otherwise a subscribed calendar drifts out of date silently.
Never miss a mention. When you’re mentioned in a comment, notify yourself.
Watch the assumptions. When a comment is added to a spreadsheet, if the
sheet is Inputs, notify yourself. Comments elsewhere stay quiet.
What rules don’t do
Worth knowing before you plan around them:
- Time passing is mostly not an event. “If this is still unread in three days” or “if nobody replied in two days” are not expressible. Rules react to things happening. Scheduled rules exist but carry no record with them. The exception is a package that runs its own sweep and turns a deadline into an event — Boards does this for “a card becomes overdue” and “a card is due soon”.
- Content changes are invisible. Editing a document or a cell produces collaborative operations, not record changes, so there is no “when this document changes” or “when this total exceeds 1000” trigger.
- A rule acts on the record that started it. It cannot go and find some other file, card, or contact and change that instead.
- No batching. Each event is handled on its own; there is no “one summary of today’s mail”.
Package authors adding new triggers and actions should read Automation.