SharePoint lists in Foundry IQ after On Your Data retired

23 October 2026

Tags: Search and vector storesAIDesktopCommand line

The IT service desk built its “ask the known issues list” chat in 2025. A nightly script exported the SharePoint list of known issues to text files in Blob Storage, an indexer chunked them into Azure AI Search, and Azure OpenAI On Your Data answered questions with citations. It worked well enough that people stopped searching the list by hand. Then in October the platform team flagged the app on the retirement list, and the questions started: what replaces it, do we have to rebuild the index, and why is the overnight export still the only way SharePoint gets in?

This post answers those three in order, with the facts as Microsoft Learn stated them on 23 October 2026. The short version: the index survives, the app changes, and the export script is the part worth replacing.

What happened to Azure OpenAI On Your Data?

It retired. Microsoft Learn’s On Your Data page, now kept for historical reference, says Azure OpenAI On Your Data retired on 14 October 2026 and is no longer supported by Microsoft. Requests that carry data_sources or call the /extensions/chat/completions path are the ones affected. Ordinary chat completions without that configuration are not part of the retirement.

For an app backed by Azure AI Search, Learn points to Migrate Azure OpenAI On Your Data to Foundry IQ, a Microsoft notebook that keeps your index and changes the application around it. Three details from the notice shape the plan. Migration is not automatic. Connector behaviour, access control lists and embeddings do not convert on their own. And the sample’s answer synthesis uses the 2026-08-01-preview API. The route Learn offers on the stable 2026-04-01 API, with no preview label, is minimal, extractive retrieval with your app writing the answer.

Foundry IQ itself is mixed. Learn’s What is Foundry IQ? page says some of its features have left preview and others remain in it, depending on the Search REST API version you call. Our post on Azure AI Foundry agents and SharePoint list rows sets Foundry IQ beside the other Foundry tools, so this one stays with the index.

Where the SharePoint list fitted in before

It never fitted directly. The historical list of supported sources on the same Learn page names Azure AI Search, Azure Cosmos DB for MongoDB vCore, Blob Storage, uploaded files, web addresses, Elasticsearch and MongoDB Atlas. SharePoint is not on it. Learn also advised that structured data be converted to text for best results, which is how the service desk ended up with a script that wrote one text file per list item.

That script carries most of the risk in the old design. It reads the whole list every night, so the index is up to a day behind. A deleted known issue stays in Blob Storage until someone notices. A lookup to the Product list arrives as an id unless the script resolves it, and the script fails without an error the day someone renames a column. None of that changes when the app moves to Foundry IQ, because Foundry IQ reads whatever index you give it.

Three Foundry IQ routes to a SharePoint list

Foundry IQ has three, and two of them are in preview. Learn’s knowledge source overview marks the indexed SharePoint and remote SharePoint knowledge sources as preview. The indexed source runs Microsoft’s SharePoint indexer, whose list support is itself in preview, as our Azure AI Search destination page describes with its prerequisites and limits. The remote source queries SharePoint at request time and keeps no index.

The third way is the search index knowledge source, which wraps an index you already have and carries no preview label. That is the route Microsoft’s migration notebook uses, and it is where SPSync fits: SPSync keeps the index current from the list, and Foundry IQ reads it. The preview SharePoint sources are worth testing if you need SharePoint permissions enforced at query time, which a replicated index does not give you.

Feeding the index from the list with SPSync

SPSync replicates SharePoint lists one way into Azure AI Search, so SharePoint stays the system of record and SPSync never writes back to it. It reads the list through Microsoft Graph, resolves lookups, and writes one document per list item into an index named after the list and the replication’s table prefix. With prefix: servicedesk, the Known Issues list becomes the servicedesk-known-issues index. Later runs read only what changed, and a document is removed from the index on the run after its item is deleted.

In the desktop app, connect the service desk site, tick the Known Issues list and the Products list it looks up to, and pick Azure AI Search. From the command line, the table prefix is the top-level prefix key of the replication config, and the destination block sits beside it:

prefix: servicedesk          # index names start with this
destination:
  kind: azure-ai-search
  connection_string_env: SPSYNC_AAIS_STATE_PATH   # local state file path
  dataset_name: main          # dataset in the local state, not the index name
  azure_ai_search_endpoint: https://contoso-search.search.windows.net
  azure_ai_search_api_key_env: SEARCH_ADMIN_KEY
  azure_ai_search_embedding_provider: azure-openai
  azure_ai_search_embedding_model: kb-embed        # your deployment name
  azure_ai_search_embedding_dimensions: 1536
  azure_ai_search_embedding_columns: [title, symptoms, workaround]
  azure_ai_search_embedding_api_key_env: AOAI_API_KEY
  azure_ai_search_embedding_azure_endpoint_env: AOAI_ENDPOINT

SPSync needs an admin key, because creating and updating indexes needs one, and a local state file path it keeps between runs. With the embedding settings present it adds an sp_embedding vector field and fills it during the sync, one vector per item built from the columns you list, and it re-embeds an item only when that text changes. SPSync does not split long text into chunks, so this suits lists whose text columns hold a paragraph or two, which most known issues lists do.

The Product lookup arrives as a key field and a searchable display name, so a filter on product and a search on its name both work. Titles and single-line text are searchable, filterable and facetable, multi-line text is searchable, and every item document carries sp_item_id and sp_modified for citations and freshness. The search index design resource covers the field layout in more detail.

What does Foundry IQ need from an SPSync index?

Learn’s criteria for agentic retrieval lists what an existing index needs before a knowledge source can wrap it. Here is each requirement against what SPSync creates:

The semantic configuration needs care with API versions. Learn’s search index knowledge source page says that from the 2026-05-01-preview API a knowledge source no longer needs one, but earlier versions, including the stable 2026-04-01, still do. Microsoft’s migration notebook calls it optional in the preview. Add one anyway, so both API versions work.

The vectorizer matters more than it looks. SPSync stores a vector for every document, but Foundry IQ sends text, and the migration notebook says vector retrieval “needs a valid query-time vectorizer, not just stored vectors”. Without one, the knowledge base searches the text fields only. Learn’s vectorizer page adds that the vectorizer must use the same embedding model as the stored vectors.

That decides which SPSync embedding provider to pick. With azure-openai and an Azure OpenAI embedding model the vectorizer supports, the vectorizer can call the same deployment SPSync used. With SPSync’s openai or local providers, the only matching vectorizer is a Custom Web API one in front of the same model, which you would host yourself. Keep SPSync’s dimensions at the model’s own output size; Learn warns that a dimension mismatch between the vectorizer and the field breaks queries.

We have read all of this on Learn and checked SPSync’s code against it, but we have not run a Foundry IQ knowledge base against an SPSync index ourselves. Test it on your own service before you cut over. Learn’s agentic retrieval overview also says agentic retrieval runs in select regions only, so check yours first.

Wrapping the index in a knowledge base, step by step

After the first sync, open the servicedesk-known-issues index in the Azure portal’s index designer. Add a semantic configuration, which Learn says needs no rebuild, with title as the title field and the multi-line text fields as content:

"semantic": {
  "defaultConfiguration": "known-issues",
  "configurations": [{
    "name": "known-issues",
    "prioritizedFields": {
      "titleField": { "fieldName": "title" },
      "prioritizedContentFields": [
        { "fieldName": "symptoms" }, { "fieldName": "workaround" }
      ],
      "prioritizedKeywordsFields": [{ "fieldName": "product_value" }]
    }
  }]
}

Then add an Azure OpenAI vectorizer under vectorSearch.vectorizers pointing at the kb-embed deployment, and set "vectorizer" on the spsync-hnsw profile SPSync created, which is the profile the sp_embedding field already uses. SPSync only ever adds fields to an existing index and sends every other section back as the service holds it, so both changes survive later runs.

Next, create the knowledge source on the same search service. On the stable 2026-04-01 API it must name the semantic configuration:

PUT https://contoso-search.search.windows.net/knowledgesources/known-issues-ks?api-version=2026-04-01
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "known-issues-ks",
  "kind": "searchIndex",
  "description": "Service desk known issues, replicated from SharePoint by SPSync",
  "searchIndexParameters": {
    "searchIndexName": "servicedesk-known-issues",
    "semanticConfigurationName": "known-issues",
    "sourceDataFields": [
      { "name": "sp_item_id" }, { "name": "title" }, { "name": "sp_modified" }
    ]
  }
}

The JSON follows the shapes on the Learn pages linked here; check them against the current API before you rely on them. Then create a knowledge base that references known-issues-ks, and either call its retrieve action from the old app’s backend or connect it to a Foundry agent. Use sp_item_id in the answer to link back to the SharePoint item, and sp_modified to say how fresh it is.

Does azure-search-openai-demo work with SharePoint lists?

Not directly. Microsoft’s azure-search-openai-demo sample on GitHub now runs on agentic retrieval and has an optional SharePoint source. Its docs say that source searches SharePoint documents with the signed-in user’s token and needs users to hold a Microsoft 365 Copilot licence. It does not describe list items.

The sample also builds its own index, and its code expects its own field names, such as content and sourcepage. To use it over a list, either change its field names to match an SPSync index, or keep the sample for documents and put the list behind a separate knowledge source in the same knowledge base.

What the index does not carry

SharePoint item permissions are not copied. Foundry IQ can enforce permissions at query time for sources that bring access control data with them, and an SPSync index has none to enforce, so anyone the knowledge base serves can retrieve every item. Scope the app to people who may see the whole list. File contents are not copied either: SPSync replicates list columns and library metadata, so documents belong in a source built for them.

Two operational points. If you change SPSync’s embedding dimensions or a column’s type, SPSync creates a new index with a -v2 suffix, because Azure AI Search cannot change an existing field. The new index starts without your semantic configuration and vectorizer, and the knowledge source still points at the old name, so add both again and repoint the source. And Foundry IQ ranks passages; it cannot count. “How many known issues are open for the VPN client?” needs the same list in a SQL table, which the Foundry post shows with a view and an MCP tool, and the guide to SharePoint lists in AI frameworks covers from other frameworks.

If your vectors need to stay outside Azure, Postgres with pgvector gets the same embeddings on sync, and our post on keeping SharePoint data in region for AI follows each hop. For the retrieval side in general, see RAG over SharePoint lists and the map of the Microsoft AI stack for SharePoint lists. SPSync ships no agent; the knowledge base and the app are yours.