A Microsoft MVP helping you grow your business by empowering everyone to achieve more with Microsoft 365 and #Copilot
Melbourne
Joined February 2014
- Tweets6.7K
- Following452
- Followers1.4K
- Likes3.1K
Pinned Tweet
I've had early access to SharePoint knowledge bases, and there's plenty to get into.
Connected pages for people and agents, built from the documents you already have.
Here's what I've learnt from two builds, and what I'd plan before starting yours.
Building a SharePoint knowledge base leaves you with decisions about access, sources, ownership and updates.
I've pulled together what I'd plan around from two builds, including the preview limits and credits.
The full guide:
linkedin.com/pulse/sharepoin…
Start your SharePoint knowledge base pilot with a few questions one team asks regularly.
Choose approved sources, agree the audience and name the owner. Then review the structure Copilot proposes.
You'll have a clear purpose for every page you build.
A SharePoint knowledge base health check doesn't verify accuracy.
It can find broken links, pages missing from navigation and incomplete source references.
You still need someone to compare the guidance with its sources. Include that review before sharing it.
For each SharePoint knowledge base page, I'd plan:
- A useful description
- Consistent tags
- Source references
- An owner
- A review date
Decide those properties early. Retrofitting them across a few hundred pages is slow work.
Review your SharePoint knowledge base after a Copilot update, especially pages you've edited manually.
During preview, AI updates can reverse those edits or recreate deleted pages.
Include that review in the update process before people rely on the guidance.
Keep the source document visible from your SharePoint knowledge base guidance.
In my HR build, page properties linked back to the original Word documents.
When someone queries a policy, the reviewer has a source to check and an owner to follow up with.
Before importing content into a SharePoint knowledge base, check for drafts, duplicates and old guidance.
An import copies what's there.
I'd rather resolve conflicting versions in the source folder than leave readers to work out which KB page to trust.
Your SharePoint knowledge base needs someone responsible for requesting updates.
In my build, I changed the employee handbook, then asked Copilot to refresh the pages.
During preview, source changes don't update KB pages automatically. Give that request an owner.
I gave Copilot 30 HR, IT and onboarding documents to build a SharePoint knowledge base.
It proposed task-based sections with routes for employees and managers. The source documents stayed put, linked from the pages.
Here's the build:
youtu.be/vYLMopaKU7w
SharePoint knowledge base properties live inside the markdown file as YAML frontmatter.
I added leave tags through the page interface, then checked the file. The tags were there.
Your descriptions, tags and source references travel with the content.
Decide who can read your SharePoint knowledge base before adding sources.
KB pages don't inherit source permissions. Content from a restricted document can become readable by everyone with KB access.
Review the audience before asking Copilot to build.
Before Copilot builds your SharePoint knowledge base, ask it to propose the structure.
In my HR build, I reviewed the topics, navigation and routes for employees and managers first.
You can change a plan before you have pages to reorganise.
I imported an 84-page markdown knowledge base into SharePoint, with its hierarchy and page properties.
The structure you prepare becomes the structure people navigate. Review it before importing.
Here's the first-look build:
youtu.be/NVFZhF4FS5w
Your SharePoint knowledge base should follow the questions people ask.
A new starter needs to know what happens on day one. That answer might span HR, IT and onboarding documents.
Give them connected guidance they can follow through the task.
Daniel Anderson | Microsoft MVP retweeted
SharePoint + Copilot just got a lot more interesting 👀
I counted down my top 10 new things you can do, no developer required.
1. 🔎 Ask Copilot questions about SharePoint content
2. 📄 Compare different versions of SharePoint files
3. ⏪ Review SharePoint version history and restore previous versions
4. ✂️ Reorganize PDFs and extract pages into a new PDF
5. 🖼️ Edit images directly from a SharePoint document library
6. ✨ Create interactive HTML experiences from SharePoint content
7. 🌐 Create SharePoint pages and homepages from HTML
8. ⚡ Create workflows and approvals using natural language
9. 🧠 Create, test, and improve reusable Copilot skills
10. 📊 Use Copilot with SharePoint site analytics
Full video in the comments👇
Copilot in SharePoint gives you scope to delegate small, complete jobs where the documents already live.
Define the outcome, check the result and keep approval at the right step. This PDF workflow shows the approach:
youtu.be/R2uCU3Pw3Tk
There's useful Copilot and SharePoint work to do with the content you already have.
Choose information people repeatedly need help applying. Then build a better way to use it. Our policy checker illustrates that thinking:
youtu.be/2KRsVpcB3Ag
SharePoint can be where an AI-created business experience becomes part of everyday work.
The design may begin elsewhere. Publishing, navigation and ongoing ownership still need a home. This learning hub shows one approach:
youtu.be/RZcF6mcCeGg