Integration guide

Notion integration for AI agents and workflows

Swfte Studio has a Notion node with three actions in its shipped data: search the workspace for databases, query the pages in a database, and create a page. A workflow can read from Notion on its own, and you can put a person’s approval in front of the step that creates anything.

This page keeps to those three actions. It also says what the data does not show: no Notion trigger, no action that edits or archives an existing page, and no Notion entry in the MCP tool list. Notion is reached through the workflow node, not through an MCP server.

Built in Swfte Studio, run as a governed workflow, and held to the same rules as any governed agent.

Notion at a glance

Catalogue
Productivity
Actions in the shipped data
3 (2 read, 1 write)
Credential type shown
A stored credential, referred to by id
MCP server
None in the MCP tool list
Shipped templates that use it
notion database workflow

What you can do with Notion

Every action below is read from a node in a shipped workflow template. Nothing is listed that the data does not show.

Notion actions in the shipped workflow templates
ActionTypeOperationWhat the data shows
Search for DatabasesReadsearchSearches the workspace. The shipped template filters the search to databases and asks for ten results.
Query Database PagesReadquery_databaseReads the pages in one database, chosen by its id. The template asks for five.
Create New PageWritecreate_pageAdds a page under a parent database, with a title property. The template stamps the title with the time of the run.

Two reads and one write. Nothing in the shipped data edits, moves or deletes a page, so the workflows below only add pages, and they add them for a person to review.

The template starts from a plain start node. A Notion event, such as a page being added to a database, does not appear in the data: <Notion trigger events - founder to fill>.

What sits in a Notion workspace, and why that matters for an agent

Notion tends to hold the working memory of a team: meeting notes, roadmaps, wikis, hiring trackers and policy pages. Many of those live in databases, where every row is a page with properties. An agent that queries a database reads whatever the connection has been shared with, so the first control is the share list. Connect the databases the workflow was designed for, and leave the rest of the workspace out.

Creating a page is a write, and in Notion a new page is visible to everyone who can see its parent. That makes create-page closer to publishing than to saving a draft. The shipped template handles one real-world case well: it checks whether any database was found and, if none was, takes a separate branch that outputs “No Database Found” instead of carrying on with empty values.

How to connect Notion

The shipped Notion workflow carries no keys. Each Notion node points at a stored credential by id, so you create the connection once and every Notion node in the workspace can use it.

  1. 01

    Create the credential

    Add a Notion credential in Studio. The data does not say which kind it is: <Notion credential type - founder to fill>.

  2. 02

    Share only what the workflow needs

    In Notion, share the specific databases with the connection. A database that has not been shared cannot be searched, which makes the share list a low-cost limit.

  3. 03

    Run the search on its own first

    Look at what comes back before you add the query or the create step. A surprising database name is a finding, not a nuisance.

  4. 04

    Add the approval before the write

    Put a human-input step in front of the create-page node, addressed to the person who owns the target database.

Three governed Notion workflows to build in Studio

Each has a label. A starting point builds on a shipped template, which is an integration test with no approval step. A design is intent only.

Weekly roadmap digest for review

Starting point

Builds on the shipped template “notion database workflow” (9 nodes), which you can find in the template library.

Turn the pages of a roadmap database into a one-page summary that a product lead approves before it appears in the workspace.

  1. Search for the roadmap database, then query its pages.
  2. An LLM node writes a short digest from the page titles and properties.
  3. A human-input step sends the draft to the product lead, with approve and reject branches.
  4. On approval, the create-page node adds the digest. A rejection ends the run and keeps the editor’s reason.

Where the approval sits. The shipped template creates its page straight away. The approval step and the choice of parent database are the parts you add.

Meeting notes to an action register

Designed

Pull action items out of meeting notes and file them in a tracker database, with the meeting owner confirming each batch.

  1. Query the meeting-notes database for pages from the last week.
  2. An agent node lists the action items it finds, with the page each came from.
  3. A human-input step goes to the meeting owner, who approves or rejects the list.
  4. Each approved item becomes a page in the action database through the create-page node.

Where the approval sits. Approval is per batch, so nothing is filed that an owner has not seen. A rejected list files nothing.

Policy page review prompts

Designed

Remind page owners that a policy page is due for review, without touching the page itself.

  1. Query the policy database for its pages.
  2. A code node keeps the pages whose review date has passed.
  3. For each due page, the agent drafts a review note that names the page and its owner.
  4. A human-input step goes to the compliance lead. On approval, the create-page node adds the note to a review-queue database.

Where the approval sits. The workflow never edits the policy page, so a mistake costs one extra row in a queue and not a changed policy.

Shipped template
A governed template with its approval step already in it ships in the platform.
Starting point
A shipped template runs the same actions. It is an integration test with no approval step, so you add the gate.
Designed
Design intent. It uses the actions listed above plus generic nodes, and nothing has been built as a template.

Approvals and records for Notion

Notion holds drafts, plans and sometimes sensitive pages, so the question for each workflow is what it may read and what it may publish.

Needs a person’s approval

  • Creating a page in any database that more than your own team can see.
  • Any run that reads databases holding people, legal or finance material.
  • A change of parent database in a workflow that has already been approved.

Can run without one

  • Searching for databases the connection was shared with.
  • Querying a team-only database to build a digest that only the team reads.

What is recorded

  • Which Notion actions ran in each workflow run, and in what order.
  • The approver’s answer on each draft, and when they gave it.
  • Any policy decision, such as a redaction or a deny, taken before the page was created.

The human-input step, the policy engine and the run ledger are built in the product. The policy engine only acts on runs that have a policy attached, so attach one before you rely on it. None of this makes Notion itself stricter: who can see a page is still decided in Notion.

A policy step in a design below describes the intent. The policy engine acts only on runs that have a policy attached, and a self-serve way to author policies is not something we describe as built.

Swfte’s own security position and any attestations are on the trust page. How approvals, policy and records fit together is on the governed agents page.

Comparing tools for Notion work

These comparison pages are dated and sourced. Each says who should pick the other tool.

  • Glean alternatives

    If your main need is search across Notion and your other tools, the Glean comparison says when that suits you better than a workflow builder.

  • n8n alternatives

    If you are comparing workflow builders for Notion work, the n8n comparison sets out the differences in hosting and governance.

  • Best automation platforms

    How automation platforms compare on governance, approvals and records, with the method shown.

Notion questions

Does Swfte have a Notion MCP server?

No. The MCP tool list in Swfte’s generated data has eight entries: Firecrawl, Stripe, GitHub, GitLab, Slack, Postgres, Puppeteer and Filesystem. Notion is not one of them. You reach Notion through the Studio workflow node described on this page.

Can an agent edit or delete existing Notion pages?

Not with the actions in the shipped data, which are search, query and create. Design workflows that add pages for people to merge by hand, and check the node in Studio before you assume more.

How do I stop a workflow writing to the wrong database?

Share only the intended database with the connection, set the parent database in one place at the top of the workflow, and put an approval step in front of the create-page node. The approver then sees the draft before it exists in Notion.

Is there a Notion template I can start from?

Yes, one: the notion database workflow in the shipped templates. It searches for databases, queries a database and creates a page. It is an integration test with no approval step, so treat it as a starting point and add the gate yourself.

What does Swfte record when a workflow writes to Notion?

The run ledger records the policy decisions, the approvals and the actions for the run, including the create-page action. That record is separate from Notion’s own page history. There is no dedicated ledger export yet, so tell us what you need to keep.

Build a governed Notion workflow

Begin with a read-only workflow on a test account, then add one write with an approval in front of it.

Build this in Studio

Describe what you need in plain language. Studio builds the agents and workflows, and you keep every version.