Intermediate · Lesson 13 of 22

Automation Rules: Triggers & Scheduled Tasks

Build rules that run automatically — no clicks required. Row added, row changed, form submitted, time-based schedule, or incoming webhook: Coda automations keep your doc working while you're not watching.

⏱ ~26 min ⚡ Automations ✅ Prerequisite: Lesson 12
01 — Automations vs Buttons 02 — Automation Anatomy 03 — Trigger Types 04 — The If Condition Step 05 — Action Types 06 — Three Practical Examples 07 — Gotchas Practice
01 — Automations vs Buttons

No click required — guaranteed execution.

Lesson 12 covered buttons — actions triggered by a human click. Automations are the next level: they trigger themselves in response to events. A row was added. A column value changed. A form was submitted. The clock hit 9am on Monday. No one needs to be in the doc.

Buttons (Lesson 12)

A human clicks → action fires. Great for on-demand tasks where the user decides when to trigger something. If no one clicks, nothing happens.

Automations (this lesson)

An event occurs → action fires automatically. Run server-side even when the doc is closed. Guarantees execution: a row added at 2am triggers the automation at 2am.

Find automations in the left sidebar (lightning bolt icon) or from a table's overflow menu → Automate. You can also combine both: a button creates a row, and an automation fires when that row is created.

Automations run server-side They don't require anyone to have the doc open. This makes them suitable for overnight processing, daily summaries, and event-driven workflows that need to be reliable even when no one is watching.
02 — Automation Anatomy

When → If → Then → And Then.

Every automation rule has four parts in sequence. Two are required; two are optional.

Automation builder — four-part structure
W
When Required
The trigger — which event causes this automation to consider firing.
If
If Optional
A condition formula (true/false). Automation proceeds only if true. Omit to always fire on trigger.
T
Then Required
The first action — ModifyRow, AddRow, send Slack message, etc.
+T
And Then Optional, repeatable
Additional chained actions. Add as many as needed; they run after Then completes.
03 — Trigger Types

Five ways to start an automation.

Choose the trigger type when setting up a new rule. The trigger determines what event causes the "When" to fire.

Trigger types — reference table
Trigger Fires when… Best for
Row added A new row is inserted in the target table (manually, via button, or API) Welcome notifications, auto-assign, log new signups
Row changed Any field in a row changes — or configure specific columns to watch Stamp timestamps on status change, trigger approval flows
Form submitted Someone submits a form view linked to this table Confirmation emails, auto-routing, notify owner
Time-based A schedule: daily at 9am, every Monday, 1st of the month, etc. Weekly digest, daily standup row, monthly archive
Webhook A POST request hits the automation's auto-generated URL External integrations: Stripe, GitHub, Zapier → Coda
Scoping "Row changed" to specific columns By default, Row changed fires when any column in a row is edited — including by other automations, creating loop risk. Always scope it to specific columns you care about (e.g., only watch Status). This prevents runaway automations and makes intent explicit.
04 — The If Condition Step

Only proceed when this is true.

The If step is an optional formula filter that must return true or false. The automation proceeds to the action only if the formula returns true. In the If step you can reference the triggering row's values directly with [Column Name] — no thisRow prefix needed.

If step — condition formula examples
// Only fire when Status was changed to "Done"
[Status] = "Done"

// Only fire for high-priority rows assigned to me
And([Priority] = "High", [Assignee] = User())

// Only fire for overdue rows
[Due Date] < Today()

// Multiple conditions with Or()
Or([Priority] = "Critical", [Escalated] = true)
If is more efficient than action-level filtering You could skip the If step and put a condition inside your action formula. But using If stops the automation earlier — the run history shows "condition not met" rather than a completed run that did nothing, making debugging much cleaner.
05 — Action Types

What automations can actually do.

The "Then" and "And Then" steps support all the same actions as buttons — plus Pack-powered integration actions for external services.

Built-in actions (no Pack needed)

  • ModifyRow — update column values
  • AddRow — insert a new row into any table
  • DeleteRow — remove a row
  • Send Coda notification — in-app bell notification
  • Trigger another automation — chain automations

Pack-powered actions (require installed Pack)

  • Send Slack message — Slack Pack
  • Send Gmail email — Gmail Pack
  • Create Jira ticket — Jira Pack
  • Post to webhook — HTTP Pack
  • Create Google Calendar event — Calendar Pack
Packs are covered in Lesson 14 Pack-powered actions appear in the automation action picker only after the relevant Pack is installed in your doc. Lesson 14 covers how to find, install, and configure Packs.
06 — Three Practical Examples

Real automations every team uses.

Example 1 — Status stamp: record completion date automatically
When:  Row changed on Tasks (watch: Status column only)
If:    [Status] = "Done"
Then:  ModifyRow(thisRow, [Completed Date], Now())
Example 2 — New task notification to Slack
When:  Row added to Tasks
If:    (no condition — fire for every new task)
Then:  Slack.PostMessage(
         "#team",
         "New task: " & [Name] & " → assigned to " & [Assignee]
       )
Example 3 — Weekly digest row every Monday at 9am
When:  Time-based — every Monday at 9:00 AM (doc timezone)
If:    (no condition)
Then:  AddRow(
         [Weekly Log],
         [Name], "Week of " & Today(),
         [Open], Tasks.Filter([Done] = false).Count(),
         [Done This Week], Tasks
           .Filter([Completed] >= DateAdd(Today(), -7, "days"))
           .Count()
       )
Example 1 gotcha: scope the row-changed trigger In Example 1, always scope the Row changed trigger to the Status column only. If you leave it watching "any column", the automation fires when it sets Completed Date — triggering itself again in an infinite loop.
07 — Gotchas

Four things that trip people up.

Formula recalculation does NOT trigger automations

The "Row changed" trigger fires on direct data edits — a user typing a value, a button running ModifyRow, or an API call. It does not fire when a formula column recalculates and produces a different output. If you need to react to a derived value crossing a threshold, use a time-based trigger with an If condition instead.

Automation loops

If Automation A modifies a row that triggers Automation B, and B modifies a row that triggers A again — you have an infinite loop. Coda has loop detection, but design carefully: always scope "Row changed" triggers to specific columns, and avoid chaining automations that modify the same columns they watch.

🕐

Time-based automations use the doc's timezone

The doc's timezone is set in Doc Settings. "Every Monday at 9am" fires at 9am in the doc's timezone, which may differ from where you or your team members are located. Check the doc timezone before setting up time-based rules for global teams.

Use the Test button before activating

Every automation rule has a Test button that runs the action once on a sample row (without requiring the trigger condition to be met). Always test before enabling a new automation — especially one that sends notifications or creates rows, where a silent bug could cause dozens of duplicate records.

Practice

Test your knowledge.

Automation Rules: Triggers & Scheduled Tasks

5 Questions
Question 1 of 5
A formula column recalculates and its output changes from "On Track" to "At Risk". Will a "Row changed" automation watching that table fire?
Automations only fire when a user, button, or API writes a value directly to a column. Formula recalculations happen in the browser and are not "row changed" events from the automation engine's perspective. To react to a derived value, use a time-based trigger with an If condition filter.
Question 2 of 5
The If condition step in an automation must return what data type?
The If step evaluates a formula that must return a boolean (true or false). If it returns true, the automation proceeds to the Then action. If false, the automation stops and logs "condition not met" in the run history. Formulas like [Status] = "Done" return a boolean.
Question 3 of 5
A time-based automation is set to fire "every Monday at 9:00 AM". Whose 9am does it use?
Time-based automations use the doc's timezone, which is configured in Doc Settings. This is important for distributed teams: a "9am Monday" rule fires at 9am in the doc's timezone, regardless of where individual users are located.
Question 4 of 5
In buttons you use RunActions() to chain actions. What is the equivalent structure in automations?
In automations, chaining is done by adding "And Then" action steps — each one runs after the previous completes. You can also use RunActions() inside a single Then step for more complex conditional branching, but the native automation approach is the "And Then" step chain.
Question 5 of 5
Automation A stamps a "Completed Date" whenever Status is set to "Done". A developer asks: "Why does Automation A keep firing in a loop?" What is the most likely cause?
This is the classic automation loop: the trigger watches "any column change," so when Automation A sets the Completed Date column, that edit is itself a row change — firing the automation again. Fix: scope the Row changed trigger to watch only the Status column, so writing to Completed Date doesn't re-trigger it.
← Prev Buttons & Actions Lesson 12