Notion Certification common mistakes
Notion Certification · Understand the traps and how to avoid them.
Treating a Notion workspace as if it had a single flat permission model, so the candidate grants a page-level permission and then assumes every nested child page and database inherits exactly that same access without checking inherited versus explicitly added members.
Candidates often study page sharing in isolation and never reconcile it with the separate concept of workspace-level membership, teamspaces, and the fact that a child can be shared with additional people while the parent restricts others. The mental model of 'permissions flow down and never diverge' is intuitive but wrong in edge cases.
What to do instead
Before answering, draw the hierarchy: workspace → teamspace → page → subpage/database. For each level, ask 'who is a member here, and is this access inherited or explicitly added?' Practice predicting effective access for a user who is in a teamspace but has been individually removed from one subpage. Memorise that explicit additions can extend access beyond the parent and that inheritance is the default, not the only rule.
Confusing teamspace membership roles with workspace owner/admin/member roles, and answering as if making someone a teamspace admin also gives them workspace settings access, or as if a workspace admin automatically can see every private page.
Both systems use similar words (admin, member, owner), so candidates collapse them into one ladder. The exam deliberately probes the seam between workspace-level administration and content-level access because that seam is where real incidents happen.
What to do instead
Build a two-column table: workspace roles (owner, admin/member tiers) versus teamspace roles (admin, member, and any content-only access). Write one sentence per cell describing what that role can and cannot do. Drill the specific question 'can a workspace admin read a private page they were never shared on?' and 'can a teamspace admin change billing or security settings?' until both answers are automatic.
Assuming that deleting or trashing a page, database, or teamspace permanently removes content immediately, and answering retention, recovery, or eDiscovery questions on that assumption.
Consumer-grade tools often behave this way, and candidates extrapolate. In Notion, trashed items sit in a recoverable state, workspace owners can restore them, and the trash interacts with plan-level retention and export behaviour. The distinction between 'trashed', 'permanently deleted', and 'retained for compliance' is exactly what the exam tests.
What to do instead
Learn the lifecycle as discrete states: active → trashed (recoverable, still visible to owners/admins) → permanently deleted. For each state, note who can see it, who can restore it, and whether it appears in exports or audit logs. Then map plan-level retention and audit features onto that lifecycle so you can answer 'what does a departing employee's content look like one week later?'
Treating guest access and external sharing as a binary 'on/off' setting, so the candidate misses that guests can be scoped to specific pages, that guest visibility differs from member visibility in search and mentions, and that domain restrictions and allowed-email settings change the answer.
Candidates prepare for internal collaboration and skim the external-sharing material, which is dense and settings-heavy. The exam asks scenario questions ('a contractor needs to comment on one database') where the correct answer depends on guest scoping rather than a global toggle.
What to do instead
For each external-sharing control, write the exact scenario it enables and the scenario it blocks. Practise the chain: invite guest → scope to page or teamspace → verify they cannot see siblings → verify search/mention behaviour → verify what happens when the guest's email domain is not on the allow list. Also confirm which settings only workspace owners can change.
Answering workspace-structure questions by nesting everything under one root page, then failing items that ask how teamspaces, sidebar sections, and top-level pages differ in navigation, permissions, and discoverability.
Personal Notion use encourages a single sprawling page tree, so candidates carry that habit into the exam. They underestimate that teamspaces are the primary unit for permission scoping and that sidebar organisation is a separate concern from access control.
What to do instead
Redesign a sample workspace on paper: decide which content belongs in a teamspace versus a private page versus a shared top-level page, and justify each choice by who needs access. Learn the trade-offs: teamspaces give clean permission boundaries and discoverability for members; deep page nesting gives flexibility but blurs ownership. Be able to recommend a structure for a given team size and collaboration pattern.
Confusing database templates with page templates and with duplicated pages, so the candidate picks the wrong mechanism when asked how to standardise a recurring document or enforce required properties.
All three produce a pre-filled page, so the surface behaviour looks identical. The differences are in where the template lives, whether it can be set as a database default, whether it can enforce property values, and how it behaves when the source is edited later.
What to do instead
Write a comparison of the three: page template (button or template gallery, reusable block content), database template (default for new rows, can preset properties, can be set as the default template for a database), and duplicate (a one-time copy with no ongoing link). For each, state what happens when you edit the original. Then answer practice prompts like 'new project row must always start with status Backlog and an owner property' by naming the mechanism and why the others fail.
Overstating what AI features can do inside a workspace, such as assuming AI can read content the user cannot access, or that AI-generated summaries and Q&A respect permissions automatically without configuration.
Candidates generalise from consumer AI assistants that index everything. Workspace AI is permission-aware by design, but the exact behaviour depends on what the user can already open, which workspace content is connected, and admin settings controlling AI availability.
What to do instead
Separate the capabilities: writing assistance on a page you are editing, Q&A over content you can access, and autofill or property generation in databases. For each, state the permission boundary explicitly ('results are limited to content the asking user can already view'). Learn which admin controls govern AI enablement and which data is excluded, and be ready to say what AI will not do, such as surfacing a private page to a teammate.
Ignoring the plan tier when answering feature-availability questions, so the candidate says a control exists (audit log, advanced permissions, longer retention, certain admin controls) when it is limited to higher plans or enterprise agreements.
Study material often describes the full feature set without gating, and candidates memorise capabilities without attaching them to tiers. Exam items frequently hinge on 'which plan is required' or 'what is available to this organisation'.
What to do instead
Maintain a feature-to-tier matrix for the controls you are most likely to be asked about: audit log, SCIM/provisioning, advanced permission settings, guest controls, retention, export options, and AI features. Mark each as available or not on the tiers you are responsible for. When an item mentions an organisation type, check the matrix before choosing.
Treating workspace settings, billing, and member provisioning as one undifferentiated 'admin' area, so the candidate cannot say who can invite members, who can change security settings, who can transfer ownership, and what happens when the last owner leaves.
These tasks all live in settings and all feel like 'admin stuff', so candidates skim the distinctions. The exam tests them because they are the highest-consequence actions in a workspace.
What to do instead
List the privileged actions (invite/remove members, change roles, enable security controls, manage billing, transfer or delete workspace, export all content) and for each record the minimum role required. Add the edge cases: what happens when the sole owner is deactivated, and how ownership transfer works. Rehearse the 'departing admin' scenario end to end.
Answering data-governance questions by describing what should happen rather than what the product actually does, for example asserting that content is encrypted in a specific way, that a particular export format preserves all metadata, or that a deleted user's pages are reassigned automatically.
Governance topics attract aspirational answers, and candidates fill gaps with plausible-sounding policy language. The exam rewards precise product behaviour, and vague 'best practice' phrasing usually maps to a distractor.
What to do instead
For each governance claim you plan to use, attach a source of truth: the specific setting, the specific export behaviour, or the specific admin action. Where you are unsure of exact behaviour, flag it and verify rather than guessing. Practise rewriting fuzzy statements ('data is protected') into concrete ones ('who can export, what the export contains, and who can restore deleted content').