SharePoint to Azure AI Search (keyword, vector and hybrid)

Last updated 23 October 2026

Status: Shipped · product: SPSync for Search & Vector Stores

SPSync copies SharePoint lists into Azure AI Search one way, so SharePoint stays the system of record and the index is a copy that SPSync keeps current. You get keyword, filter and facet search over list items, and a vector field for hybrid search if you want one. Once you turn embeddings on, SPSync generates the vector for every document during the sync itself, with no embedding job of your own.

If you look after a search page, a Copilot Studio agent or a retrieval pipeline over a SharePoint list, you may have read that Microsoft’s own indexer now reads lists and wondered whether you still need a separate tool. This page gives the facts as Microsoft Learn stated them on 22 October 2026, then what SPSync does differently, so you can pick the one that fits.

Does Azure AI Search index SharePoint lists?

Yes, in preview. The SharePoint in Microsoft 365 indexer now indexes list items and their column values, starting in the 2026-05-01-preview REST API, and the What’s new page lists the change under June 2026. Preview features carry no service-level agreement and Microsoft does not recommend them for production workloads.

To try it you complete Microsoft’s preview registration form, run a Basic tier or higher search service and configure the indexer through a preview REST API. The same Learn page lists two limits that rule it out for some tenants: no private endpoints, and no support for tenants with Microsoft Entra ID Conditional Access enabled.

What the Azure AI Search SharePoint indexer gives you for lists

It does a good deal. It indexes incrementally, picking up new and changed list items, and an item deleted in SharePoint is removed from the index on the next indexer run, which runs in your search service on the schedule you give it. With permission metadata ingestion, also in preview, it can store basic access control lists for list items and trim results to what each user may see, which SPSync does not do. A skillset on the indexer can split text into chunks and embed it with an Azure OpenAI embedding model or a custom skill. For document libraries it extracts the text inside files, and SPSync copies library metadata only, never file contents.

Each list item arrives with its values as JSON in a content field, and every list column appears as a source field you map to an index field by hand. Learn’s worked example maps a text column, a number, a Yes/No and a choice column. It does not say how lookup, person or multi-value columns arrive, so test those on your own lists before you rely on them.

Microsoft also points people building a custom Copilot or RAG app over SharePoint towards the remote SharePoint knowledge source, which queries SharePoint directly and keeps no index at all.

Where SPSync differs from the native indexer

SPSync starts from a different place. It reads each list through Microsoft Graph with Sites.Selected read access, normalises the items, and then writes them to whichever destination you configured. With Azure AI Search as that destination, the differences you will notice are these:

• a single lookup column becomes a key field and a display-name field, so you can filter on the related item’s id and search its display value;
• multi-value choice, lookup and person columns become their own child indexes, and people share one sp-users index;
• embeddings come from OpenAI, Azure OpenAI or a local model with no API key, one vector per item built from the text columns you name (SPSync does not split long text into chunks);
• the same lists can go to SQL Server, Postgres or another destination through a second replication, so reporting and search read from matching copies;
• if your vectors need to live outside Azure, Postgres with pgvector gets the same embeddings on sync.

Keep the two gaps in mind when you compare them. SharePoint item permissions are not copied, so the index is visible to anyone holding a query key. And SPSync does not index the text inside files.

SharePoint list to Azure AI Search index fields

SPSync needs the service endpoint, https://<service>.search.windows.net, and an admin API key held in an environment variable. Creating and updating indexes requires an admin key; a query key will not do. Entra ID sign-in is not supported yet. The REST API version defaults to 2024-07-01 and rarely needs changing. SPSync also keeps a local state file between runs, so give it a stable path on the sync host.

Each table becomes an index, with underscores in the name replaced by dashes: one per list, one per multi-value column, and one shared sp_users table as the sp-users index. A knowledge article list, kb_articles, gives a kb-articles index, a kb-articles--audiences child index for a multi-choice Audiences column, and sp-users. Every index uses an sp_key field as its document key.

Field attributes follow the column type:

• titles, single-line text, choice values and lookup display names are searchable, filterable, sortable and facetable;
• multi-line text is searchable only, since it can exceed the service’s filterable size;
• numbers and dates are filterable and sortable, and whole numbers, dates and Yes/No columns are also facetable;
• IDs are filterable.

You choose which text columns feed the vector field; the filterable and facetable flags follow the column type and need no configuration.

Embeddings on sync for hybrid search

Azure AI Search and Postgres with pgvector are the two SPSync destinations that receive vectors. Turn on embeddings by naming a provider (OpenAI, Azure OpenAI or a local model), a model, the vector dimensions and the text columns to embed. SPSync adds an sp_embedding field to each list’s main index and fills it on every run for documents whose text changed, so an unchanged item is never sent to the embedding model again.

Changing the model keeps the same index, and the next run re-embeds every document in it. SPSync creates a new index version, named with a -v2 suffix, only when the vector dimensions change or a column changes type, because Azure AI Search cannot change an existing field. Leave embeddings off and you get a keyword index with filters and facets.

SPSync configures one HNSW vector profile with the service defaults. It adds no semantic ranker, scoring profiles or analysers, and changes you make to those in the portal are kept, because SPSync only ever updates the field list.

What each run sends

After each run SPSync sends only documents whose content changed, plus removals, in batches of 1,000. A reconcile, weekly by default, re-sends everything as a check on the index, which also puts back any document someone edited or deleted in the index by hand. A push that fails is retried on the next run.

Azure OpenAI On Your Data and SharePoint lists

Azure OpenAI On Your Data retired on 14 October 2026 and Microsoft no longer supports it. For apps that read from an Azure AI Search index, Learn’s migration guidance moves them to Foundry IQ and reuses the existing index. An index SPSync maintains is an ordinary Azure AI Search index, so it can be that index once you add the semantic configuration and query-time vectorizer Foundry IQ asks for, and SPSync keeps refreshing it whichever app reads from it. SharePoint lists in Foundry IQ after On Your Data retired walks through that migration step by step. Our chat over SharePoint data page covers the retrieval side, and Azure AI Foundry agents and SharePoint list rows shows where the Azure AI Search tool fits beside a SQL route for counts.

Uses

A search page over SharePoint lists, a Copilot Studio agent grounded on list data, chat over your SharePoint data, and retrieval for a RAG pipeline.

Azure AI Search bills by tier and index size, so the number of lists and the size of long text fields both affect cost.

spsync auth login --client-id 00000000-0000-0000-0000-000000000000
spsync export-config --output replication.yaml --pipeline-name azure_ai_search --prefix azure_ai_search --destination-kind azure-ai-search --connection-string-env SPSYNC_DB_CONNECTION --dataset-name azure_ai_search --client-id 00000000-0000-0000-0000-000000000000 --site-url https://contoso.sharepoint.com/sites/example --all-lists
spsync doctor replication.yaml
spsync run replication.yaml

pipeline_name: azure_ai_search
prefix: azure_ai_search
auth:
  mode: delegated
  client_id: 00000000-0000-0000-0000-000000000000
  tenant_id: common
destination:
  kind: azure-ai-search
  connection_string_env: SPSYNC_DB_CONNECTION
  dataset_name: azure_ai_search
scopes:
  - site_url: https://contoso.sharepoint.com/sites/example
    mode: entire_site
reconcile_interval_days: 7
create_reporting_views: false

# every night at 02:00
0 2 * * * cd /opt/spsync && SPSYNC_DB_CONNECTION="$(cat /etc/spsync/db.env)" uv run spsync run replication.yaml >> /var/log/spsync/run.log 2>&1

# .github/workflows/spsync-run.yml
name: SPSync
on:
  schedule:
    - cron: "0 2 * * *"
  workflow_dispatch: {}
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@v3
      - run: uv sync
      - run: uv run spsync run replication.yaml
        env:
          SPSYNC_DB_CONNECTION: ${{ secrets.SPSYNC_DB_CONNECTION }}
          SPSYNC_LICENCE_KEY: ${{ secrets.SPSYNC_LICENCE_KEY }}

# azure-pipelines.yml
schedules:
  - cron: "0 2 * * *"
    branches: { include: [main] }
    always: true
steps:
  - script: uv sync
  - script: uv run spsync run replication.yaml
    env:
      SPSYNC_DB_CONNECTION: $(SPSYNC_DB_CONNECTION)
      SPSYNC_LICENCE_KEY: $(SPSYNC_LICENCE_KEY)

# Windows Task Scheduler action (see /docs/cli/automation/)
$env:SPSYNC_DB_CONNECTION = (Get-Content C:\spsync\db.env)
uv run spsync run C:\spsync\replication.yaml
schtasks /Create /SC DAILY /ST 02:00 /TN "SPSync" /TR "powershell -File C:\spsync\run.ps1"

# ~/Library/LaunchAgents/io.spsync.run.plist, then: launchctl load ~/Library/LaunchAgents/io.spsync.run.plist