> ## Content Index
> Fetch the complete content index at: https://notionsolutions.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Notion Automations: Define the Trigger, Action and Exception
- URL: https://notionsolutions.net/notion-automations-trigger-action-exception/
- Published: 2026-10-21T09:00:00.000Z
- Updated: 2026-10-21T15:54:31.000Z
- Description: Plan a native Notion handoff before building it: define the event, eligible records, target, exceptions, and the evidence you need before retrying.
- Author: Kevin Turner
- Tags: guide, automations

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](https://www.notion.com/help/database-automations?ref=notionsolutions.net) 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](https://www.notion.com/help/database-automations?ref=notionsolutions.net). 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](https://www.notion.com/help/database-automations?ref=notionsolutions.net). 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.

__Specification for a client-review handoff__
| 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](https://notionsolutions.net/notion-client-project-tracker-template/) 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](https://www.notion.com/help/database-automations?ref=notionsolutions.net). For this example, filter the eligible Projects view to the three conditions in the table, then scope the rule to that view.

[![Three current project conditions combine with a person changing Status to Client review; later Owner edit is separate](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/automation-event-eligibility.webp)](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/automation-event-eligibility.webp?ref=notionsolutions.net)

A project can match the view without a new status event. Handle missing-owner exceptions deliberately.

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](https://www.notion.com/help/database-automations?ref=notionsolutions.net) 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

1. Open the Projects database, select **⚡ → New automation**, and give the rule a descriptive name such as Client review: create task.
2. Select the eligible Projects view as its scope. Choose **New trigger** and set the Status change to Client review.
3. Choose **New action → Add page to** and select Tasks. Set the Task title to Review client delivery.
4. 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.
5. 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.
6. 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](https://www.notion.com/help/database-automations?ref=notionsolutions.net), 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.

[![Maya maps from project Owner to task Owner, and the Harbor project page maps to the task Project relation](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/automation-source-target-map.webp)](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/automation-source-target-map.webp?ref=notionsolutions.net)

Check the destination types and page reference, then compare the created task with its source marker.

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.

__Choose recovery from the actual source and destination together__
| 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. |

[![A correct task with an unchecked marker needs marker repair; a checked marker without a task needs investigation](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/automation-output-marker-recovery.webp)](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/automation-output-marker-recovery.webp?ref=notionsolutions.net)

The source marker and actual task must agree. Check both before creating any missing work again.

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](https://www.notion.com/help/database-automations?ref=notionsolutions.net). It is a separate design from the person-driven status rule above.

[Database automations cannot trigger other database automations](https://www.notion.com/help/database-automations?ref=notionsolutions.net). 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](https://notionsolutions.net/notion-recurring-template-not-triggering-automation/) before redesigning the workflow.

[Mentions and formulas are supported in automation actions, not triggers](https://www.notion.com/help/database-automations?ref=notionsolutions.net); 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:

__Checks to record before adopting the review-task rule__
| 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](https://notionsolutions.net/notion-project-dashboard-weekly-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](https://www.notion.com/help/database-automations?ref=notionsolutions.net). 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.