What SharePoint does very well, and what it cannot tell you
In many organisations the knowledge base already exists: it is a SharePoint site. Procedures live in document libraries, work instructions keep their version history, site pages introduce teams and their rules. Microsoft 365 does what it was built for: store, share, find, and control who may open what.
What a library cannot tell you comes down to three questions: who can actually apply the procedure filed there, how many people still know how, and which critical knowledge has no document at all. A file called "Restarting line 2" proves that somebody once wrote something down. It does not tell you that the only person able to do it retires in eighteen months.
That is the whole gap between a document repository and knowledge management: the first keeps what was written, the second measures what the organisation knows and what it is about to lose. The SharePoint connector bridges the two without moving a single file.
What the connector reads, exactly
- Site pages (modern pages): the text of every web part.
- Document libraries, file by file, subfolders included down to six levels: Word (.docx), PDF, PowerPoint (.pptx), Excel (.xlsx), plain text, Markdown, HTML and CSV.
- The scope you set: one site address per line, or just the site of the base address. An optional filter restricts reading to the libraries whose name contains a given word ("Procedures", for instance).
Images, videos, archives and legacy Office formats (.doc, .xls, .ppt, pre-2007) are skipped without failing the run. A file is only read again when its version has changed: a second sync of an unchanged site downloads nothing, and your Microsoft 365 tenant is not hammered for no reason.
What it never does
It writes nothing to SharePoint: the permission requested is a read permission, and the driver has no write function at all. It uses no person's account and no user password: it signs in as an application registered in your own tenant, which you can revoke at any time. The access token issued by Microsoft lives for one hour and stays in memory; it is never written to the database. The application secret is encrypted in the server's vault and never shown again on screen.
Confinement remains the rule. When you save the connector, the only hosts it needs — graph.microsoft.com, login.microsoftonline.com and your sharepoint.com address — are allowed by name, for this connector only; they are removed with it, and every call is written to the outbound log. The product's AI stays local: the text it reads is never sent to an outside AI service.
Connecting it, in five steps
Allow about twenty minutes, plus someone who administers your Microsoft 365 for the first three steps (Application Administrator or Global Administrator role). They are done once.
- Register an application in the Microsoft Entra admin center: App registrations › New registration, accounts in this organisational directory only, no redirect URI. Write down the Application (client) ID and the Directory (tenant) ID.
- Create a client secret (Certificates & secrets) and copy its value straight away: Microsoft will not show it again.
- Grant the permission: API permissions › Microsoft Graph › Application permissions › Sites.Read.All, then "Grant admin consent". If your policy requires it, pick Sites.Selected instead and have access granted site by site: the connector works the same way and only sees those sites.
- Connect it in KnowledgeCapital: Administration › Sources › Connect a system › SharePoint / Microsoft 365. Paste the address of any page of your site (the base address is detected), the application ID and the secret.
- Check, then sync. The check requests a token from Microsoft and lists each site's libraries; nothing is saved until you connect.
The tenant is inferred from the site address (acme.sharepoint.com gives acme.onmicrosoft.com). If yours was renamed, type "directory-ID/application-ID" in the Identifier field.
When "Check" says no
| Message | Likely cause | What to do |
|---|---|---|
| Microsoft rejects the application (401) | Wrong or expired secret | Create a new secret and paste it again |
| Unknown tenant (400) | Tenant wrongly inferred from the address | Type "directory-ID/application-ID" |
| Access denied (403) | Admin consent not granted, or Sites.Selected without access to the site | Grant consent, or open the site to the application |
| Address not found (404) | Wrong site address, or site closed to the application | Paste the address of a page of the site |
From document to knowledge: the links
Every page and file read is compared with your knowledge catalogue. When the full name of a piece of knowledge appears in a document — in the title the suggestion is strong, in the body only it is weaker — the system suggests a link, showing its score and the evidence behind it. The knowledge manager confirms or rejects: nothing is linked automatically, and a rejected suggestion does not come back.
The rule that explains almost everything: the knowledge name must be written as it is in your catalogue. A file called "Oven work instruction" will never meet a piece of knowledge named "Running the curing oven". Renaming the file, or naming the knowledge the way teams actually say it, is enough. The "Recompute links" button then runs every page already read against today's catalogue, without a single call to Microsoft.
What it changes on the knowledge map
- Each knowledge sheet lists its reference documents, with a link to the original in SharePoint.
- Search and the assistant find the site's pages and files; their title opens the original.
- The criticality of each piece of knowledge sits next to its documentation: red-zone knowledge with no document at all lands on a work list. It is often the first thing to get written down, or handed over before a retirement.
- Conversely, a document that matches no knowledge points to a gap in the catalogue: something teams document that the map does not know about yet.
To give an order of magnitude: if six files in a library changed since the last run, only those six are downloaded and read again, however many documents the site holds.
SharePoint, Confluence, a DMS: which one to connect?
As many as you have. Each system is one more connector, on the same screen and under the same rules: Confluence (the only one that can also receive the sheets your committees validate), your document management system through CMIS or WebDAV, Notion, your intranet, and any other tool through the API. An on-premises SharePoint Server that exposes a CMIS root connects through the DMS connector.
Connectors are included from the Professional plan upwards, and in the sovereign edition installed on your servers. On the hosted service, an hourly clock re-reads every connector whose frequency is due; on your own servers, a scheduled task does the same. To decide where to start, the guide on building a knowledge management system from scratch gives the order of the steps.
SharePoint, Microsoft 365, Microsoft Entra and Microsoft Graph are trademarks of Microsoft Corporation; Confluence is a trademark of Atlassian. KnowledgeCapital is neither affiliated with nor endorsed by these companies.