![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 26%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFS%3C/text%3E%3C/svg%3E)
Azure AI Search
An Azure search service with built-in artificial intelligence capabilities that enrich information to help identify and explore relevant content at scale.
Hello @Fredrik Skau
The documented syntax supports multiple includeFolder clauses. The folders are separated by semicolons, and the includeFolder parameter is repeated:
"container": {
"name": "useQuery",
"query": "includeFolder=https://contoso.sharepoint.com/sites/project/Shared Documents/FolderA;includeFolder=https://contoso.sharepoint.com/sites/project/Shared Documents/FolderB"
}
Each value must be a complete SharePoint folder URL, and all included folders must belong to the same document library. Root-only paths are unsupported.
Because one includeFolder works while adding a second reproducibly returns HTTP 500, first verify that:
- Both URLs reference folders in the same document library.
- Neither value is the document-library root.
- The query repeats includeFolder= for each folder.
- Entries are separated with a semicolon.
- The application has at least read access to both locations. If Sites.Selected is used, the application must receive an explicit permission grant on every applicable SharePoint site; Entra admin consent alone does not provide site access.
If those requirements are satisfied, the request format is documented as supported. I cannot find an official Microsoft limitation stating that an indexed SharePoint knowledge source accepts only one includeFolder. The HTTP 500 response therefore appears inconsistent with the documented behavior, but only Microsoft can confirm whether this is a defect in the preview knowledge-source creation path.
The indexed SharePoint knowledge source is itself a preview feature. It automatically creates a SharePoint data source, skillset, index, and indexer, and it inherits the SharePoint indexer’s prerequisites and limitations. Preview functionality is not covered by a service-level agreement and can change before general availability.
Possible supported workarounds are:
- Create one indexed SharePoint knowledge source for each folder and reference both from the same knowledge base. Azure AI Search knowledge bases can contain one or more knowledge sources.
- If the required selection can be represented that way, use includeLibrary with one or more excludeFolder clauses. Both filters are documented for the SharePoint indexer.
- Create the SharePoint data source and indexer directly, then expose the resulting index through a Search Index knowledge source. Microsoft supports using an existing compliant index as an agentic knowledge source.
For escalation, include the complete sanitized request body, API version, response body, HTTP response headers and request ID, UTC timestamp, search-service resource ID, and results showing that each folder works independently but fails when combined.
References:
- SharePoint indexer: control which documents are indexed
- SharePoint indexer permissions
- Create an indexed SharePoint knowledge source
- Introduction to Azure AI Search
- Create a Search Index knowledge source
Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.