Database Automations DEEP DIVE! | What's New, Basics to Advanced Notion Tutorial

Notion database automations now support two major upgrades—sending emails directly from automation runs and defining variables inside automation steps—making it easier to build workflows that react to database changes and then communicate results. The interface also got a clearer “lightning” workflow builder, with new action options like “send mail to” and “define a variable,” plus formula-based property edits that unlock more dynamic behavior (such as computing dates from other fields).

The practical takeaway is that automations become far more than simple “when X then set Y” rules. With the new email action, a project can automatically notify a person when a status flips to complete, using the trigger page’s name and completion date to generate a subject and message. With variables, automations can reuse computed or referenced values across multiple steps—especially useful when syncing data between related databases or updating many pages at once.

The tutorial then walks through the basics by starting with the prerequisite: an automation needs a database. Once a database exists, automations can be scoped either to the entire database or to specific table views. That scoping matters because views can filter which pages are eligible—for example, creating a “this month” view by filtering a date property, then running automations only for pages visible in that filtered view.

At the core of every automation is a trigger and an action. A simple example sets a “completion date” when a “status” property changes to “complete.” The automation is configured so the trigger watches for the status value, and the action edits a target property on the same page using the date triggered. The tutorial also covers multi-condition triggers, where multiple conditions can be combined using “all” versus “any” logic—useful for assigning a person only when both status and a “type” property match (e.g., status = in progress and type = marketing).

From there, the actions expand beyond editing a property. Automations can add pages to another database (e.g., when a marketing project enters “in progress,” create a related task in a task database with its own initial status and assignee). They can also edit pages in other databases by filtering which pages to update (for instance, turning marketing tasks from “not started” to “in progress” when the parent project changes).

The “advanced” section shows formulas and variables in action. Formulas can dynamically set due dates—like setting a due date to three days after a status enters “in review.” They can also calculate durations, such as computing how many days an issue stayed open by using the date between the trigger time and an “open date.” Variables enable bulk updates, such as completing all subtasks when a parent task is marked done by capturing the triggered page’s sub-item pages and then setting their statuses.

Finally, the tutorial demonstrates a more complex, public-facing sync pattern. An internal projects database can keep sensitive fields (like risk level and total cost) private, while a public-facing projects database shows only selected properties. Automations add new public pages when internal pages are created, then use variables and formulas to keep the public page fields updated whenever internal properties change—using relations to map each internal page to its corresponding public entry.