Notion decision log template: full setup with automations
Build a decision log in Notion: the database properties, a page template, a two-way Replaces relation, four views, and automations that post decisions to Slack.
A product team decides in a Slack thread to cap free workspaces at three projects. Someone says "let's log it in Notion." Two weeks later, nobody can find the page, because it was never written, or it was written as a bullet in meeting notes under a heading about something else.
A decision log in Notion works when it is a database with a fixed shape, not a page of notes. This guide builds one step by step: properties, a page template, views, and automations. It uses Notion's help center, checked on 5 November 2026. For a tool-agnostic version you can paste anywhere, see the decision log template.
Step 1: create the Decisions database
Create a full-page database called Decisions. Each page is one decision, and the page title is the decision itself, written as a verdict: "Free workspaces are capped at 3 projects", not "Free plan limits".
One database for the whole team works better than one per project. Decisions outlive projects, and a single database is the one place everyone searches.
Step 2: add the properties
Add these properties. Each one exists for a reason:
| Property | Type | Why |
|---|---|---|
| Name | Title | The decision, as a verdict |
| ID | ID | A unique number, so tickets and PRs can cite the decision |
| Status | Status | Where the decision stands |
| Owner | Person | The one person who can change it |
| Approved by | Person | Who else agreed, especially other teams |
| Decided on | Date | When it became the rule |
| Review by | Date | When to check it still holds |
| Area | Select | Product, Pricing, Engineering, Design, and so on |
| Source | URL | The Slack thread, PRD, or meeting notes it came from |
| Replaces | Relation to Decisions, two-way | Links a new decision to the one it replaces |
| Projects | Relation to your Projects database | The work this decision governs |
Notion's ID property generates a unique number for each page that can't be edited by hand, which is what you want for a stable reference.
Set up Status. Notion's Status property sorts options into three groups: To-do, In progress, and Complete. Use these options:
| Group | Options |
|---|---|
| To-do | Proposed |
| In progress | In review |
| Complete | Accepted, Rejected, Replaced |
Set up Replaces. Create a Relation from Decisions to Decisions, turn on the two-way option, and name the other side Replaced by. Now each decision shows what it replaced and what replaced it.
Step 3: add a page template
A database template gives every new decision the same sections. Click the arrow next to New, choose New template, name it Decision, set Status to Proposed, and add this body:
## Decision
[One or two sentences. What we will do.]
## Why
[The reason this option won. What problem forced the decision.]
## Options we rejected
- [Option]: [why not]
## What this changes
[Who and what is affected. Links to tickets, specs, or code.]
## Open questions
- [Anything not yet decided, marked clearly]
Then set it as the database's default template, so a new page opens ready to fill in. Notion's documentation warns not to pre-fill relation properties in a template, or every new page will link to the same pages. Leave Replaces and Projects empty in the template.
Step 4: create four views
Views turn the database into a register. Create these:
| View | Layout | Filter or group |
|---|---|---|
| Board | Board | Grouped by Status |
| Current decisions | Table | Status is Accepted, sorted by Decided on, newest first |
| Due for review | Table | Status is Accepted and Review by is on or before today |
| Waiting for a decision | List | Status is Proposed or In review |
"Current decisions" is the view to link everywhere: from your team wiki, your PRD template, and your onboarding doc. It is the answer to "what did we decide?"
Step 5: add automations
Automations keep the log visible without anyone remembering to share it. Notion's database automations use a trigger and one or more actions. Three are worth setting up:
Announce accepted decisions.
- Trigger: Property edited, when Status is set to Accepted.
- Action: Send Slack notification to your team channel, with the decision title and a link.
Announce replaced decisions.
- Trigger: Property edited, when Status is set to Replaced.
- Action: Send Slack notification to the same channel, so people stop following the old rule.
Weekly review reminder.
- Trigger: Every week, on Monday morning.
- Action: Send Slack notification to the decision owners' channel, linking to the Due for review view.
One plan detail: on Notion's free plan, only Slack notification automations are allowed. Other automations need a paid plan, so check what yours includes.
A filled-in example
Name: Free workspaces are capped at 3 projects
ID: 42
Status: Accepted
Owner: Priya (PM, Growth)
Approved by: Head of Product, Billing tech lead
Decided on: 3 November
Review by: 1 February
Area: Pricing
Source: Slack #growth thread, 2 November
Replaces: #31 Free workspaces have unlimited projects
Projects: Free plan limits
## Decision
Free workspaces can have up to 3 projects. Creating a 4th shows the
upgrade dialog instead of an error.
## Why
Heavy free usage costs more than it converts. A hard cap is easier to
explain than usage-based limits.
## Options we rejected
- Soft cap with warnings: users ignored warnings in the trial.
- Cap at 5: too few upgrades in the pricing model.
## What this changes
Billing enforces the cap server-side. Existing workspaces over 3 keep
their projects as read-only.
Rules that keep it alive
The database is the easy part. These habits decide whether it gets used:
- One owner for the log. Usually the most senior PM. Without one, filing stops within a quarter.
- Replace, don't edit. When a decision changes, create a new page, link it with Replaces, and set the old one to Replaced.
- Log it where it's decided. If the decision happened in Slack, the person who closed the thread files it the same day.
- Link from the work. Tickets and PRDs link to the decision's page, so people find it when they need it.
Where a Notion decision log falls short
Notion solves where decisions live. It doesn't solve how they get there. Every page is filed by hand, and decisions made in Slack threads and pull request reviews mostly never arrive. Notion also can't tell you when code or another document contradicts an accepted decision.
It also doesn't reach AI coding agents. An agent working in your repository doesn't open your Notion workspace unless something points it there. If you are deciding whether Notion is the right home at all, see Notion alternatives for tracking product decisions.
Where Lockstep fits
Lockstep reads Notion pages along with Slack threads, PRDs, and pull requests, drafts the decisions it finds, and sends each to its owner to approve in one click. Approved decisions brief Claude Code at the start of each session, and any MCP agent can query them. When one is replaced, the old version stays visible as replaced. Your Notion pages stay where they are; Lockstep tracks the decisions inside them.
Session briefings work with Claude Code today. See Lockstep for Notion.
Sources checked 5 November 2026
- https://www.notion.com/help/database-properties
- https://www.notion.com/help/database-templates
- https://www.notion.com/help/database-automations
Related reading
For the template in Markdown and spreadsheet form, use the decision log template. For a Jira version, see decision log in Jira. To compare tools, see the best decision log tools for product and engineering teams.
Frequently asked questions
- How do I make a decision log in Notion?
- Create a database called Decisions with one page per decision. Add properties for status, owner, decided date, review date, area, and source link, plus a two-way relation so a decision can point to the one it replaces. Make a database template with sections for the decision, reasons, and rejected options.
- Should I use Status or Select for decision status in Notion?
- Status. Notion's Status property groups options into To-do, In progress, and Complete, so you can put Proposed under To-do, In review under In progress, and Accepted, Rejected, and Replaced under Complete, then group a board view by those.
- Can Notion notify Slack when a decision is accepted?
- Yes, with a database automation. Use the Property edited trigger on Status, set to Accepted, with a Send Slack notification to action. Notion's free plan only allows Slack notification automations; other automations need a paid plan, so check yours.
- How do I show that a decision was replaced in Notion?
- Add a Relation property from the Decisions database to itself, turn on the two-way option, and name the sides Replaces and Replaced by. When a new decision replaces an old one, link them and set the old one's status to Replaced instead of editing it.
- Why do Notion decision logs go stale?
- Every page has to be filed by hand, and filing is the first thing to slip under deadline pressure. Decisions made in Slack or meetings never reach the database, and nothing tells you when an accepted decision has been reversed elsewhere.
Keep reading