Knowledge connectors – Docebo Help & Support

Introduction

Knowledge connectors are how Docebo Knowledge gets its content. A connector links Docebo to a system your organization already uses to store knowledge, such as Confluence, Google Drive, or SharePoint, so that content from that system can be added to Knowledge collections and made available to your users.

At least one connector must be set up before you can create a Knowledge collection, since collections are built entirely from content made available through connectors. This can be done by Superadmins in “Knowledge connectors” under the “Add-ons and integrations” menu, after the feature was activated via the Launch pad.

Why connectors instead of file uploads

Docebo Knowledge is built around connecting to source systems rather than uploading individual files. This is a deliberate choice, and it's what makes the feature low-maintenance:

Content stays current automatically. Because a connector reads directly from the source system, any change made there, a page edited in Confluence, a file updated in SharePoint, is reflected in Docebo without anyone needing to re-upload or replace anything manually.
You don't need to build a separate permission structure. Uploaded files would need their own visibility rules managed inside Docebo. With a connector, permissions are inherited from the source system instead, so there's nothing extra to configure or keep aligned over time.

In short, once a connector is set up, keeping knowledge accurate and access correct is handled for you.

Two types of connectors

Connectors make content available in one of two ways. Both are found in the same place and are set up in a similar way, but they behave differently once connected.

	Indexing connectors	Live connectors
Systems	Confluence, Google Drive, SharePoint Files, SharePoint Sites, Notion, ServiceNow	Slack, Jira, Salesforce
Content	Synced to Docebo and indexed once added to a collection	Never copied or stored
When the source is accessed	When content is added to a collection, and on a schedule to keep it up to date	At the moment a user asks a question
What you add to a collection	Files, pages, folders, or spaces	Jira projects, Slack channels or Salesforce objects
Data volume	Indexed content counts toward it	Not counted

Indexing connectors: metadata first, content on demand

Connecting a system doesn't mean everything in it gets pulled into Docebo right away. Syncing happens in two stages:

At the connector level, Docebo syncs metadata only: things like folder and space hierarchy, file and page names, and structure. This is what makes the content browsable and selectable, but nothing is extracted or indexed yet.
At the collection level, when a Superadmin actually adds a piece of content to a Knowledge collection, that's the point where its content is extracted and indexed.

This two-step approach is intentional, and it brings two concrete benefits:

More trustworthy answers. Instead of an entire system being dumped into Docebo, only the content a Superadmin has deliberately curated into a collection becomes searchable and usable by search, the AI assistant, and agents. That curation step is what keeps answers relevant and trustworthy.
Lower cost. Since indexed data volume is what's priced, and only content that's been explicitly added to a collection gets indexed, you only pay for what your organization actually chooses to use. Connecting a system, and browsing it, never by itself creates any indexing cost.

Once content is indexed, it's kept up to date automatically, so changes in the source system are reflected in Docebo without manual maintenance.

Live connectors: searched at question time

A live connector never syncs anything. Once it's set up, it shows as connected immediately, and no content is copied, indexed, or stored in Docebo.

Instead, when a user asks the AI assistant a question, or uses an agent with Jira, Slack or Salesforce tools, Docebo queries the source system at that moment:

With the user's own account. The search runs as the user, so Jira, Slack and Salesforce apply their own access rules. The admin account used during setup is not used at question time.
Only where you allowed it. Searches are limited to the projects or channels a Superadmin added to the collection. Docebo enforces this restriction itself, so it doesn't depend on the AI.
Read-only. The connector only reads from the source system.
With a link to the source. Results used in an answer are shown with a link back to the original content in Jira, Slack or Salesforce.

The first time a user's request needs a live connector, they're asked to connect their own account. They approve access once on the source system's own consent screen. Since nothing is indexed, live connectors don't count toward your indexed data volume.

Setting up a connector

Setting up a connector is a technical task, and it will typically require support from your IT department. In practice, this usually means someone with administrative access to the source system (for example, a Google Workspace admin, a Microsoft Entra ID admin, or an Atlassian organization admin) needs to register an application for Docebo, grant it a defined set of read-only permissions, and share the resulting credentials so a Superadmin can complete the connection in Docebo.

A few things that make this easier to plan for and scope confidently:

Setting up a connector doesn't cost anything. There's no license fee or setup fee for connecting a system; the only cost tied to Docebo Knowledge is the indexed data volume described above, which only applies to indexing connectors.
You control the scope, right from setup. As part of connecting a system, you choose which part of it to make available to Docebo, for example, specific Confluence spaces, specific SharePoint sites, specific Google Shared Drives, or specific Slack channels. Anything outside that scope is never synced, or for live connectors never searched. This makes it straightforward to keep sensitive, confidential, or PII-heavy areas of a system out of Docebo entirely, without needing to first build any workaround inside the source system itself.
What each connector covers is clearly defined. Every connector works with a specific type of content (for example, files versus pages) and, within that, only certain content or file types. You don't need to guess or discover this after the fact: it's shown on the Overview tab when you start the setup, and documented in the first section of the setup guide for each connector.

Setting up your first connector

Each source system has its own dedicated setup guide with the exact steps to follow, written to hand directly to whoever is supporting you on the IT side:

A note on permissions

Docebo always enforces the permissions of the source system: a user can only find and use knowledge they already have access to there. How this works depends on the connector:

Connector	How access is checked	What users need
Confluence, Google Drive, SharePoint files, SharePoint sites	Permissions are synced from the source system, and each user is matched to their source system account by email	The email address in Docebo matches the one in the source system, and Docebo can trust it (see below)
ServiceNow	Each article is shown to users whose email matches a ServiceNow user who is allowed to read it. Script-based user criteria are only applied for users who connect their own ServiceNow account	The same email match. Until a user connects their own account, they may see articles that a script-based criterion would hide from them
Notion	Notion doesn't provide page-level permissions, so they can't be synced. Each result is checked live with the user's own Notion account	Users connect their own Notion account. Until they do, Notion results aren't shown to them
Jira, Slack, Salesforce	Every search runs with the user's own account, so Jira, Slack and Salesforce apply their own access rules	Users connect their own account once, the first time it's needed

How Docebo trusts a user's email

For connectors that match users by email, Docebo needs to be sure the email on a user's profile really belongs to that user, so nobody can see someone else's content by entering their address. It decides this in two steps:

Single sign-on (SSO) first. If your platform uses SSO, the users are provisioned by your identity provider, and the provisioned user fields are locked so users can't edit them, then Docebo trusts the email as it is. Nothing else is required.
Otherwise, the verified email. If these SSO conditions aren't met, the email address on the user's Docebo profile must be verified. Verified means that the field “email_validation_status” needs to be set. This can be done via the Docebo API or directly for each user in the admin settings.

If you provision users via our API using Docebo Connect make sure that each user you provision has the email_validation_status set to 1.

Users whose email can't be trusted this way, or doesn't match any account in the source system, won't see any content from these connectors. It's worth checking this early, since it determines whether a given user will see knowledge results once collections are published.