Dawn already connects to repositories, ticket systems, and cloud storage. Confluence and Notion are the next step — two of the most widely used documentation systems, and two of the most requested integrations since Dawn launched.
This release adds first-class support for both. Link your Confluence spaces or Notion page trees to a workspace, assign them to agents, and those agents can browse, search, and read from them like any other connected source.
Confluence
Connecting Confluence follows the same model as other Dawn integrations. The workspace owner adds a connection using a Confluence Cloud site URL, an Atlassian account email, and an API token. Once connected, Dawn discovers the spaces that account can see, and the owner chooses which ones to link.
From there, agents assigned to those linked spaces can browse, search, and read pages within them. Ask an agent to check the deployment runbook before answering a question about rollback procedures, and it pulls from the actual Confluence page your team maintains — not a stale copy or a guess.
Confluence spaces tend to accumulate a lot of content over time. Teams do not always know exactly which page has the answer, but they know the space. Dawn handles that naturally — an agent assigned to a linked space can search across pages, follow the hierarchy, and pull from the right section without the person asking needing to know where it lives.
That is especially useful for operational documentation. Runbooks, incident postmortems, environment setup guides — the kind of content that is critical when you need it and invisible the rest of the time. An agent with access to the right Confluence space surfaces it in context, right when the question comes up.
Notion
Notion works slightly differently because of how Notion handles access. Instead of user credentials, Dawn connects through a workspace-owned internal integration token with the Read content capability.
The key concept is the shared root page. When you create a Notion integration and share specific pages with it, Dawn discovers those page trees and treats them as the boundaries for agent access. Agents can traverse and read any descendant within a linked root, but they do not wander outside it. That boundary is important — it means the workspace owner controls exactly how much of Notion is visible to Dawn, and agents stay within the scope they were given.
In practice, most teams share one or two root pages that contain their product docs, engineering handbook, or team wiki. The agent can walk the full tree under those roots — nested pages, sub-pages, databases rendered as pages — and treat the content the same way it would treat any other connected source.
Notion pages also tend to be more structured than raw documents. Teams use them for PRDs, project trackers, meeting notes, and decision logs. When an agent reads a Notion page, it gets that structure intact, which means answers that reference Notion content can be more specific than a generic summary.
What This Changes Day to Day
The practical difference is that agents can now ground their answers in the documentation your team already maintains in Confluence or Notion. That changes the quality of responses for any question where context matters.
A support agent can search the engineering wiki before responding to an internal question. A planning agent can read the Notion PRD before suggesting scope changes. Someone asking about an incident can get an answer grounded in the current operational playbook rather than whatever the agent was last trained on.
It also changes how teams think about keeping documentation current. When agents actively use your wiki pages and Notion docs to answer questions, outdated content becomes a visible problem — the answers start being wrong in ways people notice. That creates a natural feedback loop: the team updates the page, and the next answer is better.
For teams that split their knowledge across multiple systems — code in GitHub, tickets in Jira or Azure DevOps, long-form docs in Confluence or Notion — this release means Dawn can now reach across all of those when answering a question. The agent does not need to be told which system has the answer. It searches the sources it has access to and works from what it finds.
Scoping What Agents Can See
Both integrations give you control over what is exposed. With Confluence, you choose which spaces to link — not every space the account can see has to be visible to agents. With Notion, the boundary is the shared root page — only the trees you explicitly share with the integration are discoverable.
On top of that, linked sources are assigned to specific agents. A support agent might have access to the operations wiki and the incident postmortem space, while a product agent only sees the PRD pages in Notion. That scoping is per-agent, so different agents in the same workspace can have different documentation views.
This matters for teams with sensitive documentation. You do not have to choose between giving an agent access to everything or nothing. Link the sources that are relevant, assign them where they belong, and leave the rest unconnected.
Getting Started
The setup guides cover the exact connection shape Dawn expects today:
Both integrations follow the same workspace-owned connection model: create the connection, discover sources, link only what you want exposed, and assign those sources to the agents that should use them. If you have already connected a repository or a ticket system, the pattern will feel familiar.