How to Write Acceptance Criteria in Notion
Notion is where many product teams write their PRDs and specifications, making it a natural home for acceptance criteria — especially when AC needs to live close to the full product context rather than buried inside a ticketing tool. The challenge is that Notion is freeform, so without structure, AC ends up as scattered bullet points that QA cannot reliably act on.
This guide covers setting up a structured acceptance criteria system in Notion using database properties, linked views, and templates that make AC traceable from PRD to QA.
Step-by-step guide
Create an Acceptance Criteria database linked to your PRD
In your team workspace, create a full-page database called "Acceptance Criteria." Add a Relation property that links each AC row to your "PRDs" database. Add these properties: Story (text, the user story this AC belongs to), Criterion (text, the testable statement), Type (select: Functional, Error State, Performance, Accessibility), Status (select: Draft, Reviewed, Passed, Failed), and Ticket URL (URL linking to the Jira or Linear ticket).
Write each criterion as a separate database row
Create one row per acceptance criterion. In the Criterion field, write the full Given-When-Then statement. Example: "Given an unauthenticated user visits a protected route, When the page loads, Then they are redirected to /login with a ?redirect query parameter set to the original URL." Separate rows make it possible to filter by Status and see QA progress at the row level.
Add a template for new AC sets
Create a template in the AC database for a standard story with 5 AC rows pre-filled: one happy path, two edge cases, one error state, and one performance criterion. Each row starts as Draft status. This template prevents teams from skipping the error state and performance criteria that engineers forget to handle.
Create a linked view inside the PRD page
Open your PRD page in Notion. Add a linked database view of the AC database, filtered to show only rows related to this PRD. Set the view to a Table layout grouped by Type. This gives anyone reading the PRD a live view of all acceptance criteria without leaving the document.
Set up a QA handoff view
Create a new view of the AC database called "QA Handoff" filtered to Status = Reviewed. Add sorting by PRD (relation) so all AC for one PRD are grouped together. Share this filtered view URL with QA — they see only the finalized, reviewed criteria ready for testing, not drafts.
Update status as QA runs tests
When QA runs a test against a criterion, they update the Status field to Passed or Failed. For Failed rows, they add a comment on that row with a screen recording or screenshot. Use Notion comments (Cmd+Shift+M on a row) to tag the engineer who built the feature. The Relation to the PRD means any stakeholder can see exactly which criteria have passed at any point.
Common mistakes
Writing AC as inline text in the PRD instead of a database
Prose AC in a PRD section cannot be filtered, grouped, or tracked by status. It becomes stale the moment QA starts testing. Use a linked database so each criterion has a lifecycle.
No link between Notion AC and the engineering ticket
Without a Ticket URL field on each AC row, there is no way to trace from a failing test back to the Linear or Jira issue. Always populate the Ticket URL field when the story is created.
Mixing AC with implementation notes
AC describes user-visible behavior. Implementation notes ("use Redis for this") belong in a separate Technical Notes section of the PRD. Mixing them confuses QA and creates tickets that are not testable.
Only writing AC after the PRD is approved
AC should be drafted during PRD writing, not after. Writing AC first is actually a good practice for sharpening requirements — if you cannot write a testable criterion for a requirement, the requirement is probably too vague.
Tips
Use Notion's filter to create a personal view showing only AC rows assigned to your current sprint's PRDs
Add a "Complexity" number property to rate how difficult each criterion is to test (1-5) — QA uses this to time-box testing
Link each failed AC row to a bug report in your ticketing tool using the Ticket URL field
Archive the AC database for shipped features by changing their PRD relation status to "Shipped" — this preserves historical context without cluttering active views
How Vantage helps
Vantage generates acceptance criteria from PRD requirements as part of ticket generation. If you use Notion for documentation, you can export the generated AC and paste it into your Notion database, or use the Vantage API to sync requirements directly. Either way, the AC starts from your PRD language, not from scratch.