Integrations

The Knowledge Platform supports connectors for external systems such as SharePoint, Confluence, and Salesforce.

To connect external systems to the Knowledge Platform, the setup is done in 2 layers:

1. External platform setup

   • SharePoint -> Microsoft Entra App Registration

   • Confluence -> Atlassian OAuth app in Developer Console

   • Salesforce -> Salesforce External Client App / Connected App

2. Knowledge Platform setup

   • configure the connector in Configure Data Sources

Important note

Configure Data Sources requires Admin permissions.

Connector setup always happens in 2 steps:

1. The external system must be configured to generate the required credentials and allow Knowledge Platform access.

2. Those credentials must then be entered in the Knowledge Platform under Configure Data Sources.

Related documentation

For a high-level explanation of how connector authentication works, what credentials are needed, and why SharePoint differs from Confluence and Salesforce, see:

in simple terms, how connector authentication works in the Knowledge Platform, what credentials are needed for each provider, and why SharePoint differs from Confluence and Salesforce.

Quick Summary

• SharePoint uses a Microsoft App Registration in the customer's Microsoft tenant.

• Confluence uses an Atlassian OAuth app created in the Atlassian Developer Console.

• Salesforce uses a Salesforce External Client App / Connected App.

• In all 3 cases, the goal is to generate a client ID and client secret that identify the Knowledge Platform to the external system.

• For SharePoint, a tenant ID is also needed because Microsoft authentication is tenant specific.

• Having a client ID and client secret alone is not enough. The external configuration must also include the correct permissions/scopes and redirect URI.

Beginner explanation

An external platform does not allow any random application to read its data.

Before the Knowledge Platform can connect, the external platform needs to know:

1. Which application is requesting access

2. Whether that application is trusted

3. What that application is allowed to do

That is why each provider has its own way to register or define an application identity.

The naming is different, but the concept is similar:

• Microsoft / SharePoint -> App Registration

• Atlassian / Confluence -> OAuth app

• Salesforce -> External Client App / Connected App

What the client ID and client secret mean

• Client ID = the public identifier of the application

• Client Secret = the private secret used by the backend to prove the application's identity

These values are generated by the external platform configuration, not by the Knowledge Platform itself.

---

Why SharePoint is special

SharePoint is part of the Microsoft 365 / Entra ecosystem.

That means:

• the SharePoint site belongs to a Microsoft tenant

• the Microsoft login/token endpoints belong to that tenant

• the App Registration should normally be created in that same tenant

So the correct mental model is:

SharePoint and the App Registration belong to the same Microsoft tenant.

Example:

• SharePoint site: https://cnxmail.sharepoint.com/sites/AppDev_Global_IX_Wisdom/...

• expected setup: App Registration in the Microsoft tenant that owns cnxmail.sharepoint.com

If those do not match, authentication or authorization usually fails.

SharePoint flow explained simply

1. The customer creates a Microsoft App Registration in the same tenant as their SharePoint.

2. That registration generates:

   • Client ID

   • Client Secret

   • Tenant ID

3. They configure the required delegated permissions.

4. They add the correct callback URL used by the Knowledge Platform.

5. They provide the credentials to us.

6. We configure the SharePoint connector in Configure Data Sources using:

   • base URL

   • client ID

   • tenant ID

   • client secret

7. A user authenticates with Microsoft.

8. The backend exchanges the authorization code for tokens.

9. The Knowledge Platform uses those tokens to browse and ingest SharePoint content through Microsoft Graph.

SharePoint: what must be configured

Required values we need

• SharePoint base URL

  • example: https://cnxmail.sharepoint.com

• Tenant ID

• Client ID

• Client Secret

Important note about base URL

The connector configuration is matched by base URL, not by the full long SharePoint path.

Example:

• full target URL:

  • https://cnxmail.sharepoint.com/sites/AppDev_Glo...

• connector base URL:

  • https://cnxmail.sharepoint.com

More information:

---

Confluence: how it differs

Confluence does not use a Microsoft App Registration.

Instead, the customer creates an OAuth app in the Atlassian Developer Console.

That app generates:

• Client ID

• Client Secret

Confluence values we need

• Confluence base URL

  • example: https://your-company.atlassian.net

• Client ID

• Client Secret

More information:

---

Salesforce: how it differs

Salesforce also does not use a Microsoft App Registration.

Instead, the customer creates a Salesforce External Client App / Connected App.

In this implementation, Salesforce uses a client credentials flow, so it is more system-to-system and less user-interactive than SharePoint.

Salesforce values we need

• Salesforce base URL

  • example: https://your-org.my.salesforce.com

• Client ID

• Client Secret

More information:

---

What happens inside the Knowledge Platform

After the external platform setup is complete, the connector is configured in:

• Configure Data Sources

Important:

• This view requires Admin permissions

The connector configuration is stored per:

• application

• provider

• base URL

This means the same Knowledge Platform application can connect to multiple external environments, but each distinct environment needs its own matching connector configuration.

Configure Data Sources

This view requires Admin permissions