> For the complete documentation index, see [llms.txt](https://docs.ixhello.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ixhello.com/knowledge-bot/functional-documentation/functional-capabilities/data-sources/integrations.md).

# 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 <a href="#important-note" id="important-note"></a>

**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 <a href="#related-documentation" id="related-documentation"></a>

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 <a href="#quick-summary" id="quick-summary"></a>

* **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 <a href="#beginner-explanation" id="beginner-explanation"></a>

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 <a href="#what-the-client-id-and-client-secret-mean" id="what-the-client-id-and-client-secret-mean"></a>

* **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 <a href="#why-sharepoint-is-special" id="why-sharepoint-is-special"></a>

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 <a href="#sharepoint-flow-explained-simply" id="sharepoint-flow-explained-simply"></a>

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 <a href="#sharepoint-what-must-be-configured" id="sharepoint-what-must-be-configured"></a>

#### Required values we need <a href="#required-values-we-need" id="required-values-we-need"></a>

* SharePoint **base URL**
  * example: `https://cnxmail.sharepoint.com`
* **Tenant ID**
* **Client ID**
* **Client Secret**

#### Important note about base URL <a href="#important-note-about-base-url" id="important-note-about-base-url"></a>

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:&#x20;

***

### Confluence: how it differs <a href="#confluence-how-it-differs" id="confluence-how-it-differs"></a>

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 <a href="#confluence-values-we-need" id="confluence-values-we-need"></a>

* Confluence **base URL**
  * example: `https://your-company.atlassian.net`
* **Client ID**
* **Client Secret**

More information:&#x20;

***

### Salesforce: how it differs <a href="#salesforce-how-it-differs" id="salesforce-how-it-differs"></a>

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 <a href="#salesforce-values-we-need" id="salesforce-values-we-need"></a>

* Salesforce **base URL**
  * example: `https://your-org.my.salesforce.com`
* **Client ID**
* **Client Secret**

More information:&#x20;

***

### What happens inside the Knowledge Platform <a href="#what-happens-inside-the-knowledge-platform" id="what-happens-inside-the-knowledge-platform"></a>

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 <a href="#configure-data-sources" id="configure-data-sources"></a>

**This view requires Admin permissions**

<figure><img src="/files/mOAyTYfk91MDrpFdLmYt" alt=""><figcaption></figcaption></figure>

&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ixhello.com/knowledge-bot/functional-documentation/functional-capabilities/data-sources/integrations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.