Microsoft Foundry: SharePoint Knowledge Integration - The Easy Way and The Hard Way

Introduction

Microsoft Foundry seems to have new features and possibilities every time I launch it; the latest example is a complete overhaul of the experience with a rename from “Azure AI Foundry” coming out of Ignite 2025. This platform has become the preferred sherpa to guide me in my ascent up AI mountain. I built my career’s base camp out of .NET, Azure, and SharePoint; gazing up the Python trail snaking its way to the summit, I found myself more unwilling than most to give up my curly braces and semicolons to get there.

This blog series will present two options for how to send your Foundry AI agents to SharePoint college for some document knowledge. The “Easy Way” is for organizations that have M365 Copilot licensing which allows them to leverage an out of the box Foundry connection. But in case your team is more invested in the M365 Power Platform and doesn’t mind some C# and Azure stops along the “Hard Way,” there is a more convoluted path to the summit…but the view is just as magnificent.

Series Overview

In order for my fellow mountaineers (.NET developers, architects, and AI engineers from all corners of the Microsoft tech stack [specifically Azure, M365, Power Platform, and .NET]) to get the most out of this for their coding pleasure and be able to make their own way up the mountain, this series will be divided up as follows:

1. Tradeoffs Between the Two Approaches
2. SharePoint Knowledge Connections to Foundry Agentsthe Easy Way
3. SharePoint Knowledge Connections to Foundry Agentsthe Hard Way

         a. Deep Dive: Extracting SharePoint Content withPower Automate

          b. Deep Dive: A Custom API To Sync SharePointContent with Azure Storage

         c. Deep Dive: Deploying Azure AI Search with C#

      4. Azure AI Search Knowledge Connections to FoundryAgents

Tradeoffs Between the Two Approaches

This first post in the series will introduce these two options and discuss their pros and cons. Based on your organization’s licensing options, your team’s expertise, your IT department’s existing investments in Microsoft technologies, and your administrator’s M365 deployments, this should help determine the best way up the mountain.

Let’s climb!

The Easy Way

This is the out of the box approach, where we configure a connection to SharePoint directly in Foundry. The huge upside is that there is no custom code required; it “just works” and is the preferred way to ground Foundry agents in your organization’s site collections (and not just intranets and team sites, but any SharePoint-backed repository like Teams channels or OneDrive folders). You can point your agent to a site, document library, or even a specific folder therein to curate the proper context for your chat completions. However, there are some limitations:

• As previously mentioned, your account needs to be imbued with an M365 Copilot license, since SharePoint doesn’t swim in the vectorization pool.
• This only supports modern site collections under the /teams managed path, which is a tenant-wide setting that might not be easily adoptable. The screenshot below shows how to configure this in the M365 SharePoint Admin Center, accessible from https://<tenant>-admin.sharepoint.com:

The Hard Way

If either of the two limitations above are a deal breaker for your organization, there is another way to make SharePoint AI-consumable! Foundry agents can also be grounded in an Azure AI Search index, so this approach builds up to that:

1. Hook two Power Automate flows up to a document library (one for uploads or edits and one for deletions)
2. The flows collect and send the metadata for these file changes to a custom API
3. The code behind the API’s ingestion endpoint downloads the file, decorates it with metadata, and uploads it to an Azure Storage blob container (or deletes it for the second flow)
4. Azure AI Search is configured with a blob data source against this container, and an indexer uses a connection to Foundry to chunk and vectorize the content
5. Foundry agents are then given Azure AI Search knowledge

We’ll get into all the technical details in the deep dives listed above. But first, here are the limitations of this custom approach:

• While the out of the box SharePoint knowledge can be as broad as a site collection or as narrow as a folder, this approach is meant to target the document library level. Additional customizations can support specific folders, but going up to the site collection level requires attaching flows to all libraries, which while being technically viable, becomes challenging from a governance perspective. At the end of the day, however, this is a fully custom approach, so the tools are there to do the job…
• …and being a custom solution, it requires much more effort than “The Easy Way.”
• There is inherent latency with this architecture. Flows triggered by SharePoint document library actions could take up to thirty seconds to fire and execute, and Azure AI Search indexers can only run as often as once every five minutes. Therefore, accounting for the code execution in the middle, it could conservatively take up to six minutes for SharePoint changes to be reflected in Foundry.

How Do I Climb?

The following considerations should help you decide which approach is the best SharePoint journey up the AI mountain for your organization:

• If you have M365 Copilot licenses for all target users, go with the Easy Way.
• If you cannot pivot to modern SharePoint site collections, you’ll need the Hard Way.
• If you have talent around Azure AI Search customizations, the Hard Way is compelling because there is A TON that you can do with this beyond Foundry integration. In other words, this approach gives you searchable, vectorized SharePoint content as a service available to your organization.
• If you have reservations about a dependency on Power Automate as a key architectural component, consider the Easy Way.
• If you don’t have the capability to deploy a custom C# web API to Azure, then the Easy Way is your best option.
• As of November 2025, SharePoint knowledge is in preview in the “old” Azure AI Foundry experience, but not in the “new” Microsoft Foundry flavor announced at Ignite. However, this “new” platform is itself in preview. Either way, Azure AI Search knowledge is fully live. If there is trepidation around beta tech, the Hard Way is currently your best bet.

A Note on Security

I do want to mention one aspect of this integration – common to both approaches – is that SharePoint security is not discussed. We are still assessing to what extent this should lend itself to agent knowledge from a philosophical perspective. In other words, in a site collection with a complex security model having custom roles, broken inheritance, and/or item-level permissions, it’s possible that the agent would “know more” than the current user.

We have some ideas on how to evaluate SharePoint security as a pre-processing step before the agent responds as a Foundry custom tool. There is also a “just in time” post-processing approach where we ensure the documents used by the agent are filtered against the current user’s access.

Regardless, this series will follow the paradigm of an agent knowing everything about a SharePoint context with the assumption that users chatting with it are privy to that corresponding information. If you’re using SharePoint as an organization-wide knowledge base, wiki, or some other broader intranet environment, this should be a safe assumption.

However, if site collections have confidential HR data, extranet client information, or other sensitive content, additional consideration should be made before unleashing agents against it to any extent. Since SharePoint’s CMS and Foundry’s agents are so extensible, we have a lot of approaches on the whiteboard to provide the “2.0” version of this integration with options around how to ensure that your data is only consumed by those with proper access to it.