Skip to main content
Knowledge integrations bring documents from external sources into Flow. People search the synced copy of files they can already open in the source, after Flow has stored that grant. When enabled, search can also include connected Jira issues and web results.

Capabilities

  • Knowledge source bindings (Confluence, SharePoint, Google Drive, ServiceNow KB, and Notion where enabled)
  • Scheduled and on-demand sync
  • Search across synced content
  • Optional Jira and web search
  • Source status and sync details in Flow

Configuration

Knowledge sources are connected per team under Integrations. That team setting is how you pick the site, folder, space, or knowledge base and watch sync health. It is not the read lock.

Connect a knowledge source

1

Open Integrations, filter to knowledge integrations, and choose a provider.

2

Connect the provider and select the team and content to sync.

3

Run an initial sync and confirm that the intended content appears in Flow.

4

Enable Jira or web search in product settings if those options are available for your deployment.

Scopes and permissions

The provider connection needs read-only access to the content you want to sync. Write access is not required. See the individual provider pages for provider-specific requirements. For SharePoint, SharePoint Scoped, Google Drive, Dropbox, Box, and ServiceNow, Flow authorizes reads from the crawled provider access list. A person can read a file in Flow when the source already grants them access and Flow has stored that grant. Connecting the source to their team is not required to read. Connecting it does not grant read. Organization admins cannot bypass that source access. When Flow cannot determine who the source allows, it does not grant everyone access. Some SharePoint pages stay limited to the team that connected the source. ServiceNow can use an explicit team or organization setting. See SharePoint and ServiceNow KB. Org-wide Knowledge and org-wide search use only that source access. Team-scoped Knowledge and team-scoped search also require a source that team owns or later connected. For Confluence Cloud, an administrator chooses at connect time. One choice mirrors Confluence permissions, including restricted pages, and needs an Atlassian organization API key. The other choices use a Flow publication audience: the teams that connected the source, or the organization. Those publication choices skip restricted pages and do not use the organization API key. See Confluence Cloud. For Notion, the connection determines what Flow can crawl. Notion does not give Flow a reliable list of people who can view each page, so Flow does not copy Notion Share-menu, inherited team-space, group, guest, public-link, or per-user permissions. An administrator chooses the Flow publication audience: unpublished, the teams that connected the source, or the organization. A second team can connect the same Notion source. Its members read through that publication audience. They do not receive a Notion people snapshot. Missing or stale authorization state denies access. Notion crawl scope follows the root selected in Flow:
  • Page: the selected page and its structural descendants, including child pages and child databases.
  • Database or data source: every row plus structural descendants beneath those rows.
  • Workspace (when explicitly configured): all content that the connection can discover.
To choose a root, search the content shared with the connection, then open a result to browse what a crawl rooted there covers. A page lists its child pages and databases. A database lists its data sources, or its row pages when Notion does not return data sources. A data source lists its row pages. Select any item at any level. Search always spans the whole connection; there is no search inside an opened item. Flow does not expand a selected root through ancestors, siblings, relation properties, mentions, links, or other content merely available to the connection.

Provider pages