Cloud

Building a SharePoint Knowledge Base That Copilot Can Actually Use

June 30, 2026 · 6min read · The Technica Stack

When Microsoft 365 Copilot answers a question about your organisation — "What is our leave policy?" or "What are the payment terms in our standard contract?" — it retrieves information from SharePoint, OneDrive, and other M365 sources the user has access to. The quality of Copilot's answer is directly determined by the quality and structure of that underlying content.

Most Philippine organisations deploying Copilot discover this problem quickly: Copilot retrieves the wrong version of a policy, confidently cites outdated information, or returns no results because the relevant document is buried in a personal OneDrive folder no one else can access.

This guide covers how to build SharePoint in a way that makes both Copilot and human search effective.

Why SharePoint Structure Matters for Copilot

Copilot uses Microsoft Graph to retrieve content. Microsoft Graph respects SharePoint permissions — Copilot can only surface content the querying user has access to. It also uses semantic search to find relevant documents based on meaning, not just keywords.

The two failure modes:

1. Content the user can't access: A policy document stored in the HR manager's personal OneDrive is invisible to all other users — and to Copilot for those users. Critical knowledge locked in personal storage is the most common reason Copilot says "I couldn't find information about that."

2. Contradictory or outdated content: If SharePoint contains three versions of the leave policy — the 2021 version, the 2023 update, and a draft revision — Copilot may retrieve any of them. Without clear governance on which is the authoritative version, Copilot confidently cites outdated information.

SharePoint Architecture for a Knowledge Base

1. Separate Operational Files from Knowledge Content

Most Philippine organisations use SharePoint as a file server — project files, client documents, correspondence, drafts, and finished content all in the same site. For Copilot, this creates noise.

Recommended architecture:

Knowledge hub site (dedicated SharePoint communication site):

Contains only authoritative, published content
Policies, procedures, standard operating procedures
Product and service information
Onboarding materials
Frequently asked questions

Team sites (one per department or project):

Working files, drafts, project documents
Not the source of truth for policies
Copilot queries here will find project-specific information

Personal OneDrive:

Personal working files only — never the location for shared knowledge

2. Document Libraries: One Source of Truth

Create dedicated libraries for each knowledge category:

Library	Content
`Policies`	HR policies, IT policies, compliance policies — one document per policy, clearly named
`Procedures`	Step-by-step SOPs, work instructions
`Templates`	Official document templates with version date in the filename
`Products & Services`	Service descriptions, pricing guides, technical specs
`Client Resources`	Onboarding guides, user manuals, FAQs

Naming convention for policies: [Category]-[Name]-v[Version]-[YYYY-MM].docx Example: HR-Leave-Policy-v3-2026-03.docx

3. Retire or Archive Outdated Versions

Copilot has no concept of "this is the old version" unless you establish it structurally. For each document category:

Keep only the current version in the live library
Move superseded versions to an Archive subfolder (or separate archive library)
Apply a content type or column to mark documents as Active or Archived
Use SharePoint retention policies to automatically move documents older than a defined period to the archive

4. Permissions: Make Knowledge Accessible

Knowledge content should be accessible to all staff by default. The most common mistake is leaving the default permissions (department-only) on policies that should be organisation-wide.

Recommended permission structure for the Knowledge hub:

Site collection admin: IT + designated knowledge owner
Site members (edit): Department heads and document owners
Site visitors (read): All staff (company-wide)

For sensitive policies (executive compensation, disciplinary procedures), create a separate restricted library within the same site with appropriate access restrictions.

Metadata: Making Content Findable

SharePoint's search — and Copilot — works significantly better when documents have consistent metadata columns.

Minimum recommended columns for knowledge documents:

Column	Type	Example values
`Document Type`	Choice	Policy / Procedure / Template / FAQ / Reference
`Department`	Choice	HR / IT / Finance / Operations / Legal
`Status`	Choice	Active / Draft / Under Review / Archived
`Effective Date`	Date	2026-03-01
`Document Owner`	Person	The individual responsible for keeping it current
`Review Due`	Date	2027-03-01

When a user asks Copilot "What is our current IT security policy?", Copilot can use the Status: Active, Department: IT, and Document Type: Policy metadata to narrow the search to the correct document — rather than returning all documents containing "IT security."

Content Standards for Copilot-Readable Documents

Copilot extracts meaning from document content. Documents written for Copilot retrieval share characteristics with documents written for human readability:

Use descriptive headings: Copilot uses headings to understand document structure. "Section 3" is unhelpful; "Section 3: Leave Entitlements for Regular Employees" is directly retrievable.

State the key facts explicitly: "All regular employees are entitled to 15 days of vacation leave per year" — this explicit statement is what Copilot retrieves and cites. Implicit or assumed information is not retrieved.

Include the effective date in the document body: "This policy is effective from March 1, 2026" — not just in the filename or metadata.

One topic per document: A single 50-page HR manual covering all policies returns poor Copilot results because any query matches the entire document. Separate into individual policy documents (leave, attendance, performance, etc.) for precise retrieval.

Copilot-Specific SharePoint Features

Restricted SharePoint Search

Admins can configure Copilot to search only specific SharePoint sites, rather than the entire tenant. For Philippine organisations with sensitive data in some sites, Restricted SharePoint Search limits Copilot's scope to approved knowledge sources only.

Admin portal: Microsoft 365 admin centre → Settings → Copilot → Manage Copilot settings → Restricted SharePoint Search

SharePoint Pages as Knowledge Articles

SharePoint Pages (not documents) are increasingly effective for knowledge base content. Pages support structured layouts, metadata, and inline media — and Copilot retrieves Page content directly.

For frequently-asked-question content, building SharePoint Pages (rather than Word documents) often produces better Copilot results because Pages are designed for structured content consumption.

Copilot Studio Integration

For organisations that want to deploy a custom AI assistant specifically trained on their SharePoint knowledge base — rather than the general M365 Copilot — Microsoft Copilot Studio allows building a custom agent with SharePoint as its knowledge source. See our Copilot Studio custom agents guide.

Implementation Sequence for Philippine Organisations

Month 1: Audit existing SharePoint — identify the top 20 most-referenced documents, verify they are in a shared library with appropriate permissions, and apply status metadata.

Month 2: Create the Knowledge hub site architecture, migrate top-priority documents, establish naming conventions and metadata columns.

Month 3: Train document owners on the governance process — how to publish, how to archive, review cycle.

Month 4+: Expand to additional document categories, measure Copilot answer quality against the baseline.

For Philippine organisations building a SharePoint knowledge base and deploying Microsoft 365 Copilot — available through Technica Solutions Inc., get in touch.

Talk to our Cloud & I.T. team →