SharePoint Online in 2026: Authoritative Sites, AI Workflows, and DocGen

TL;DR

• Authoritative sites mark your canonical source of truth — but narrowly. They are a trust signal in Copilot Search, not a global re-ranking of every Copilot answer.
• AI workflow rules and structured document generation (DocGen) are still preview features of Copilot in SharePoint, with hard limits worth knowing before you promise anything.
• Configuration is PowerShell-first. Authoritative sites have no admin-centre UI; availability is governed by Set-SPOTenant -KnowledgeAgentScope.
• Marking a site authoritative does nothing about who can read it. That is a separate — and more urgent — problem.

What changed between June and August 2026

This article first ran in June. Three things have moved since, and they matter enough to correct rather than leave standing.

The feature family was renamed. What Microsoft shipped as "AI in SharePoint" is now Copilot in SharePoint. The PowerShell parameters did not change — they still carry the preview-era KnowledgeAgent prefix, which is a small but real trap when you search for cmdlet help.

The preview flipped from opt-in to opt-out. Since mid-June 2026 it rolls out automatically to every user with a Microsoft Copilot licence. Previous opt-outs are honoured; the default tenant scope is NoSites. That default is exactly the thing to verify rather than assume.

Authoritative sites are narrower than the announcement implied. Microsoft frames them as a signal for Copilot Search, surfacing a From your organization label. That is useful. It is not the same as telling every Copilot response which of five conflicting policy documents to believe.

SharePoint's new job: feeding the AI

SharePoint Online has become one of the most strategically important workloads in Microsoft 365, because it is where Copilot finds most of its grounding content. The better organized your SharePoint, the better your AI answers.

That reframes a lot of "boring" governance work. Cleaning up duplicate sites used to be hygiene; now it is the difference between Copilot citing the current policy and Copilot confidently quoting a three-year-old draft. Start treating everything Copilot does as a consumer of your content estate rather than a separate product.

Authoritative sites: telling Copilot Search what to trust

Authoritative sites designate the canonical, organization-managed source for a topic. Users then see a From your organization label on those results in Copilot Search.

It addresses a real failure mode: in a large tenant the same fact lives in five places with subtle differences, and an assistant has no principled way to choose. What it does not do is suppress the other four copies, or guarantee a chat-style Copilot answer draws from the authoritative site. Treat it as a promotion signal, not a filter.

Configuring them: PowerShell only, for now

There is no SharePoint admin centre toggle. In the current release you configure authoritative sites through the SharePoint Online Management Shell or CSOM, per Microsoft's documentation:

Connect-SPOService -Url "https://<tenant>-admin.sharepoint.com"
Set-SPOSite -Identity "https://<tenant>.sharepoint.com/sites/HRPolicies" -IsAuthoritative $true

For bulk work, the CSOM tenant object exposes GetAuthoritativeResources(), SetResourceAsAuthoritative(), BulkSetResourceAsAuthoritative() and their removal counterparts — useful when the list is driven from a source of record rather than hand-maintained. CSOM 16.1.26914.12004 or later is required, and the PnP route needs an Entra ID app registration for interactive sign-in.

Four constraints should shape your design:

• 100 sites maximum. That is a curation budget, not a catalogue. If your instinct is to mark every intranet site authoritative, the cap will stop you — and it should.
• Up to 72 hours to propagate. Do not designate a site on Monday and demo it on Tuesday.
• Site-level only. A site holding both canonical policy and working drafts is a poor candidate.
• Personal sites are excluded, and multi-geo tenants manage authoritative data per geo, so you run the designation in each geo separately.

Does this apply to your tenant? The licensing, precisely

Authoritative sites sit inside SharePoint Advanced Management (SAM), which has an unusual entitlement rule: if your organization assigns at least one Microsoft Copilot licence to any user — who need not be a SharePoint admin — SharePoint administrators get the SAM feature set that supports Copilot deployment. In practice, one Copilot licence unlocks the governance tooling for the whole tenant.

That covers most of what a Copilot readiness programme needs: Restricted Content Discovery, restricted access control, block download policies, data access governance reports, and the site ownership, inactive-site, and attestation policies. Two carve-outs: the Sensitivity labels for files report additionally requires E5 or G5, and restricted site creation by apps needs the separate SharePoint Advanced Management Plan 1 add-on.

Copilot in SharePoint itself has a harder gate — an active Microsoft Copilot licence per user, and it is not supported in GCC, GCC High, DoD, air-gapped environments, or Microsoft 365 operated by 21Vianet. Government tenants get the SAM governance half of this article but not the authoring half. If you are still modelling licence spend, our breakdown of Business Premium vs E3 vs E5 is the right companion read.

Decide your Copilot scope before the default decides for you

Because the preview is now opt-out, the useful question is not "should we enable this?" but "where is it on right now, and did anyone choose that?" Availability is controlled with three Set-SPOTenant parameters, documented in Get started with Copilot in SharePoint. You need SharePoint Online Management Shell 16.0.26615.12013 or later; older modules fail with A parameter cannot be found that matches parameter name 'KnowledgeAgentScope', which is almost always a stale or duplicate module rather than a licensing problem.

# Where is it today?
Get-SPOTenant | Select-Object KnowledgeAgentScope, KnowledgeAgentSelectedSitesList

# Pilot pattern: on for a named set of sites only
Set-SPOTenant -KnowledgeAgentScope IncludeSelectedSites
Set-SPOTenant -KnowledgeAgentSelectedSitesList @(
    "https://yourtenant.sharepoint.com/sites/ITPilot",
    "https://yourtenant.sharepoint.com/sites/HRPolicies"
)

# Add to the list later without clobbering it
Set-SPOTenant -KnowledgeAgentSelectedSitesList @("https://yourtenant.sharepoint.com/sites/Finance") `
    -KnowledgeAgentSelectedSitesListOperation Append

Three details save you a support ticket. The selected-sites list cannot exceed 100 URLs, so it is a pilot mechanism, not a permanent segmentation strategy. The list overwrites by default — use Append or Remove for incremental changes. And multi-geo tenants must run the script in each geo.

Below the tenant, site owners get a Site AI settings panel: they choose which agent opens from the Agent icon and can hide the Copilot button from site visitors. Name that in your site-owner guidance rather than letting people discover it.

One preview-only surprise: per-user daily and weekly usage limits. When a user hits one, the features go quiet until the limit resets. If a pilot group reports that "Copilot stopped working," check this before debugging permissions.

AI workflow rules: useful, and tightly bounded

From a document library, the Copilot quick action Set up rules lets a content owner describe an outcome — "email me when a contract is approved," "move reviewed invoices to the Verified Expenses folder" — and get a configured rule back for review. Existing rules live under Automate > Rules > Manage rules.

The trade-off is the usual one: easier creation needs naming, ownership, and review conventions, or the tenant fills with half-finished automation — the same discipline that keeps Groups and Teams sprawl under control. What the documentation makes clear, and the demos do not:

• Four actions only: email, move, copy, set value. Delete and translate are unsupported.
• Three triggers: item created, modified, deleted. "Date approaches" is not yet wired up.
• 15 rules per list or library, and rules cannot target multi-line text columns.
• Prompts work in many languages, but file processing is English-only. Encrypted files cannot be analysed at all.
• Notifications cannot go to mail-enabled security groups — they come from no-reply@sharepointonline.com to named individuals, a poor fit for on-call rotations.

Scope pilots to simple routing and notification work, and keep Power Automate for anything with branching, approvals, or external systems.

Structured document generation: the two traps

DocGen turns a Word template into an AI-generated form. Copilot analyses the .docx, suggests fields, and every submission produces a governed document in a SharePoint library with the field values captured as list metadata. Each document also gets a permanent, never-reused reference number you can format with a prefix and suffix — MEA-2026-0001, for example.

The licensing split is unusually sensible: content managers who build forms need a Microsoft Copilot licence and Edit permissions on the library; people who merely submit the form need neither. That makes a legal or HR rollout far cheaper than per-seat Copilot. Two traps, though:

Conditional sections do not re-evaluate in Word for the web. Business rules mapped to template sections — country-specific clauses, optional annexes — are evaluated at generation time. Change a field value afterwards in Word for the web and the shown and hidden sections stay put. There is no reliable workaround: regenerate from the form, or open the file in Word for Windows.

Power Automate ignores conditional field visibility. Flow actions do not hide or show fields the way the interactive form does, so a field your form hides can still be required by the flow and block it. Microsoft's guidance is to make any conditionally hidden field optional when the form will also be driven from a flow.

Smaller constraints: templates must be .docx, published forms are read-only until you edit the template in Word and republish, submitters are not automatically granted access to the destination library, and PDF output does not work when sensitivity labels are enabled on the site or library — which collides with most regulated-industry configurations.

DocGen and its Power Automate companions (Form submitted, Get form metadata, Generate document from form) are all still preview as of late August 2026, with general availability signposted for later in the year. Pilot it; do not put a contract process on it yet.

Charts and dashboards: what it really is

The June version of this article described "chart creation." More accurately, Copilot in SharePoint builds interactive HTML reports and dashboards from library content, lists, and Excel or CSV files — charts included, but inside a generated report rather than a new chart web part. A dashboard built from a list stays connected to it and refreshes when opened, which is the real difference from exporting to Excel.

flowchart LR
    C[Well-organized SharePoint content] --> A[Authoritative site designation]
    A --> S[Copilot Search: 'From your organization']
    C --> G[Copilot grounding]
    R[Restricted Content Discovery] -.excludes.-> G
    P[Permissions + RAC] --> G
    G --> Q[Accurate, current AI answers]
    C --> W[AI workflow rules]
    C --> D[DocGen forms + dashboards]

The problem authoritative sites do not solve

Here is the failure mode that actually generates incidents. Marking a site authoritative promotes it; it changes nothing about who can read it. If your HR site is overshared to Everyone except external users, designating it authoritative makes the oversharing more discoverable, not less.

The counterweight is Restricted Content Discovery (RCD), which keeps a site's content out of organization-wide search and Copilot responses and removes AI entry points — the Copilot button, AI actions, Create pages with AI — from that site. Crucially, it does not change permissions: users who already have access keep it, and Purview eDiscovery and auto-labelling keep working because the content stays in the index.

# Restrict a site while its permissions are under review
Set-SPOSite -Identity "https://<tenant>.sharepoint.com/sites/Finance" -RestrictContentOrgWideSearch $true
Get-SPOSite -Identity "https://<tenant>.sharepoint.com/sites/Finance" | Select RestrictContentOrgWideSearch

# Let site admins manage it themselves (justification required, and audited)
Set-SPOTenant -DelegateRestrictedContentDiscoverabilityManagement $true

# Tenant-wide report of restricted sites
Start-SPORestrictedContentDiscoverabilityReport
Get-SPORestrictedContentDiscoverabilityReport

Two operational realities. RCD propagation is slow on large sites — Microsoft states a site with over 500,000 items can take more than a week to reflect the change. It is a review window, not an emergency brake. And because RCD also switches off Copilot on that site, over-applying it quietly degrades the AI experience you are building; Microsoft explicitly cautions against blanket use.

For a hard boundary rather than a discovery limit, Restricted Access Control (RAC) confines all access to a named security group. For file-level control, sensitivity labels with Purview DLP exclude items from agent processing — the citation still appears, but the content is not used in the response. You cannot yet label an .agent file directly; use a DLP condition on the .agent extension instead. Getting this wrong looks like Copilot serving data users should not see; the permission mechanics are in our guide to SharePoint Online permissions and governance.

What to do first

Order matters here, because doing this backwards wastes effort:

1. Audit before you enable. Run the SAM data access governance reports and the Everyone except external users insights — the only step whose value does not depend on a preview feature shipping.
2. Apply RCD to the sites that fail the audit, as a review window. Start early; propagation on large sites is measured in days to weeks.
3. Check your scope deliberately. Run Get-SPOTenant | Select-Object KnowledgeAgentScope and decide, rather than inherit, where the preview is live.
4. Designate authoritative sites sparingly. Pick the ten to twenty topics your help desk is actually asked about, confirm those sites are clean and correctly permissioned, then mark them. Budget 72 hours before evaluating.
5. Pilot workflow rules on one library with an owner who will maintain them, inside the 15-rule ceiling.
6. Prototype DocGen on one low-stakes document type — an internal letter, not a customer contract — and test the Word for the web and Power Automate behaviours first.
7. Write site-owner guidance last, once you know which controls you are delegating. Automate the recurring checks with the Graph PowerShell SDK so step one becomes a schedule, not a project.

Running a broader Copilot programme? This slots into the readiness workstream in our Copilot rollout guide.

The bottom line

SharePoint in 2026 is the grounding layer for everything Copilot does, and Microsoft's updates are about making that grounding trustworthy — but most of the headline features are still preview, PowerShell-configured, and narrower than the announcements suggest.

What pays off regardless of what ships next is unchanged: know who can read what, name your canonical sources deliberately, and keep the promoted set small enough that the designation still means something. Good SharePoint governance is now good AI governance — and unlike the preview features, it is available in your tenant today.

Further reading

• SharePoint Authoritative Sites in Copilot Search (Microsoft Learn)
• Get started with Copilot in SharePoint, preview (Microsoft Learn)
• Generate structured documents in a SharePoint document library (Microsoft Learn)
• Restrict discovery of SharePoint sites and content (Microsoft Learn)
• SharePoint Advanced Management features in Microsoft Copilot licenses (Microsoft Learn)
• What Are the Latest Features in SharePoint 2025/2026 (Microsoft Learn Q&A)
• Microsoft roadmap roundup — 01 June 2026 (SharePoint Stuff)

Image credit: Shixart1985 via Wikimedia Commons (CC BY 2.0).