SharePoint Connector

The SharePoint connector syncs documents from Microsoft SharePoint Online into a Knowledge base, so an AI Employee can search and cite that content in its answers. It reaches SharePoint through the Microsoft Graph API and offers three authentication modes, chosen with the Authentication Mode selector:

• App Credentials: an Azure AD app registration with a client secret. This is the default and the usual choice.
• App Certificate: the same app registration proving itself with an uploaded X.509 certificate instead of a secret. Use it when your Azure AD app is configured to reject client secrets.
• Sign in with Microsoft: delegated OAuth2, where an individual signs in with their own Microsoft account.

A connection stores only credentials; it is not tied to any one site. You choose which sites, libraries, and folders to ingest on each Knowledge base built from the connection.

You set up a SharePoint connection from the Data sources tab of the Integrations page. The creator chooses whether it is a Shared or Private connection (see Authentication and connections); builders never see credentials and reference the resulting Knowledge base when configuring a workflow.

What it ingests

For each Knowledge base you point the connector at one or more SharePoint URLs: a site, a document library, or a folder. The connector resolves each URL to its site and library, walks every subfolder under it recursively, and ingests each file it finds. Because scope is set per URL, one connection can span multiple sites and more than one document library. Files are downloaded and sent through the shared ingestion pipeline (extract → chunk → embed → store) described in Data Connectors.

For each file the connector captures its name, folder path, MIME type, size, and a source version tag used for incremental sync. Only file types the pipeline can extract are processed (see Limits). Access problems never fail the whole sync: a subfolder the identity can't read is skipped with a warning, and any URL that can't be reached (no access, wrong tenant, a deleted site, or a temporary error) is recorded as a skipped target while the remaining URLs still sync. Each URL shows a Synced or Skipped badge in the Folder scope card after a run.

How to connect

Open the Data sources tab, select the SharePoint tile, and choose an Authentication Mode. All modes ask for a connection name; App Credentials and App Certificate also take an optional description plus your Azure AD app details.

App Credentials mode

App Credentials mode authenticates as an Azure AD app registration using the client-credentials flow, with no interactive sign-in. The setup form collects:

To produce those credentials, the in-product setup guide walks you through Azure:

1. In the Azure portal, go to Microsoft Entra ID → App registrations → New registration. Name it (for example, "Ema SharePoint Connector") and choose single-tenant.
2. On the app Overview page, copy the Directory (tenant) ID and Application (client) ID.
3. Under API permissions, add Microsoft Graph → Application permissions for Sites.Read.All and Files.Read.All, then Grant admin consent (requires admin rights).
4. Under Certificates & secrets, create a new client secret and copy its Value immediately. It is shown only once.

Paste the three values into the form and select Create connection. Ema validates the credentials by acquiring a token from Azure AD before storing the connection; the specific sites and folders are checked later, when you scope a Knowledge base.

App Certificate mode

Use App Certificate mode when your Azure AD app registration is set to reject client secrets and require a certificate. It authenticates as the same app registration but proves possession of an uploaded X.509 certificate instead of sending a secret, with no interactive sign-in.

Setup matches App Credentials through the Azure app-registration steps; the difference is in Certificates & secrets: instead of creating a client secret, open the Certificates tab, select Upload certificate, and upload the public certificate (.cer/.pem). Note its expiry, as syncs fail once the certificate lapses. Never upload the private key to Azure.

The form collects the same Connection name, Description, Azure Tenant ID, and Client ID, plus one field:

Select Create connection to validate and store.

Sign in with Microsoft (delegated)

This mode uses the OAuth2 authorization-code flow: you sign in with your Microsoft account and consent to read access, with no service principal or admin consent step required up front. It is available only when SharePoint OAuth2 is configured on your Ema platform; the form disables it and shows a notice when it isn't.

To connect:

1. Select Sign in with Microsoft mode and enter a connection name.
2. Select Connect with Microsoft. Ema redirects you to login.microsoftonline.com with a signed state parameter for CSRF protection.
3. Approve the requested scopes: Files.Read.All, Sites.Read.All, and offline_access.
4. Microsoft redirects back to Ema's callback, which exchanges the one-time code for an access and refresh token, runs a live test against the site, and stores the tokens encrypted.
5. The Data sources tab shows a success banner and the new connection appears in the list.

Connection visibility

Every connection is either Shared (usable by anyone in the workspace) or Private (visible only to you). The visibility selector appears on the connect dialog and on each connector's create page.

Connections created from the Knowledge Base connect dialog are Private by default. If you want a Shared connection so that other builders can also use it as a source, select Shared before completing the connection. Builders and admins may create Shared connections; roles below builder cannot.

Selecting Shared shows a disclosure: a Knowledge Base built on a Shared connection serves its documents to every reader without checking who is asking, because SharePoint's per-document access control is not captured at ingest time in most configurations. Anything the connected account can read becomes readable to everyone who can open that Knowledge Base.

A workspace admin can change a connection's visibility on its detail page after creation. Only the connection's owner can promote a Private connection to Shared, because a Private connection is not visible to anyone else, including admins. If the person who created a Private connection is unavailable and it needs to be changed, the connection must be deleted and recreated.

Sync configuration

Scope and schedule are set on the Knowledge base built from the connection, not on the connection itself. One connection can feed several Knowledge bases, each scoped to different folders.

Folder scope

A SharePoint source syncs nothing until you give it at least one URL; there is no whole-site or whole-tenant default. In the Knowledge base's Folder scope card, add one or more Folder URLs: a site URL (e.g. https://contoso.sharepoint.com/sites/engineering), a document-library URL, or a folder URL as it appears in your browser's address bar. Ema normalizes each one, handling URL-encoding and SharePoint view URLs (the .../Forms/AllItems.aspx form, including id/RootFolder parameters) automatically. Only files under the URLs you supply are ingested.

Schedule

In the Knowledge base's Sync configuration, set:

• Sync enabled: turn syncing on or off.
• Schedule: Interval (sync automatically) or Manual (only on demand). For interval, set the interval in minutes.
• Sync now: trigger a one-off sync at any time.

Syncs are incremental: the connector compares each file's eTag against the stored content hash and skips unchanged files, so re-syncs only process what changed. The page shows the last and next sync times.

Citations in Teams

When an AI Employee answers a question in a Microsoft Teams channel, SharePoint Knowledge base sources appear as a Sources footer on the answer card. This applies to both DAG workflow AI Employees and orchestrator AI Employees.

The link in the footer is the document's own SharePoint web URL (the same URL you would open in your browser), not a temporary presigned link. Clicking it opens the document directly in SharePoint, subject to the user's own SharePoint permissions.

Limits and behavior

• Scope is set per URL, not per connection. One connection can ingest from multiple sites and from more than one document library; it only crawls the URLs you add to a Knowledge base, never a whole tenant automatically.
• Supported file types only. Extractable types are PDF; Word, Excel, and PowerPoint (.docx, .xlsx, .pptx); plain text, Markdown, CSV, HTML, and JSON; and images (.png, .jpg, .webp, .gif) read via a vision model. Other types are counted as unsupported and skipped.
• Read-only. Both modes request read scopes only; the connector never writes back to SharePoint.
• Partial access is tolerated. Subfolders the identity can't read are skipped with a warning; the sync continues for everything else.
• Rate limits from Graph (HTTP 429/503) are retried with Retry-After back-off, capped at five minutes per wait, up to three attempts.
• Files whose contents contradict their declared type fail visibly. If a file's bytes do not match its extension (for example, a spreadsheet renamed to .csv, an Excel "Unicode Text" (UTF-16) export, or any binary saved with a text extension) the sync marks the document as failed and records the real format in the error (for example: "renamed_spreadsheet.csv cannot be ingested as text/csv: its content is legacy Microsoft Office (OLE2 .xls/.doc/.ppt)"). The file appears in the Knowledge base document list as a failed item rather than being silently absent. Re-syncing without changing the file will not help; the bytes are the same. The fix is in SharePoint: save the file as a real CSV (UTF-8), or give it its true extension so Ema ingests it with the right parser.
• SharePoint CSV files previously dropped silently are now recovered by an ordinary re-sync. Microsoft Graph reports application/vnd.ms-excel as the MIME type of a .csv stored in SharePoint, not text/csv. Before September 2026 this caused every SharePoint CSV to be counted as unsupported and skipped; no document row was created and the sync log showed no failure. This is now fixed. Any Knowledge base whose SharePoint library contains CSV files was missing them; an ordinary sync is enough to recover them (no full sync needed). Because the skipped files were never documents, Ema treats them as new on the next sync and adds them. Legacy .xls and .xlsm files remain unsupported; they report the same MIME type as a SharePoint .csv and cannot be read by the extractor.

What's next

• Data Connectors — the connection model, the ingestion pipeline, and how connectors compare to Tools.
• Google Drive Connector, Confluence Connector, Box Connector — the other source connectors.