Notion database automations pair a trigger with one or more actions: a page is added, a property changes, or a schedule comes around, and Notion runs the work you've set up. Before you build a rule, write down its source, eligible records, trigger, target, and exception, meaning any case it shouldn't handle on its own.
I would begin with one internal handoff that you can inspect, such as creating a review task when a project enters client review. Keep email, broad updates, and extra rules out of that first design. A reliable handoff needs a clear recovery path as much as a trigger.
Check the plan and access first
You'll need a paid plan and Full access to the source database before creating this task-creation rule. Notion's automation permissions let paid-plan users with full database access create, edit, and delete rules. Guests can't create database automations, even with full access.
Free users can use existing template automations without editing them. Do not mistake that for permission to build the task-creation example below.
You'll also need editing permission for the destination pages and databases, since Notion automations do not take action on access-restricted pages. When a result is missing, check both the watched source and the actual target before you blame the trigger.
Write one rule in plain language
This educational design fits a small client-work system:
When a person sets a project to Client review, create a review task for its owner if the project has an owner and has not already been handled for this review cycle. Keep missing-owner projects visible for a person to resolve.
| Rule part | Design |
|---|---|
| Source | Projects with Status (Status), Owner (Person), and Review task created (Checkbox). |
| Eligible view | All three conditions: Status is Client review; Owner is not empty; Review task created is unchecked. |
| Trigger | Property edited: Status is set to Client review. A person makes this change. |
| Target | Tasks with Task (Title), Owner (Person), and Project (Relation to Projects). |
| Actions | Add one task named Review client delivery with the source owner and source project; set the source checkbox to checked. |
| Exception | A project missing its owner is excluded and goes into a separate view. A missing or restricted destination needs a person to repair it. |
| Recovery | Find any existing task linked to that project before retrying. Reconcile the target with the source marker; do not clear the marker automatically. |
Use the project and task tracker structure if the source records are not yet defined. The property names above are model choices; they must match your real databases.
Separate eligibility from the trigger event
The eligible view says which projects may run. The trigger says what change starts the rule. A project sitting in Client review is not the same thing as a person setting its status to Client review.
Notion lets an automation watch an entire database or a particular view. The page must still match that view's filters when the trigger occurs. For this example, filter the eligible Projects view to the three conditions in the table, then scope the rule to that view.
Keep another Projects view for Status is Client review and Owner is empty. If a project enters review without an owner, the rule should exclude it. Filling the owner later is a different property edit; do not assume it replays a status trigger. Resolve the handoff deliberately, for example by creating and linking the task manually, then reconciling the marker.
With multiple triggers, pick When any of these occur or When all of these occur on purpose. Notion documents an approximately three-second window for multiple broad is edited triggers that must all occur, which is why I'd prefer the specific status is set to condition here: it doesn't ask two unrelated edits to coincide.
Make the first record concrete: an educational project named Harbor landing page starts in Draft, has one Owner, Maya, and an unchecked Review task created marker. A person changes Status to Client review. You're aiming for a Tasks page titled Review client delivery, assigned to Maya, with its Project relation pointing back to that same Harbor landing page record, and a source marker that agrees with the verified output. Those are the values to inspect in your own setup.
Map the actions to the right records
- Open the Projects database, select ⚡ → New automation, and give the rule a descriptive name such as Client review: create task.
- Select the eligible Projects view as its scope. Choose New trigger and set the Status change to Client review.
- Choose New action → Add page to and select Tasks. Set the Task title to Review client delivery.
- In the supported action fields, use the @ picker to select the Owner property from the trigger page for the task's Owner. Set the task's Project relation to the trigger project page. Confirm that the target Owner accepts a Person value and Project is a relation to Projects; do not type a page name as a substitute for a page reference.
- Add Edit property for Review task created in the watched Projects database and set it to checked. Keep this source update after the create-task action in your design.
- Review the target database, fields, scope, and trigger before selecting Create. Inspect the actual destination record when you validate the rule in your workspace.
Add page to creates a page and sets its properties, while Edit property changes properties in the watched database. Action fields support mentions of a page or a property from the trigger page, and the mapping above is built on those capabilities. Still, check the actual property tokens and accepted types in your editor.
If you choose Edit pages in for a different workflow, review the destination selection and filter before enabling it. That action can change records beyond the triggering page. Write down the intended target set rather than relying on a familiar database name.
Reconcile the source marker with the output
The unchecked marker in the eligible view excludes already-marked projects from later status events. It is useful bookkeeping. A checked source does not, by itself, prove that the expected task exists, has the right owner, or was created exactly once.
Don't read a transaction, a rollback, or a successful creation into the order of the two configured actions. Before you retry a handoff, inspect Tasks for the linked project. If the task exists but the marker is unchecked, repair the source bookkeeping instead of creating another task. The reverse case is a checked marker with a missing or wrong task: investigate that mismatch and resolve it.
| Source marker | Linked review task | Recovery decision |
|---|---|---|
| Checked | One correct task | Keep the reconciled state. Do not replay the same handoff. |
| Unchecked | One correct task | Verify its owner and Project relation, then repair the source marker. Do not create another task. |
| Checked | Missing or wrong task | Pause and investigate the mismatch. Repair the intended output deliberately rather than assuming the marker proves success. |
| Unchecked | No task | Check the event, view eligibility, target access, and rule state before deciding how to recover the missing handoff once. |
| Either | Multiple tasks for the same cycle | Pause, identify the intended task, and reconcile duplicates with their owners. A checkbox change cannot resolve duplicate work. |
This design does not provide a simultaneous-run lock. For a reopened review, decide whether it reuses the existing task or starts a new review cycle. Reusing the checkbox without checking the previous output makes those two cases indistinguishable. I would keep repeat reviews manual until the cycle identity and recovery procedure are clear.
Respect scheduled and chained-automation limits
A recurring Every {frequency} trigger can run on a daily, weekly, or other configured schedule, with a time and timezone. A recurring trigger cannot be combined with another trigger type and cannot use Edit property. It is a separate design from the person-driven status rule above.
Database automations cannot trigger other database automations. A recurring template creating a page, or an automation adding a page to another database, cannot start a hidden chain. A person clicking a button that creates a page can trigger a database automation. If a repeating template is your starting event, read why that new page does not trigger the next rule before redesigning the workflow.
Mentions and formulas are supported in automation actions, not triggers; formulas are not supported for Slack notification actions. Keep the event rule simple and use eligible-view filters for required inputs.
Validate the handoff before depending on it
Try the rule on non-client-facing example records in your own workspace and write down exactly what happens. Then hold the design to these acceptance criteria and decide whether it meets your requirements:
| Scenario | What to inspect |
|---|---|
| Eligible project enters Client review | One intended task exists, its Owner matches the source, its Project points to the trigger project, and the source marker agrees with the output. |
| Owner is missing | No automatic task from this rule; the source is visible in the missing-owner view. Assigning an owner alone must not be treated as a replay. |
| Already-marked project re-enters review | The eligible view excludes it. Inspect for duplicate or missing tasks rather than trusting the checkbox alone. |
| Target is unavailable or restricted | Record the displayed error, rule state, and actual output. Repair access or mapping before any retry. |
| Interrupted or inconsistent handoff | Compare the linked task and source marker; decide whether to fix the existing output or create missing work once. |
If results differ from the specification, keep the rule paused while you investigate. Retain a short operating note with the automation owner, source/view, target, required fields, and safe recovery decision. The exception view belongs in the ongoing workflow, including the weekly project review, rather than disappearing after setup.
When a rule stops, check the event before retrying
Start with the source record: was there a qualifying event, did it still match the watched view after the change, and was the database locked? Then inspect the target permission, property mapping, and rule state.
Notion distinguishes setup errors from later automation errors. Setup errors can stop you from saving, while a rule that was working and then hits an error gets paused. You'll get notifications for some failures, such as missing target databases or properties and invalid third-party connections. Formula and webhook failures may not notify you, so silence isn't proof of success.
After correcting a paused rule, open its automation menu and turn Active back on manually. Reconcile any existing output before replaying affected records. If an action calculates a date from an empty field, Notion recommends a view excluding empty inputs and scoping the rule to that view; repair the missing data instead of changing unrelated triggers.
