In the last article, I covered the five dimensions of organisational readiness and why the foundation underneath your AI solution matters as much as the solution itself.

This article is for the practitioners who now have to build that foundation.

The first half covers the concept what good knowledge architecture looks like and why each platform behaves differently. The second half covers implementation — how to actually configure SharePoint grounding libraries, Dataverse search, Copilot Studio knowledge sources, sensitivity labels, and permissions before an agent goes live.

If you are here to implement – skip to Part Two.

This is the second part of Stage 3 – Validate Readiness.

Part One : The Concept

The principle that applies to both platforms

Regardless of whether you are building with Microsoft 365 Copilot or Copilot Studio, one principle holds:

Your agent retrieves what your knowledge architecture allows. No agent configuration compensates for a poorly designed foundation.

Both platforms use AI to reason over content. Both will retrieve and synthesise confidently from poor quality, outdated, or inappropriately scoped content if that is what is available.

What each platform does differently

Microsoft 365 Copilot retrieves through Microsoft Graph as the signed-in user. It searches semantically across everything inside the Graph boundary – SharePoint, OneDrive, Teams, Exchange, Loop. Content outside that boundary requires explicit connector configuration. M365 Copilot readiness is largely about governing what already exists in your tenant.

Copilot Studio custom agents do not retrieve across Graph by default. Knowledge sources are explicitly configured at build time – SharePoint libraries, Dataverse tables, uploaded documents, public websites, Azure AI Search, or external connectors. The scope is deliberate, not inherited. Copilot Studio readiness is about designing what the agent is deliberately given access to.

This distinction drives everything that follows.

The shared failure modes

Both platforms fail the same ways when the knowledge layer is poorly designed: outdated documents retrieved confidently, duplicate sources with conflicting answers, content in formats that degrade retrieval quality, sensitive material surfaced to users who should never see it summarised and presented directly.

The fix is the same regardless of platform: treat your knowledge layer as a designed system – not an inherited state.

Dataverse versus SharePoint -the decision

This is not a preference – it is a design boundary.

Use SharePoint when the content is unstructured and authored by people: policy documents, guides, reference materials, FAQs. The value is human readability and document management.

Use Dataverse when the content is structured and generated by processes: intake records, request logs, approval histories, operational data. The value is schema enforcement, relational integrity, and reliable API access.

The failure mode is using SharePoint lists for structured data because it feels convenient. SharePoint lists lack the referential integrity, security model, and API surface that enterprise integrations require. A leave request created as a SharePoint list item cannot be reliably consumed by Dynamics 365, audited properly, or integrated with downstream payroll systems. The same request as a Dataverse record can do all three.

Design SharePoint as your knowledge layer. Design Dataverse as your record layer. Never cross them.

Part Two : Implementation

Order of operations – do this before anything else

The most common reason agent knowledge configurations fail is sequencing. Teams configure the agent before the knowledge layer is ready, then spend weeks debugging retrieval problems that would not have existed if the foundation had been built first.

Do these steps in this order:

1. Design and build the grounding library Structure, naming conventions, metadata columns, file format migration. The library needs to be ready before the agent touches it.

2. Configure SharePoint search schema Managed properties set to Searchable and Queryable. Do this before indexing happens – retroactive schema changes require reindexing which takes time.

3. Run sensitivity label audit and apply auto-labeling Identify label-protected files before configuring knowledge sources. In Copilot Studio these files are silently excluded – you will not know they are missing unless you check first.

4. Enable Dataverse search and configure searchable columns Do this before adding Dataverse as a knowledge source in Copilot Studio. Adding the knowledge source before columns are configured requires re-adding it after and backfilling the index takes up to two days.

5. Audit and tighten permissions Run sharing reports before deployment. Overly broad permissions are easier to tighten before users start interacting with an agent than after retrieval incidents surface.

6. Configure knowledge sources in Copilot Studio / M365 Copilot Only now. With the foundation in place, knowledge source configuration is reliable. Without it, you are debugging retrieval problems caused by issues that predate the agent.

7. Write and validate knowledge source descriptions Write descriptions before publishing. Test them by asking queries that should select each source and confirming the right source is selected.

8. Run retrieval tests across every document type Before publishing to users, test a representative query against each knowledge source. Confirm what the agent can and cannot reach. Document the results.

What good looks like versus what most teams actually have

Most teams do not start from scratch. They inherit a SharePoint environment that was never designed for agent retrieval. Here is the honest comparison:

If your current state matches the left column which it usually does – the question is not whether to fix it. It is how much to fix before the agent goes live versus what can be addressed in parallel.

The minimum viable foundation before deployment: dedicated library scope, stale content archived, consistent naming, item-level labels on sensitive content, permissions audited.

Everything else improves retrieval quality but will not cause the agent to fail outright.

Designing a SharePoint grounding library

Library structure

Create a dedicated grounding library rather than pointing an agent at a broad SharePoint site:

/HR-Agent-Knowledge
  /Policies     ← current approved policy documents only
  /Guides       ← how-to guides and process documentation
  /FAQs         ← structured Q&A documents
  /Archive      ← outdated versions, excluded from agent scope

Exclude the Archive folder from the agent’s knowledge source configuration. Outdated documents left accessible will compete with current content – the agent retrieves based on relevance, not recency.

Naming conventions

[Topic] [Document Type] [Year].docx
Parental Leave Policy 2025.docx
IT Access Request Guide 2025.docx
Expense Reimbursement FAQ 2025.docx

Metadata columns

Add these managed metadata columns to your grounding library:

• Document Type : Policy, Guide, FAQ, Process, Reference
• Business Domain : HR, IT, Finance, Legal, Operations
• Valid From / Valid To : enables date-based governance
• Status : Active, Under Review, Archived

These become filterable signals for retrieval precision. In Copilot Studio, use KQL query parameters to restrict retrieval to Status = Active preventing the agent from surfacing Under Review or Archived content without restructuring the library.

Supported file formats

Semantic retrieval is fully supported for .doc, .docx, .pptx, .pdf, .aspx, and .one. Everything else falls back to lexical search. Migrate critical content out of .xlsx and .csv before grounding the agent.

SharePoint search schema

In SharePoint admin centre → Search → Manage Search Schema: ensure managed properties for Document Type, Business Domain, and Status are set to Searchable and Queryable. Do this before the library is indexed – retroactive changes require reindexing.

When to use synced vs federated connectors : the decision

For content outside the Graph boundary, the choice between connector types is not arbitrary:

Use a synced connector when semantic retrieval quality matters more than real-time accuracy. Content is ingested into Graph, semantically indexed, and available to Copilot with the same retrieval quality as native SharePoint content. Right for: knowledge bases, policy repositories, static reference content in external systems like ServiceNow or Confluence.

Use a federated connector when real-time accuracy matters more than semantic richness. Content is queried live from the source system without being stored in Graph. No semantic indexing benefit. Right for: live inventory data, real-time case status, current pricing – anything where a one-hour-old indexed version is worse than a live query.

If you are unsure: start with synced. The semantic retrieval quality difference is significant for knowledge-heavy use cases. Federated connectors are the right call when the data changes faster than the indexing cycle can keep up with.

Configuring Dataverse search for knowledge sources

Enable Dataverse search at the environment level before adding Dataverse as a knowledge source – Power Platform admin centre → Settings → Features → Search → Dataverse Search → On. Confirm this in both development and production environments.

Configure searchable columns before adding the knowledge source

This is the step that catches most teams. In Power Apps maker portal, open the table → Columns → set Searchable to Yes for each relevant column. Update the Quick Find View to include those columns. Then add the Dataverse knowledge source in Copilot Studio.

If you add the knowledge source before configuring columns, the index will not include those columns. Re-adding the source after fixing the columns triggers a backfill that takes up to two days. Do it in the right order.

Synonyms and glossaries

Define synonyms for every non-obvious column name. A column named cr_abc_123 containing job role codes needs a synonym mapping to “job role” and “job title” before the agent can respond reliably to natural language queries about staffing. Add these at the knowledge source configuration level in Copilot Studio after adding the table.

User authentication vs agent author authentication : the decision

This is the most consequential governance decision in a Copilot Studio deployment and the one most often made by default rather than deliberately.

User authentication – the agent retrieves as the signed-in user. Only content that user personally has permission to access is surfaced. Right for: any agent handling personal data, sensitive HR content, or scenarios where different users should see different content.

Agent author authentication – the agent retrieves using its own credentials. Any authenticated user of the agent can receive content from that source regardless of their personal permissions. Right for: low-risk reference data, public-facing content, scenarios where all users legitimately need the same access regardless of their individual permissions.

The failure mode: agent author authentication applied by default to a Dataverse source containing supplier contracts or performance data. Every user of the agent regardless of role or seniority can now receive that content in a Copilot-synthesised response. The access was never intentional. It was just the default.

Document the decision for every knowledge source before deployment:

Every agent author authentication row requires explicit sign-off. Not a rubber stamp, a deliberate decision that the broader access is intentional and acceptable.

Sensitivity label implementation

The governance trap: labelling a SharePoint site as Confidential does not protect documents inside it. Item-level labels are required.

Run a content audit against your grounding library before configuring it as a knowledge source. Identify every label-protected or password-protected file – these cannot be indexed by Copilot Studio and will be silently excluded from retrieval. No error. No indication. The file simply will not appear in agent responses.

For existing content: configure Purview auto-labeling policies scoped to your specific grounding library site URLs. Run in simulation mode first. Target 80% coverage before deployment.

For Copilot Studio specifically: any label-protected file the agent needs to retrieve must be restructured – either replace the label with a permission-based control, or replicate the content into an unprotected format in a scoped library.

What will still catch you out in production

Stale content resurfaces. Grounding libraries are clean in test. In production, historical documents from before your governance effort exist across the broader SharePoint estate and get retrieved unexpectedly. Scope to libraries not sites. Archive before deployment not after.

Authentication fails after initial consent. In Teams deployments token expiry causes re-authentication prompts mid-conversation. Configure SSO via Teams channel authentication properly before production – test environment authentication behaviour does not replicate automatically.

Label-protected files silently excluded. Documents you expect the agent to retrieve are not surfaced. No error. Run a post-deployment retrieval test for every document type to confirm what the agent can and cannot reach.

Dataverse column not searchable. Agent cannot answer questions from a Dataverse knowledge source. Root cause: columns not set to Searchable before the knowledge source was added. Backfill after fixing takes up to two days. Configure columns first.

Description too generic causes wrong source selection. Agent selects HR knowledge source to answer an IT question. Rewrite descriptions to be explicitly exclusionary – state what each source should not be used for, not just what it contains.

Permissions tightened after go-live causes retrieval failure. A permission audit run after deployment removes broad access that the agent was relying on. Users start receiving incomplete responses. Run the permission audit before deployment and test retrieval after any permission change.

Pre-build checklist

SharePoint grounding library:

• Dedicated library created, not a broad site scope
• Archive folder excluded from agent knowledge source scope
• Consistent naming convention applied
• Metadata columns added – Document Type, Business Domain, Status, Valid From
• All content in supported file formats
• Search schema reviewed – key managed properties Searchable and Queryable
• SharePoint search schema configured before indexing

Dataverse knowledge sources:

• Dataverse search enabled in both dev and production environments
• Searchable columns configured before knowledge source added in Copilot Studio
• Quick Find View updated
• Synonyms and glossary terms defined for non-obvious column names

Copilot Studio knowledge source configuration:

• Descriptions written using template – specific, exclusionary, owner noted
• Synced vs federated connector decision documented for out-of-boundary sources
• Authentication model documented and signed off for every source
• Label-protected files identified and restructured or excluded
• Post-configuration retrieval test run before publishing

M365 Copilot:

• Graph boundary mapped – key knowledge sources confirmed reachable
• Sharing report run – broad permissions reviewed and tightened before deployment
• Item-level sensitivity labels in place
• DLP policies configured for the Microsoft 365 Copilot location
• Guest user access reviewed

What comes next

Knowledge foundations are now designed and configured.

The next article covers the final dimension of Stage 3 readiness: environment strategy and governance foundations – Power Platform environment design, DLP policy architecture, and tenant-level controls that determine how safely and scalably you can deploy.

A useful question to leave with:

If you mapped your current SharePoint environment against the “what good looks like” column how many rows would you be in the right column today?