Microsoft has added a long-awaited capability to its Copilot Agent Builder: makers can now ground AI agents in SharePoint list data. The feature, listed as launched on the Microsoft 365 Roadmap under ID 561920, reached general availability in June 2026 for worldwide standard multi-tenant tenants. It lets agents answer questions from structured business records—think policy registers, equipment inventories, project risks, and service catalogs—rather than only pulling from documents or sites. But the initial release comes with guardrails that will shape how organizations adopt it.

What Actually Changed

Agent Builder, the low-code tool for creating custom Copilot agents inside Microsoft 365, now offers SharePoint lists as a selectable knowledge source. Previously, makers could ground an agent in SharePoint sites, specific document libraries, or Microsoft Graph connectors. With the June update, a single SharePoint list can be added to an agent’s grounding repertoire, and the agent will use that structured data to generate responses.

The feature is available on desktop and web, and it’s already live for tenants that receive standard multi-tenant updates. According to Microsoft’s roadmap, no special configuration is required beyond the typical permissions to create agents. Makers simply pick the list while building an agent in the Agent Builder interface.

Two immediate boundaries stand out. First, an agent may reference only one SharePoint list—not multiple lists, not a list plus a secondary list for relational data. Second, that list can hold at most 20,000 items. If your list exceeds that threshold, the agent won’t be able to use it as a grounded source. These limits are deliberate: Microsoft is rolling out list support incrementally to ensure reliability and performance, but they will constrain scenarios that rely on a web of interconnected lists or master-detail patterns.

Additionally, the roadmap entry calls out specific gaps for list designers. List attachments are not supported—so files uploaded to list items (PDFs, images, etc.) won’t be indexed or used by the agent. Lookup columns are also off the table; data linked through SharePoint lookup relationships won’t be pulled into the agent’s answers. Makers who’ve built lists heavily dependent on these features will need to rethink their data model if they want an agent to provide complete answers.

What This Means for You

The impact breaks down sharply by role.

For Makers and Power Users

If you’ve been itching to build a copilot that answers “What’s the serial number of the audiovisual cart in Conference Room B?” or “Which vendors are pre-approved for compliance in the EMEA region?”, this is your moment. SharePoint lists have long stored exactly that kind of operational data, and now you can expose it through a natural-language interface.

But the single-list and 20,000-item limits mean you must choose your target list carefully. An agent designed to support a field team, for example, might need to pull from separate lists for equipment, locations, and contacts—but you can’t combine those today. Instead, you’ll need to either build a dedicated, flattened list that contains all relevant columns, or accept that the agent will only cover one slice of the scenario.

For IT Administrators

Permissions remain the backbone of any SharePoint-grounded agent. Microsoft’s documentation is explicit: an agent answers from sources only if the asking user already has access to that data. Adding a list to an agent does not grant new permissions. So before rolling out an agent, verify that your existing SharePoint permissions are tight. A list containing sensitive information—employee performance ratings, unreleased financial data—must be properly locked down; otherwise, any user who can open the agent could ask the right questions and retrieve it.

You’ll also need to audit list design. Look at which columns contain the answerable data. If critical information lives in lookup columns or as an attachment, the agent won’t see it. That could lead to frustration when the agent confidently gives a wrong or incomplete answer. Test thoroughly with representative user accounts and a suite of real-world prompts before you publish the agent broadly.

For Everyday Users

On the user side, the experience should feel seamless. You ask a copilot a question about a business process, and it returns an answer sourced from a list—no different than when it grounds itself in a document. The catch is that the quality of answers hinges on how well the list is structured. If the list’s column names are cryptic or the data is messy, you’ll get cryptic or messy responses. And if you need information that spans multiple lists, you may have to piece answers together from different agents or sources. In other words, the agent is only as smart as the list behind it.

How We Got Here

Agent Builder arrived in late 2025 as part of Microsoft’s push to let organizations create domain-specific AI assistants. It started with the ability to ground agents in SharePoint sites and documents, later adding Microsoft Graph connectors for third-party data. SharePoint lists were a frequent request from customers who have years of business data stored in list form—IT asset registers, HR onboarding checklists, project dashboards, and more. While Microsoft’s existing tools like Power Virtual Agents could tap into SharePoint, this is the first native integration for Copilot agents without additional connectors.

The roadmap entry first appeared in the spring of 2026, promising “SharePoint list support for Agent Builder” with a June 2026 target. That timeline has hit on schedule, suggesting the feature was relatively well-scoped. The limitations—one list, 20,000 items, no attachments or lookups—are consistent with an initial release designed to validate the approach before scaling up. Microsoft rarely launches complex integrations without such guardrails; the same pattern played out with earlier Copilot grounding sources.

SharePoint lists as a knowledge source represent a subtle but important shift in how Microsoft views structured data inside Copilot. Unlike a Word document or a PDF, a list has schema: columns with types, validation rules, and sometimes relationships. By allowing agents to consume that schema, Microsoft is betting that a significant amount of enterprise knowledge doesn’t live in prose—it lives in rows and columns. The move also strengthens SharePoint’s relevance as a data storage layer in an AI-first world, something that many predicted would fade in favor of Dataverse or other platforms.

What to Do Now

If you have a suitable SharePoint list and want to start testing, here’s a practical checklist:

  1. Choose the right list. Find one with fewer than 20,000 items and columns that directly contain the answers users will seek. Avoid lists where critical data is hidden in attachments or lookup columns.
  2. Flatten if necessary. If your data is normalized across multiple lists, consider creating a single list that brings together the key fields using Power Automate or a calculated import. Long-term, multi-list support may arrive, but for now, a consolidated list is your best bet.
  3. Audit permissions. Map out who should have access to the list. Tighten permissions before giving the agent to a broader audience. Use SharePoint’s permission-checking tools to validate that only intended users can read sensitive content.
  4. Test with representative prompts. Create an agent in a development or pilot environment. Have a test user—with the same permission level as your target audience—ask questions that mirror real-world inquiries. Compare the agent’s answers against the actual list data. Watch for missed items caused by unsupported column types.
  5. Prepare users for limitations. When you roll out the agent, set expectations. Let users know the agent draws from a specific list and won’t include data from attachments, related lists, or lookup fields. A simple note in the agent’s description can prevent dozens of help-desk tickets.
  6. Monitor feedback and iterate. Use the Copilot feedback mechanisms to gather insights on answer quality. Adjust the list’s columns, descriptions, and data cleanliness based on what users are actually asking.

For admins, the rollout is low-risk because the feature is already on by default. No need to enable anything; eligible users will see the SharePoint list option when they create or edit an agent in Agent Builder. However, if you’re in a regulated industry or handle highly sensitive data, you might want to limit which users can create agents at all—a setting controllable through Copilot administration policies.

Outlook

Microsoft rarely stops at a first iteration. Expect the list support to grow in two directions: capacity and complexity. The 20,000-item limit may rise, and multi-list support could follow once the team gathers telemetry on how agents consume structured data at scale. Lookup column and attachment support are plausible roadmap candidates, though they carry significant architectural challenges—attachments, for example, would require the agent to handle hybrid retrieval (list items plus files), which is a different beast.

Beyond SharePoint, this release signals a broader ambition. As more knowledge sources become available—lists, datasets, perhaps even SQL views via Graph connectors—the Copilot ecosystem edges closer to a unified query layer across Microsoft 365. The play for IT leaders is clear: start organizing your operational data in clean, single-source lists now, and you’ll be ready when the agents get smarter.