Provider Sources

Most of what your team actually knows about a system lives somewhere else — a Confluence space, a Notion database, a Jira project. Provider sources let you connect those platforms once at the org level, then browse them and pull the relevant pieces straight onto your boards.

You connect a provider with OAuth (or an API key for a few), authorize it for your org, and from then on you browse it hierarchically and add items as sources — one at a time, or in bulk. Every provider is a pull source: the platform fetches the content, and Chat reads it on demand — including building board structure from it when it governs and you ask. You don't push anything — we do the reading.

Available providers

These three are live today. Each connects with OAuth and brings in different shapes of content.

Connecting any of them follows the same two-part flow:

1. Authorize the provider for your org. Go to Settings → Integrations, find the provider, and connect it. You'll be sent through the provider's OAuth screen to grant access, then dropped back into the portal. This is a one-time, org-level step — once it's connected, everyone with the right access can use it.
2. Add items as sources. Open a board's (or workspace's) Sources panel, click Add Source, and pick the provider — a live browser of your authorized account opens. From there you select the items you want and add them — individually or in bulk.

Browsing and bulk-adding

Once a provider is connected, Add Source opens a hierarchical browser that mirrors how the platform itself is organized:

• Confluence — drill through spaces into their pages.
• Notion — navigate pages and databases.
• Jira — open a project and pick its issues.

You can add a single item — one Confluence page, one Notion database, one Jira issue — or select several and bulk-add them in a single pass. That's the fast path when an entire space or project is relevant: grab the whole set instead of clicking through one item at a time.

Each item you add becomes its own catalog source with type-specific metadata attached (which space or project it came from, its title, its identifiers). That means you can bind and reason about each piece independently — a single noisy page can be dropped without touching the rest.

Coming soon

These providers are on the way. They already appear in Connectors with a Coming soon badge, so you'll see them listed — but you can't authorize or add them yet.

Roles for provider sources

When you bind a provider source to a board, you give it a role: governing or reference.

A provider governs when it's the board's source of truth. A Confluence architecture space governing a documentation board is the canonical case — the pages shape the graph when you build or refresh the board from them in Chat, and after the pages change, you re-run that generation to bring the board up to date. Governing is what allows a source to shape the graph.

A provider is a reference when it's there for context, not control. ADRs, tickets, runbooks, design notes — content Chat reads on demand to ground its answers, but that never modifies the board itself. Ask and it pulls the whole document into the conversation; it can even draft a spec from a bound PRD, with your confirmation. Reference sources are unconstrained: bind as many as you like, of any types.

What's next