Loading tutorials…
Loading tutorials…
Templates and buttons are how you turn Notion from a doc tool into an ops tool. They are also the features most teams skip. This walks the patterns that save 5-10 hrs/week.
Who this is forAnyone whose team rebuilds the same page structures repeatedly — meeting notes, briefs, project kickoffs, OKR reviews. If you have copied an old page and edited it more than 5 times, this tutorial replaces that with one click.
What you'll need
Step 1
Template the structural skeleton, not the content. If a page type recurs 10+ times per quarter, it needs a template. If 1-2 times, it does not.
List the recurring page types in your workspace. Common candidates: meeting notes (1:1s, all-hands, project sync), briefs (content brief, design brief, campaign brief), reviews (OKR review, retro, post-mortem), checklists (new hire onboarding, campaign launch, product launch).
For each candidate, ask: how many times per quarter does this page type get created? If >10, template it. If <5, skip — the template overhead exceeds the savings.
What NOT to template: one-off strategy docs, individual project pages, anything with unique structure. Templating these creates rigidity without benefit.
Rank candidates by frequency. Build templates for the top 5-7 first. You can add more later.
Common starter set for a marketing team: (1) Content brief, (2) Campaign brief, (3) 1:1 meeting notes, (4) Sprint planning notes, (5) Post-launch retro, (6) Weekly content review, (7) New hire onboarding checklist.
Step 2
Database templates auto-populate new rows with a pre-built page structure. This is where templates pay off most.
Open a database (e.g., Content Calendar) → click the dropdown arrow next to the 'New' button → 'New template'.
Build the template page: heading, intro callout ('Fill these in before moving to Drafting'), structured sections (Brief, Outline, Sources, Distribution), to-do list of mandatory steps.
Set default properties on the template: Status = 'Brief', Owner = (leave blank for assignment), Type = 'Blog post' (or whatever default fits).
Save the template. Now clicking 'New' on the database opens this template automatically.
Optional: create multiple templates for different sub-types. 'Standard brief' for short-form, 'Long-form brief' for pillar content, 'Social brief' for social posts. Each opens via the dropdown arrow next to 'New'.
Set one as the default: dropdown next to 'New' → '...' next to template name → 'Set as default'. New rows created without choosing a template use this one.
Step 3
Page templates (the 'Templates' gallery in the sidebar) are for standalone docs that recur — meeting notes, project kickoffs, retros.
Create the master template page somewhere logical (e.g., 'Templates' subsection under SOPs & Playbooks).
Build the structure: title format ('YYYY-MM-DD — [Meeting type] — [Participants]'), agenda section, notes section, action items section (as a to-do list), follow-ups section.
Use placeholder text in brackets: '[Date]', '[Participants]', '[Key decisions]' — visible cues for the user to replace.
When users need a new instance: they navigate to the template, click 'Duplicate' (top-right '...' menu), then move the duplicate to its destination.
Better: add a Button block on the team Home page that creates a copy in the right destination automatically (next step).
Step 4
Buttons (introduced 2023, polished through 2026) execute multi-step actions: create a page, add a database row, send a notification, all from one click.
On any page → type '/button' → 'Button' block.
Configure: Button label (e.g., 'Log activity'), then add actions.
Available actions: Insert blocks, Add page to (database — pre-fills properties), Edit pages in (database — bulk update), Show confirmation, Open page.
Common pattern 1 — Quick capture: a 'Log new activity' button on the CRM Home page that creates a new Activities row with Date = today, Type = (asks via confirmation), Owner = current user.
Common pattern 2 — Meeting prep: a 'Start 1:1 meeting' button that creates a new page in the 1:1 Notes database, sets Date = today, Participants = (asks), opens the new page immediately.
Common pattern 3 — Status bump: an 'Approve brief' button on each content item that sets Status to 'Drafting' and assigns to the owner.
Buttons feel like magic the first time they work. They are also the single highest-leverage Notion feature for repetitive workflows.
Step 5
A button that just creates an empty row is useless. The leverage is in the auto-fills: today's date, current user, default status, smart titles.
When configuring a button's 'Add page to' action, click each property to pre-fill.
Date properties: use 'Now' to set today. For 'Next Monday', use a Formula property on the destination database with formulaDateAdd(now(), 1, 'week').
Person properties: use 'Person who clicked the button' to assign to current user.
Status properties: hard-code the starting status (e.g., 'Brief' for new content items).
Title properties: use a Formula or hard-coded prefix. For meeting notes: format(now(), 'YYYY-MM-DD') + ' — [Meeting name]'.
Test the button by clicking it. Inspect the new row. Adjust if any property is empty when it shouldn't be.
Step 6
A button that deletes 50 rows should ask before firing. Confirmations prevent the "wait, no" moment.
On any button action, the third action option is 'Show confirmation'.
Use confirmations on: destructive actions (delete, archive, mass status change), bulk operations (edit 50 rows), actions that send external notifications (post to Slack, send email via integration).
Confirmation popup shows the label you set ('Archive all completed tasks?'). User clicks Confirm or Cancel.
Do NOT use confirmations on simple create actions — clicking the button is the confirmation.
Document which buttons have side effects in the SOP page. New hires need to know which buttons are safe to click for exploration.
Step 7
A 1-page directory of every template and button in the workspace. This is what makes templates discoverable.
Create a page 'Templates & Buttons Registry' under SOPs & Playbooks.
Table: Template/Button Name, What It Does, Where It Lives, Owner.
Document every template (database templates and page templates) and every button. Link directly to where each one is in the workspace.
Pin the Registry on the Home page under a 'Quick references' section.
Revisit monthly. Add new templates as they emerge. Retire ones with <1 use in the last quarter.
Common mistakes
No templates at all — everyone rebuilds pages from scratch
What goes wrong: Each teammate spends 20-30 min/week recreating meeting note structures, brief outlines, etc. A team of 6 = 2-3 hrs/wk = ~$8-12K/yr of avoidable labor + the cost of inconsistency (briefs missing fields, retros missing follow-ups, etc.).
How to avoid: Build the top 5-7 templates this week. Even basic templates eliminate 80% of the rebuild tax.
Templates that exist but are buried 4 clicks deep
What goes wrong: Templates exist in some folder but team members do not know where. They recreate pages from scratch anyway. Templates that go unused are pure overhead — 2-3 hrs of setup time wasted, no payoff.
How to avoid: Surface templates: (a) database templates via the New button dropdown, (b) page templates via Buttons on the Home page, (c) document in the Registry on the Home page.
Buttons without pre-filled properties
What goes wrong: Button creates an empty row that the user has to fill in entirely. No time savings vs creating a row manually. Worse: the user trusts the button and forgets to set properties → empty Status/Owner/Date fields silently break filters.
How to avoid: Every button's 'Add page' action should pre-fill at least: Date (today/now), Owner (person who clicked), Status (sensible default). Test by clicking and inspecting the new row.
Too many templates — 40+ in the workspace
What goes wrong: Team members do not know which template to use. They pick the first one or recreate from scratch. Maintenance overhead: someone spends 2 hrs/quarter updating templates that nobody uses.
How to avoid: Cap at 10-15 active templates. Audit quarterly — retire any template not used in 90 days.
Templates that hard-code names or dates that go stale
What goes wrong: A 'Weekly review' template that says 'Week of Jan 1, 2024' in the title gets duplicated 50 times in 2026 — every page says Jan 2024. Confusing and embarrassing in client-facing contexts.
How to avoid: Use placeholders ([Date], [Participants]) for variable content. Use button-pre-filled Date properties for the actual date — never hard-code dates inside template content.
Destructive buttons without confirmations
What goes wrong: An 'Archive all completed' button gets clicked by accident → 200 archived rows. Restoring takes 1-2 hrs of manual work + the trust loss with the team for 'breaking the database.'
How to avoid: Every button that bulk-edits, deletes, or archives must have a confirmation step. Test by clicking and confirming the popup appears.
Recap
Done — what's next
How to use Notion databases, relations, and rollups without breaking everything later
Read the next tutorial
Hand it off
Templates and buttons are quiet leverage — they save 5-10 hrs/week per team and make Notion feel like a real ops tool. A specialist will inventory your recurring workflows, build the templates, wire the buttons with smart pre-fills, and document the registry. Typically a one-shot $200-400 engagement, or part of ongoing ops support at $400-1,200/mo at $14-16/hr.
See specialist rates
Yes — Notion has a Template Gallery (notion.so/templates) where you can publish a duplicate of any page. For private team templates: the template lives in your workspace; share via the Share button with read access for guests, who can duplicate into their own workspace.
Not directly via Notion buttons — those are click-only inside the app. But: you can use Zapier or Make webhooks to mimic button actions. A Slack /command triggers a Zap that creates a database row via the Notion API — same outcome, more setup.
Database templates auto-populate when a new row is created in that specific database — used for content briefs, meeting notes, etc. Page templates are standalone templates you manually duplicate — used for one-off docs like project kickoffs or strategy docs. Database templates are higher leverage for recurring workflows.
Yes — the 'Edit pages in' action lets a button update multiple records matching a filter. Example: 'Archive all completed' button edits pages in the Tasks database where Status = Done, setting Status = Archived. Always pair with a confirmation step.
Notion has no native version control on templates. Workarounds: (1) keep a 'Templates — Archive' page where you copy old versions before changing the live one, (2) use the page-history feature (30 days on Plus, 90 days on Business) to recover prior versions. For truly mission-critical templates, document the structure in a separate spec doc.
Notion
Databases are the leverage in Notion. They are also the part most teams use wrong — flat lists with no relations, brittle formulas, and rollups that silently break. This walks the patterns that hold up at scale.
Notion
Most Notion content calendars die within 60 days because they were copied from a template without the workflow underneath. This walks the database, the views, and the status discipline that makes a content calendar the actual source of truth.
Notion
Every team starts a Notion wiki. Most have 800 orphan pages by year two. This walks the structure, the verification habit, and the governance that keeps a wiki alive and useful.