Connect to Azure AI Search

A compliance team hands you three things: a search endpoint, an index name, and an admin key. They want an agent that answers from the four thousand policy PDFs behind that index. The handover takes a lot for granted on your behalf: that a vector index, an embedding model and an endpoint URL are familiar objects, and that adding a knowledge source to an agent and testing it is routine work for you. What it says nothing about is the part that decides the outcome. Whether this particular index can answer at all, which authentication type the environment's rules leave you, why a freshly added source stays silent, and why the citation link comes back broken are four separate questions, and a good share of the failures on this surface are already decided before you open Copilot Studio.

Start from what the product claims. Azure AI Search provides a powerful search engine that can search through a large collection of documents, and Copilot Studio supports adding Azure AI Search as a knowledge source^[1]. That support is real and it is narrow: Copilot Studio consumes a vector index that was prepared in Azure AI Search first, with its integrated vectorization and any semantic-ranker configuration already in place. Microsoft's own training walkthrough says so in as many words, describing the index creation work of choosing an embedding model, configuring chunking, and running the vectorization pipeline as an Azure AI Search admin task^[2], with the maker connecting to an index that has already been prepared.

Two sides and a seam

That split is the mental model for the whole page, and this guide names the halves plainly. The Azure side is the search service, the index, its vector fields, its vectorizer (the object in the index schema that turns an incoming question into a vector, detailed later on this page) and its semantic configuration (the named list of fields a reranker reads, also detailed later). The Copilot Studio side is the agent, its knowledge sources, and the Test your agent panel you check them in. Between them sits the search data connection, the stored Power Platform connection that lets the agent reach the service at all. Microsoft italicises that noun deliberately when it says you must add Azure AI Search through a formal data connection^[1], and this guide uses the qualified form throughout, reserving Microsoft's bare data connection for quotations. Note the near-collision with two Power Platform terms you already use: a connection is any stored credential for a connector, and a connection reference is the solution-aware pointer to one. A search data connection is a connection of that kind, but the rules on this page attach to this particular one, and the environment-level failure below is not a general property of every connection.

Sorting a symptom by side is the fastest diagnosis this page offers. Answers that come back thin, or ranked oddly, or missing the obvious document, are almost always Azure-side: the wrong embedding model, no query-time vectorizer, no semantic configuration. A dialog that will not load, a source stuck out of the Ready state, or a citation that points at nothing, are Copilot Studio-side or connection-side. The figure below places every setting this page discusses on one side or the other, with the connection as the crossing point.

What this page covers, and what the siblings cover

Domain 2 has four pages that all sound like grounding, so the boundaries matter. Connect to Copilot connectors covers content indexed by Microsoft Search through a Copilot connector. Connect to Power Platform connectors covers the opposite arrangement, where a connector answers from live rows at query time and nothing is copied anywhere. Ground answers with Azure AI Search covers a different mechanism that shares this page's product name: the generative answers node's Classic data path, where an Azure OpenAI connection is configured inside the node itself. That is a separate wiring, and Microsoft's note under Classic data exists precisely because the two are confused. The general anatomy of any knowledge source, including retrieval scope and selection metadata, is covered by Configure custom knowledge.

One piece of vocabulary from that page does not stretch to this one. Ingested source and live source are its shorthand for the two SharePoint options, one of which copies files into Dataverse while the other queries SharePoint at request time. An Azure AI Search knowledge source is neither: the content stays in a search service you own, outside Dataverse, and Copilot Studio queries that service. Reach for the two-sides model above rather than trying to file this source under the SharePoint pair.

What this page covers is the direct route: Add knowledge, a search data connection, one vector index, and the agent grounding on it. The four questions the opening handover left unanswered are answered in that order, starting with the side of the seam that decides most of them.

An index full of correct embeddings can still be useless to an agent, and the reason is that grounding needs the question turned into a vector too. Copilot Studio is specific about which indexes it supports: Copilot Studio supports vectorized indexes using integrated vectorization, and that method enables the system to use the same embedded model used to vectorize the data to also vectorize the incoming prompt at runtime, which reduces the need to write special functions to do the same^[1]. Read the second half of that sentence as the requirement, not the benefit.

Integrated vectorization is Azure AI Search's name for doing the encoding inside the search pipeline rather than in your own code, and Azure describes it as an extension of the indexing and query pipelines that adds vector encoding during indexer-driven indexing and vector encoding during queries^[3]. Two halves, and they are configured separately.

The indexing half and the query half

The indexing half is an indexer plus a skillset: a chunking strategy and an embedding skill, where the embedding skill can be the AzureOpenAIEmbedding skill, a custom skill pointing at another embedding model, the Azure Vision multimodal embeddings skill, or an AML skill pointing at models in the Microsoft Foundry model catalog^[3], among the options Azure lists for that step. Chunking matters for a practical reason rather than a doctrinal one: chunking isn't a hard requirement, but unless your raw documents are small, chunking is necessary for meeting the token input requirements of embedding models^[3].

The query half is one object with one job. Azure defines it as a vectorizer, defined in the index schema, assigned to a vector field, and used automatically at query time to convert a text query to a vector^[3], and then states the constraint that decides whether an agent gets sensible answers: the vectorizer you set up must match the embedding model used to encode your content^[3]. Azure repeats it in the query-only setup path as well, where step one is to add a vectorizer that should be the same embedding model used to generate vectors in the index^[3]. Azure publishes the pairing as a table, so an AzureOpenAIEmbedding skill pairs with the Azure OpenAI vectorizer, a custom skill with the Custom Web API vectorizer, and so on. The figure below shows both halves converging on the same vector field, which is the picture worth carrying into a question.

The two failures this produces

The first is an index with no vectorizer at all. A data team that computes embeddings in a nightly script and pushes the arrays into a vector field has satisfied the indexing half and skipped the query half entirely. The documents are there, the vectors are there, and nothing in the index knows how to encode an incoming question. The repair is on the Azure side: define a vectorizer in the index schema that matches the embedding model used to encode the content, or rebuild the index through integrated vectorization.

The second is a mismatch. Stored vectors produced by one model deployment, and a vectorizer pointed at a different one, need not fail loudly. Both sides return numbers of the right shape, so the comparison can be meaningless while nothing raises an error; what Azure documents is the requirement that the two match, not a particular failure mode. This is why the constraint is a matching constraint rather than a presence constraint.

For teams who are not permitted to build and run their own embedding pipeline, the portal path is the answer Microsoft points at. The Copilot Studio article says to prepare your data and choose an embedded model, then use Import and vectorize data in Azure AI Search to create vector indexes^[1]; the Azure article recommends the same portal wizard, referring to it as the Import data wizard^[3] in a tip. Both names point at the same portal experience for vectorizing content. Choosing it is what makes the index compatible without anyone writing a function.

Semantic ranker is the most over-promised setting on this surface, and knowing its exact boundary answers a whole family of questions. Azure defines it as a feature that measurably improves search relevance by using Microsoft's language understanding models to rerank search results^[4], and then draws the boundary itself: what semantic ranker can't do is rerun the query over the entire corpus to find semantically relevant results, because semantic ranking reranks the existing result set, consisting of the top 50 results as scored by the default ranking algorithm^[4].

That is the whole story in one line. Semantic ranker fixes ordering, not recall. A stakeholder who expects it to surface documents the first pass never returned is expecting something the feature explicitly does not do, and the honest answer is that the recall problem belongs to the query and the index, not the reranker.

Where it sits in the pipeline

The first pass is the search engine's own scoring: a BM25-ranked result from a text query or an RRF-ranked result from a vector or hybrid query^[4], where BM25 is the keyword relevance score and RRF is Reciprocal Rank Fusion, the method that merges the rankings of a hybrid query. The reranking layer, which Azure calls L2 ranking, then uses the context or semantic meaning of a query to compute a new relevance score over preranked results^[4]. The figure below places the fifty-document boundary between the two stages, because that boundary is what most scenarios turn on.

Two details from the same article change how you prepare an index for it. The reranker builds its input from named fields: the summarization model assembles inputs from the title, keyword, and content fields listed in the semantic configuration^[4], with published token allowances of 128 tokens for title, 128 for keywords and the remainder for content. Because the system trims long strings to fit, Azure says it's important to add fields to your semantic configuration in priority order^[4]. And the content type matters: the language models in semantic ranker work best on searchable content that is information-rich and structured as prose, so a knowledge base, online documentation, or documents that contain descriptive content see the most gains^[4]. Long prose-heavy policy articles are the canonical fit; the further content sits from information-rich prose, the less the reranker's language models have to work with.

It is worth being precise about what the reranker returns, because it is often confused with generation. Semantic captions and answers are always verbatim text from your index, and there's no generative AI model in this workflow that creates or composes new content^[4]. The generation happens later, in the agent.

It is an Azure-side prerequisite

Copilot Studio's position is a sequencing rule. Copilot Studio also supports the use of the semantic ranker feature, and this feature also needs to be configured in Azure AI Search before adding the connection in Copilot Studio^[1]. Do the Azure work first, then connect.

On one point the two published sources differ and this guide will not pick a winner. The Copilot Studio article describes only the prerequisite and shows no semantic-ranker control in its numbered steps. The training unit says that if the tier supports the feature and it has been enabled in Azure AI Search, you can activate it when configuring the knowledge source in Copilot Studio^[2], while its own note repeats that the semantic ranker feature must be enabled in Azure AI Search before you can configure it in Copilot Studio^[2]. Whether a Copilot Studio-side activation control exists is therefore contested between the two pages. What both agree on, and what is safe to build and to answer on, is the ordering: configure semantic ranker in Azure AI Search first, and availability depends on the search service, since Azure publishes semantic ranker as available in select regions^[4] with its own billing plan.

Some search services are deliberately unreachable from the internet, and the agent still has to query them. Copilot Studio supports that arrangement: Copilot Studio supports Azure AI Search indexes configured for virtual networks, and this configuration allows you to use a private endpoint to securely connect your search indexes^[1]. The catch is that it takes configuration on both sides, and neither side is configured from the agent.

On the Azure side, a private endpoint is a tier decision before it is a network decision. Azure states the prerequisite twice, once in the prerequisites list and once in the portal walkthrough: Azure AI Search service (Basic tier or higher), because private endpoints aren't supported on the Free tier^[5]. A pilot built on the Free tier therefore cannot be hardened in place; the service has to be recreated on Basic or higher. That is a small fact with a large consequence for a project plan, and it is the reason a scenario mentioning the Free tier is usually asking about the tier rather than about the network.

The cheat-sheet compression of all this, that virtual network support is configured "for both the search service and the Power Platform environment", is a useful shorthand and not quite the vendor's wording. On the search side the named feature is a private endpoint on a Basic-or-higher service, which is itself an object in a virtual network of your own; virtual network support is the name Power Platform gives its half. On the Power Platform side, then, the mechanism is virtual network support. Microsoft describes it as using Azure subnet delegation to manage outbound traffic from Power Platform at runtime, so that Power Platform components can call resources owned by your enterprise inside your network^[6]. Azure AI Search is a named beneficiary rather than an assumed one: the supported-services table lists AI search under connectors as generally available^[6] and links that row to this very knowledge-source article. Two prerequisites from the same doc set decide whether the option is even available: environments must be managed environments^[7] to enable virtual network support, and the supported environment types are production, default, sandbox and developer, with trial environments and Microsoft Dataverse for Teams listed as not supported^[6].

Where the builder's job stops

Delegating a subnet, creating the enterprise policy and linking it to an environment is administrator work, done in Azure and the Power Platform admin center, and it is outside what an agent builder configures. The training unit draws the same line and gives the practical instruction: virtual network support is typically an infrastructure decision made before a maker begins configuring knowledge sources, so confirm with your Azure administrator that VNet support has been configured in the Power Platform admin center before you start the connection setup^[2].

So the builder-side skill here is recognising a prerequisite, not executing it. The figure below shows the private path and marks which prerequisite sits on which side. Once both are in place, nothing about the connection itself changes: Microsoft's article ends the virtual-network section by telling you to follow the steps to complete the configuration of the connection^[1] in Copilot Studio, which are the same steps the next two sections walk through. There is no private-endpoint checkbox in the wizard, and the absence of one is the point: the network path is decided underneath the agent, not inside it.

There is one instruction on this surface that is worth more than the rest of the wizard combined, and Microsoft states it as a rule and a prohibition in the same breath: you must add Azure AI Search through a formal data connection, and you shouldn't manually configure an endpoint and API key^[1]. The training unit repeats it and adds the operational version: always add Azure AI Search through the Create new connection dialog, never by manually entering an endpoint URL and API key directly in the knowledge source form^[2].

What makes this worth a rule rather than a preference is the size of the failure. Microsoft's own description of the consequence is unusually blunt: if you create an unsupported Azure AI Search connection, Copilot Studio might store a faulty data connection that prevents the Azure AI Search connection dialog from loading, the dialog might briefly appear and then fail with an error, and Copilot Studio doesn't currently provide an interface to delete a broken Azure AI Search data connection^[1]. Then the sentence that decides the blast radius: because data connections are managed at the environment level, this issue can affect all agents^[1].

Environment-level means somebody else's agent breaks

Read that scoping literally, because it is the difference between an inconvenience and an incident. The faulty object is stored in the Power Platform environment, not in the agent you were building. A maker experimenting in a shared development environment can leave a broken connection behind, and a second maker who has never touched Azure AI Search opens the same dialog on a different agent and watches it flash and fail. The figure below shows that shape: one bad object, three affected agents, and only one of them ever created it.

Recovery is correspondingly awkward, which is the second reason the rule is worth memorising. Microsoft offers exactly two moves: to recover the connection, reset the agent's external access or delete and recreate the affected agent^[1]. Neither is a tidy delete of the offending connection, because no such command exists. So the answer to a scenario describing this symptom is never "remove the bad connection" and never "re-add the knowledge source"; it is the recovery pair Microsoft publishes, and the prevention is going through Create new connection every time.

Two published routes, one of them stale-looking

One wrinkle deserves flagging rather than smoothing over. The same article's numbered walkthrough tells you to open Add knowledge, choose Featured, select Azure AI Search and then Create new connection. Its recovery note, a few lines earlier, tells you that when re-adding Azure AI Search, use Data sources then Azure AI Search with Entra ID authentication, not API keys^[1]. Those are two different navigation paths on one page, and the article never reconciles them. The training unit, published a fortnight later, gives only the Add knowledge route. Treat Add knowledge as the path to follow and the recovery note as guidance about the authentication choice rather than a second menu, and do not build a mental model that depends on which menu label appears in a question stem.

The half of that note that is not in tension with anything is the authentication advice, and it lines up with the training unit's recommendation. So the takeaway from this section is a single habit with an outsized payoff: reach the wizard through Add knowledge and create the connection inside it, because the one shortcut available here damages an object you cannot then delete, in a scope you do not control. Which credential that connection should carry is the next section's subject.

The wizard asks for an Authentication type before it asks for anything else interesting, and the four choices are not interchangeable. Microsoft lists them as Access Key, Client Certificate Auth, Service principal (Microsoft Entra ID application), and Microsoft Entra ID Integrated^[1], and you then enter the details required for the authentication type^[1]. The overview table on this page compares them on the axes that decide the choice; this section explains why those axes are the ones that matter.

What each option actually stores is published in the connector reference, and it is more specific than the wizard labels suggest. The key-based option takes an Azure AI Search Endpoint URL and an Azure AI Search Admin Key^[8], both required. Client Certificate Auth takes the endpoint, a tenant, a client ID and a client certificate secret. Service principal takes the endpoint, a tenant, a client ID and a client secret. Microsoft Entra ID Integrated takes the endpoint URL alone^[8], which is the whole point of it: there is no secret in the connection to rotate, expire or leak.

The two selection pressures

There are only two questions worth asking, and they come from opposite directions.

The first is what the search service will accept. Azure AI Search defaults to keys, and the consequence is stated as a troubleshooting item: the default configuration for a search service is key-based authentication, and if you don't change this setting to Both or Role-based access control, all requests that use role-based authentication are automatically denied, regardless of the underlying permissions^[9]. The mirror case is the one that appears in scenarios more often. When an administrator has hardened the service by turning key authentication off, Access Key simply cannot work, and the fact that a maker holds a data-plane role assignment does not rescue it. There is also a precedence rule worth knowing because it produces a confusing symptom: if your request includes an API key alongside role-based credentials, the service authenticates using the key^[9].

The second is what your organisation will accept as a stored credential. The training unit's recommendation is unambiguous: Microsoft Entra ID Integrated authentication is the recommended option, because it uses the signed-in user's identity rather than a stored key or certificate, which removes the overhead of key rotation^[2]. Read "the signed-in user" there as Power Platform reads it, meaning whoever is signed in when the connection is created, which is the maker. Read it as the identity that creates the connection rather than as the person who later asks the agent a question; the last part of this section explains why that distinction matters at runtime. A tenant that already registers a workload identity and rotates its secret on a schedule is describing Service principal, and the unit places it accordingly, for automated or service-to-service connection scenarios^[2].

When role-based access is the route, grant the least role that can run a query. Search Index Data Reader has read-only content access and can query indexes, and can't load documents, modify object definitions, or retrieve admin keys^[9]. Grounding only reads, so that is the whole requirement. Search Service Contributor is a common wrong answer in this shape, because it manages objects but can't load documents, query indexes, or retrieve from knowledge bases^[9]: it is more privilege and less capability for this job.

Two things the option list does not say

First, the connector reference marks one option Shareable and the rest not. Client Certificate Auth is shareable; Access Key, Microsoft Entra ID Integrated and Service principal are each described as not shareable, meaning another user is prompted to create a new connection explicitly^[8]. That is a co-authoring and solution-import consideration rather than a runtime one, but it is the reason a second maker sometimes has to re-authenticate a source that already works.

Second, a managed identity is not on the menu here even though the connector defines one. The connector reference lists a Managed Identity connection type and scopes it explicitly: Applicable: LOGICAPPS only^[8]. An answer proposing that the agent authenticate to the search service with a managed identity is describing a capability the same connector has in a different host, not in this one.

Whose identity reaches the index

One consequence follows from all four options and it is the most commonly assumed-away fact on this page. The credential in the search data connection is what queries the index. Microsoft's knowledge-sources summary assigns the agent user's Microsoft Entra ID authentication^[10] to SharePoint, Dataverse and connector-indexed enterprise data, and explains that this means the agent only surfaces content the asking user can access. Azure AI Search is not one of the rows in that table. No Microsoft page states the negative in a single sentence, so treat this as a reading of two pages rather than a quotation, but the reading is well supported: the connection carries a maker-chosen credential, and Microsoft's citation guidance separately assumes the reader may not be able to open what the agent cites. Nothing in the agent's own authentication setting is documented to change which credential the search data connection presents, so do not expect switching it to Authenticate with Microsoft to trim results per person. The figure below traces that chain and marks the node where the connection's own credential takes over the query.

If per-person trimming is a requirement, it has to be solved on the Azure side, in the index itself, not by choosing a different item from this list.

With the connection created, the remaining Copilot Studio work is short, and it contains exactly one gate that produces most of the confused bug reports on this surface.

The path is the one Microsoft numbers. Open the agent and select Add knowledge from either the Overview or Knowledge pages, or the Properties of a generative answers node^[1]; from the Add knowledge dialog select Featured, then Azure AI Search, then Create new connection; pick the authentication type, enter its details and select Create, at which point a green check mark appears to confirm the connection^[1]; select Next; then enter the Azure AI Search vector index to be used, where only one vector index can be added^[1]; and finish with Add to agent.

One index per connection

Step ten is worth reading carefully because the scope of its limit is what scenarios test. The product article says only one vector index can be added. The training unit scopes it explicitly: only one index can be added per connection^[2]. So the limit binds the pairing you are creating, not the agent as a whole. A second body of content in a second index means a second knowledge source, and an agent can hold both alongside knowledge sources of entirely different types. What you cannot do is point one Azure AI Search knowledge source at two indexes and expect the agent to search across them, or edit the binding into a list.

The green check mark is worth debunking at the same time, because it is a favourite distractor. It confirms that the connection was created. It says nothing about the index name you have not typed yet, nothing about whether that index carries a vectorizer, and nothing about whether the source will reach Ready.

Ready is the gate, and only Ready

After you add the source it appears in the knowledge sources table, and Microsoft describes the sequence. One word in it misleads on first read: the indexing being described is Copilot Studio's own metadata indexing of the source it has just been given, not a second pass over your documents. Your Azure AI Search index is already built and Copilot Studio never rebuilds it. With that read in place, the published sequence is: the status displays as In progress while Copilot Studio indexes the metadata, and after the indexing is complete the status is updated to Ready, and you can begin testing the knowledge source^[1]. The testing article states the constraint as a hard one: you can only use knowledge sources with a Ready status in Test your agent^[11].

So a maker who finishes the wizard, opens Test your agent and immediately asks a question is usually just early. Read the status in the knowledge sources table before changing anything: while a source is still preparing, waiting is the remedy rather than reconfiguration, and re-adding it only restarts the same wait. A source that is not Ready for some other reason is a different problem, and the rest of this section covers it.

One inconsistency between those two articles should be named rather than smoothed over, because a reader will meet it. The testing article, which is the fresher of the two, scopes the intermediate state narrowly: In progress means this knowledge source isn't ready for you to use in Test your agent, and this status only applies to file upload and Dataverse knowledge sources^[11]. The Azure AI Search article says an Azure AI Search source shows exactly that status. The two cannot both be complete descriptions, and neither page acknowledges the other. What survives the disagreement, and what is safe to design and answer on, is the rule they share: nothing is testable until the source reads Ready.

When the status is not In progress either

Two other states are published, and their causes are useful because they are not about waiting. Unknown means the knowledge source is blocked^[11], and the causes Microsoft lists include incorrect authentication and a data policy that blocks the source, alongside a Dataverse-specific search prerequisite. Error means the knowledge source had problems while preparing^[11], for reasons that include the knowledge source limit being reached. The figure below lays the four states out together. A source reporting Unknown rather than In progress is therefore telling you it is blocked, not that it is slow, and the diagnosis moves to Microsoft's published causes — incorrect authentication, a data policy that blocks the source, and the Dataverse search prerequisite — rather than to patience.

An agent grounded on an Azure AI Search index will happily answer with no link back to the document, and the reason is structural rather than accidental: Copilot Studio does not construct a document link, it reads one out of the index. To return citations when using Azure AI Search in Copilot Studio, include a URL field with the actual link to the document in the search index^[1]. If no field holds a URL, there is nothing to cite with.

The resolution order is published and it has two steps. When the metadata_storage_path field is included in the index, Copilot Studio interprets that field as the citation; however, if that field doesn't exist, Copilot Studio considers whatever field contains a complete URL link as the citation^[1]. The training unit gives the same order and a worked case: an index with a custom source_url field pointing at each internal document page, which Copilot Studio detects as the citation URL automatically^[2]. The figure below walks that order, including the outcome where neither branch finds anything.

Where metadata_storage_path comes from

metadata_storage_path is not a Copilot Studio field and not a naming convention you invent. It is one of the standard blob metadata properties an Azure AI Search blob indexer produces, defined as the full URI of the blob, including the storage account, for example https://myaccount.blob.core.windows.net/my-container/my-folder/subfolder/resume.pdf^[12], with Azure's own note that you use this property to include blob URLs in search results for navigation or source attribution^[12].

That provenance explains the most common citation failure. An index populated by pushing documents through the search service's REST API rather than by running a blob indexer carries none of the metadata_storage_ properties, because nothing produced them. Such an index needs a URL-valued field of its own, populated by whatever writes the documents. The second-branch rule is what makes that workable: any field holding a complete URL will do, and it does not need Microsoft's field name.

One more provenance trap is worth naming. The indexer only writes metadata into fields that exist. Azure states it as the most common cause of empty metadata: the indexer populates only metadata fields that are already defined in your search index, and if a field isn't defined, the metadata value is extracted during indexing but silently discarded^[12]. So "we run a blob indexer" is not by itself evidence that metadata_storage_path is in the index. Someone had to define the field.

A citation is a pointer, not a permission

The half that surprises people is what a working citation does not do. Microsoft attaches the warning directly to the citation guidance: ensure that the users of your agent have the necessary permissions to access the data sources the citations point to, because if the URL points to a restricted data source, the users can't access the generated citations^[1].

This is where the identity chain from earlier on this page becomes visible to end users. The index was queried with the connection's credential, so the agent can summarise a document the asking user has never been granted. The citation then hands that user a link they cannot open. The remedy is a permissions decision about the target system, made deliberately, not a Copilot Studio setting: either the audience is granted access to the referenced repository, or the index should not be exposing that content to this agent's audience at all.

Two rendering constraints belong here too, since they explain citations that vanish rather than citations that break. Customising the answer suppresses them: if you customize the generative answer response, citations aren't added automatically, so if you clear a Message node and render the answer yourself through a variable or an Adaptive Card, you need to include citation rendering yourself^[10]. And Microsoft Teams applies its own ceilings, where a response shows at most 20 citations and any beyond that are dropped^[10], with title and snippet lengths shortened as well. A citation that works in the test panel and disappears in Teams is usually one of those two, not an index problem.

The sibling page on Power Platform connectors establishes a distinction this page inherits wholesale: one connector can serve a knowledge use, where it grounds an answer, and an action use, where a connector operation does something on request. Azure AI Search is the clearest case of both being available and only one being correct for grounding.

The trap is real because the wrong option genuinely exists. The Azure AI Search connector publishes typed operations, and the reference lists them: Search vectors, Search vectors with natural language, Semantic Hybrid Search, Get search indexes, Get index statistics, Index a document, Merge a document, Delete a document^[8] and others. Any of those can be added to an agent as a tool. Doing so is a perfectly ordinary thing to do, and it does not ground anything.

Why importing the operations does not ground the agent

A tool is a capability the orchestrator can choose to call. A knowledge source is content that generative answers retrieves from. They are different registries with different configuration surfaces, and the wiring that makes generative answers search an Azure AI Search index is the knowledge source, created through Add knowledge. Adding Search vectors as a tool gives the orchestrator a callable operation with parameters to fill; it does not put the index into the set that generative answers searches, and it does not produce the citation behaviour of the previous section.

The symptom this produces is distinctive. The agent has a tool that plainly works when invoked, and answers that are still ungrounded or generic, because nothing added the index to the knowledge side. The fix is to add the index as a knowledge source, not to tune the tool. The figure below shows both branches leaving the same connection.

When the action use is the right answer

Grounding only reads, so any requirement to change the index is an action use by definition. Writing a document into the index, merging a field, deleting a record, or reading index statistics for an operations dashboard are all jobs for a connector operation, and none of them can be expressed as a knowledge source. That is the honest division: knowledge for retrieval and grounded synthesis, tools for everything the agent has to do rather than know.

Two constraints bound the action use once you choose it, and both are covered in depth on their own pages. Tool budget is one of them: exposing many fine-grained operations at agent level pushes selection work onto the orchestrator, which Configure actions and connectors and Add tools to topics treat as a design decision rather than a capability question. Licensing and reach are the other: the connector reference classifies Azure AI Search as Premium in Copilot Studio, available in all Power Automate regions except US Government (GCC High), China Cloud operated by 21Vianet, and US Department of Defense (DoD)^[8], and it publishes a per-connection call ceiling in its throttling table that belongs in capacity planning rather than in a memorised list.

The rule to carry out of this section is short. If the requirement says the agent should answer questions from documents with citations, the answer is a knowledge source bound to a vector index. If it says the agent should do something to the index, the answer is a tool. An answer that proposes importing the search service's REST endpoints so that generative answers will ground itself is combining both halves incorrectly, and it is the distractor this page exists to defuse.

Scenarios on this surface are mostly diagnostic: a configuration that looks finished, a symptom, and four plausible repairs. Sorting the symptom by side, as the first section proposed, eliminates most of the distractors before you read them closely.

The recurring stems

"The connection dialog flashes and fails, and other agents are affected." This is the malformed data connection, and the two things that make it answerable are that data connections live at the environment level and that Copilot Studio currently provides no interface to delete a broken one. Correct answers reset the agent's external access or delete and recreate the affected agent, and prevent recurrence by using Create new connection. Distractors offer to delete the connection from a management screen, or scope the damage to the one agent.

"Retrieval returns nothing sensible from an index whose vectors were written by a nightly script." No vectorizer, so no query-side encoding. The repair is on the Azure side, and every Copilot Studio-side answer is wrong by construction. The same shape appears as a mismatch, where a maker later points the vectorizer at a different model deployment than the one that produced the stored vectors.

"Stakeholders expect the reranker to surface documents the search did not return." Semantic ranker reranks the top fifty results of the first pass and cannot rerun the query over the corpus. The right answer says so; distractors offer to raise a threshold or enable another semantic feature.

"The source will not answer in the test panel." If the status is In progress, wait. If it is Unknown, it is blocked, and the published causes — incorrect authentication, a blocking data policy, and the Dataverse search prerequisite — point away from time. Re-adding the source is almost never right.

"Citations are missing, or read as raw paths, or lead to an access-denied page." Three different faults with three different repairs. Missing means no URL-valued field in the index, which is what an index loaded through the push API ends up with unless whatever writes the documents supplies a URL field itself. Present but unusable means the audience lacks permission to the referenced repository, which no agent setting fixes. Gone after customisation means the answer is being rendered by hand and citations are no longer added automatically.

"A developer imported the search REST endpoints as actions and generative answers is still ungrounded." Knowledge use versus action use. The index has to be added through Add knowledge as a knowledge source; the tool is a capability, not content.

"Keys are disabled on the search service." Access Key is out, and a data-plane role assignment alone does not rescue it. Choose an identity-based type, and prefer the least-privilege role, which for grounding is Search Index Data Reader.

"The pilot search service is on the Free tier and must be private." The tier is the blocker, because private endpoints need Basic or higher. Virtual network support on the Power Platform side is the second half, and it is administrator work confirmed before the maker starts.

The two habits that pay

First, ask which side owns the symptom before choosing a repair. Half of the wrong answers on this surface are competent fixes applied to the other side of the seam.

Second, distrust confirmations. A green check mark confirms a connection, not an index. A Ready status confirms metadata indexing, not answer quality. A citation confirms that a field held a URL, not that anyone can open it. Each of those gaps is a question that has already been written.