@@ -2,10 +2,10 @@
 title: 'Tutorial: Create an End-to-End Retrieval Solution'
 titleSuffix: Azure AI Search
 description: Learn how to design and build a custom agentic retrieval solution where Azure AI Search handles data retrieval for your custom agents in Microsoft Foundry.
-author: HeidiSteen
-ms.author: heidist
+author: haileytap
+ms.author: haileytapia
 manager: nitinme
-ms.date: 12/22/2025
+ms.date: 01/27/2026
 ms.service: azure-ai-search
 ms.topic: tutorial
 ms.custom:
@@ -413,7 +413,9 @@ print(f"AI agent '{agent_name}' created or updated successfully")
 
 #### Connect to a remote SharePoint knowledge source
 
-Optionally, if you create a [remote SharePoint knowledge source](agentic-knowledge-source-how-to-sharepoint-remote.md), you must also include the `x-ms-query-source-authorization` header in the MCP tool connection.
+[!INCLUDE [foundry-iq-limitation](../ai-foundry/default/includes/foundry-iq-limitation.md)]
+
+Optionally, if your knowledge base includes a [remote SharePoint knowledge source](agentic-knowledge-source-how-to-sharepoint-remote.md), you must also include the `x-ms-query-source-authorization` header in the MCP tool connection.
 
 ```python
 from azure.search.documents.indexes.models import RemoteSharePointKnowledgeSource, KnowledgeSourceReference

@@ -1,5 +1,5 @@
 ---
-title: Custom AML skill in skillsets
+title: Custom AML Skill in Skillsets
 titleSuffix: Azure AI Search
 description: Learn how to extend the capabilities of Azure AI Search skillsets with Microsoft Foundry or Azure Machine Learning models.
 author: gmndrg
@@ -33,7 +33,7 @@ The indexer retries two times for the following HTTP status codes:
 + `503 Service Unavailable`
 + `429 Too Many Requests`
 
-## AML skill for models in Foundry
+## AML skill for models in Microsoft Foundry
 
 Azure AI Search provides the [Microsoft Foundry model catalog vectorizer](vector-search-vectorizer-azure-machine-learning-ai-studio-catalog.md), which is also available in the [**Import data (new)** wizard](search-import-data-portal.md#skills), for query-time connections to the model catalog. If you want to use this vectorizer for queries, the AML skill is the *indexing counterpart* for generating embeddings using a model from the model catalog.
 
@@ -45,7 +45,7 @@ We recommend using the [**Import data (new)** wizard](search-get-started-portal-
 
 + A [Microsoft Foundry hub-based project](/azure/ai-foundry/how-to/hub-create-projects) or an [AML workspace](../machine-learning/concept-workspace.md) for a custom model that you create.
 
-+ For hub-based projects only, a serverless deployment of a [supported model](#skill-parameters) from the Microsoft Foundry model catalog. You can use an [ARM/Bicep template](https://github.com/Azure-Samples/azure-ai-search-multimodal-sample/blob/42b4d07f2dd9f7720fdc0b0788bf107bdac5eecb/infra/ai/modules/project.bicep#L37C1-L38C1) to provision the serverless deployment.
++ For hub-based projects only, a serverless deployment of a [supported model](#skill-parameters) from the Microsoft Foundry model catalog. You can use [use the Azure CLI](vector-search-integrated-vectorization-ai-studio.md#deploy-an-embedding-model-as-a-serverless-deployment) to provision the serverless deployment.
 
 ## @odata.type
 

@@ -64,7 +64,7 @@ The portal supports the following models for each method. Deployment instruction
 
 <sup>1</sup> For billing purposes, you must [attach your multi-service account](cognitive-search-attach-cognitive-services.md) to your Azure AI Search skillset. Currently, the wizard requires your search service and multi-service account to be in the [same supported region for the Azure Vision multimodal embeddings skill](cognitive-search-skill-vision-vectorize.md#supported-regions), even when using keyless connections.
 
-<sup>2</sup> To use this model in the wizard, you must provision it as a serverless API deployment. You can use an [ARM/Bicep template](https://github.com/Azure-Samples/azure-ai-search-multimodal-sample/blob/42b4d07f2dd9f7720fdc0b0788bf107bdac5eecb/infra/ai/modules/project.bicep#L37C1-L38C1) for this task.
+<sup>2</sup> To use this model in the wizard, you must provision it as a serverless API deployment. You can use [use the Azure CLI](vector-search-integrated-vectorization-ai-studio.md#deploy-an-embedding-model-as-a-serverless-deployment) to provision the serverless deployment.
 
 <sup>3</sup> The endpoint of your Azure OpenAI resource must have a [custom subdomain](/azure/ai-services/cognitive-services-custom-subdomains), such as `https://my-unique-name.openai.azure.com`. If you created your resource in the [Azure portal](https://portal.azure.com/), this subdomain was automatically generated during resource setup.
 

@@ -56,7 +56,7 @@ The portal supports the following embedding models for integrated vectorization.
 
 <sup>1</sup> For billing purposes, you must [attach your multi-service account](cognitive-search-attach-cognitive-services.md) to your Azure AI Search skillset. Currently, the wizard requires your search service and multi-service account to be in the [same supported region for the Azure Vision multimodal embeddings skill](cognitive-search-skill-vision-vectorize.md#supported-regions), even when using keyless connections.
 
-<sup>2</sup> To use this model in the wizard, you must provision it as a serverless API deployment. You can use an [ARM/Bicep template](https://github.com/Azure-Samples/azure-ai-search-multimodal-sample/blob/42b4d07f2dd9f7720fdc0b0788bf107bdac5eecb/infra/ai/modules/project.bicep#L37C1-L38C1) for this task.
+<sup>2</sup> To use this model in the wizard, you must provision it as a serverless API deployment. You can use [use the Azure CLI](vector-search-integrated-vectorization-ai-studio.md#deploy-an-embedding-model-as-a-serverless-deployment) to provision the serverless deployment.
 
 <sup>3</sup> The endpoint of your Azure OpenAI resource must have a [custom subdomain](/azure/ai-services/cognitive-services-custom-subdomains), such as `https://my-unique-name.openai.azure.com`. If you created your resource in the [Azure portal](https://portal.azure.com/), this subdomain was automatically generated during resource setup.
 

@@ -4,7 +4,7 @@ titleSuffix: Azure AI Search
 description: Learn how to use the REST API for indexing documents with ACLs and RBAC metadata.  
 ms.service: azure-ai-search  
 ms.topic: how-to 
-ms.date: 09/18/2025 
+ms.date: 01/28/2025 
 author: admayber
 ms.author: admayber  
 ---  
@@ -33,7 +33,7 @@ This article explains how to use the push REST API to index document-level permi
 
 ## Limitations
 
-- An ACL field with permission filter type `userIds` or `groupIds` can hold at most 32 values.
+- An ACL field with permission filter type `userIds` or `groupIds` can hold at most 1000 values.
 
 - An index can hold at most five unique values among fields of type `rbacScope` on all documents. There's no limit on the number of documents that share the same value of `rbacScope`.
 

@@ -1,21 +1,21 @@
 ---
 title: Search index overview
 titleSuffix: Azure AI Search
-description: Explains what is a search index in Azure AI Search and describes content, construction, physical expression, and the index schema.
+description: Explains index content, construction, physical expression, and schema.
 manager: nitinme
 author: HeidiSteen
 ms.author: heidist
 ms.service: azure-ai-search
 ms.custom:
   - ignite-2023
 ms.topic: concept-article
-ms.date: 06/20/2025
+ms.date: 01/27/2026
 ms.update-cycle: 365-days
 ---
 
 # Search indexes in Azure AI Search
 
-In Azure AI Search, a *search index* is your searchable content, available to the search engine for indexing, agentic search, full-text search, vector search, hybrid search, and filtered queries. An index is defined by a schema and saved to the search service, with data ingestion following as a second step. Indexed content exists within your search service, apart from your primary external data stores, which is necessary for the millisecond response times expected in modern search applications. Except for indexer-driven indexing scenarios, the search service never connects to or queries your external source data.
+In Azure AI Search, a *search index* is your searchable content on a search service, available to the local search engine for indexing, agentic retrieval, full-text search, vector search, hybrid search, and filtered queries. An index is defined by a schema that's saved to your search service, with data ingestion following as a second step. Indexed content exists on your search service, apart from your primary external data stores, which is necessary for the millisecond response times expected in modern search applications. Except for remote agentic retrieval and indexer-driven indexing scenarios, the search service never connects to or queries your external source data.
 
 This article covers the key concepts for creating and managing a search index, including:
 
@@ -24,18 +24,22 @@ This article covers the key concepts for creating and managing a search index, i
 + Basic operations
 
 > [!TIP]
-> Want to get started right away? See [Create a search index](search-how-to-create-search-index.md).
+> **Quick summary:**
+> - An index stores your searchable content
+> - Schema defines fields and their behaviors
+> - Documents are individual searchable items (similar to rows in a database)
+> - [Jump to creating an index →](search-how-to-create-search-index.md)
 
 ## Schema of a search index
 
 In Azure AI Search, indexes contain *search documents*. Conceptually, a document is a single unit of searchable data in your index. For example, a retailer might have a document for each product, a university might have a document for each class, a travel site might have a document for each hotel and destination, and so forth. Mapping these concepts to more familiar database equivalents: a *search index* equates to a *table*, and *documents* are roughly equivalent to *rows* in a table.
 
-The structure of a document is determined by the *index schema*, as illustrated in the following example. The "fields" collection is typically the largest part of an index, where each field is named, assigned a [data type](/rest/api/searchservice/Supported-data-types), and attributed with allowable behaviors that determine how it's used.
+Here's an example of what an index schema looks like.
 
 ```json
 {
   "name": "name_of_index, unique across the service",
-  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees."
+  "description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees.",
   "fields": [
     {
       "name": "name_of_field",
@@ -44,15 +48,15 @@ The structure of a document is determined by the *index schema*, as illustrated
       "filterable": true (default) | false,
       "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
       "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
-      "key": true | false (default, only Edm.String fields can be keys),
+      "key": true (only Edm.String fields can be keys) | false (default where applicable),
       "retrievable": true (default) | false,
-      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
-      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
-      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
-      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
-      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
-      "dimensions": "number of dimensions used by an embedding models", (applies to vector fields only, of type Collection(Edm.Single))
-      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
+      "analyzer": "name_of_analyzer_for_search_and_indexing" (only if 'searchAnalyzer' and 'indexAnalyzer' are not set),
+      "searchAnalyzer": "name_of_search_analyzer" (only if 'indexAnalyzer' is set and 'analyzer' is not set),
+      "indexAnalyzer": "name_of_indexing_analyzer" (only if 'searchAnalyzer' is set and 'analyzer' is not set),
+      "normalizer":  "name_of_normalizer" (applies to fields that are filterable),
+      "synonymMaps": "name_of_synonym_map" (optional, only one synonym map per field is currently supported),
+      "dimensions": "number of dimensions used by an embedding models" (applies to vector fields of type Collection(Edm.Single)),
+      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations but a field can use just one)
     }
   ],
   "suggesters": [ ],
@@ -69,6 +73,8 @@ The structure of a document is determined by the *index schema*, as illustrated
 }
 ```
 
+The `fields` collection is typically the largest part. Each field has a name, [data type](/rest/api/searchservice/Supported-data-types), and attributes that determine usage at query time.
+
 Other elements are collapsed for brevity, but the following links provide details: 
 
 + [suggesters](index-add-suggesters.md) support type-ahead queries like autocomplete.
@@ -81,7 +87,7 @@ Other elements are collapsed for brevity, but the following links provide detail
 
 ### Field definitions
 
-A search document is defined by the "fields" collection in the body of [Create Index request](/rest/api/searchservice/indexes/create). You need fields for document identification (keys), storing searchable text, and fields for supporting filters, facets, and sorting. You might also need fields for data that a user never sees. For example, you might want fields for profit margins or marketing promotions that you can use in a scoring profile to boost a search score.
+A search document is defined by the `fields` collection in the body of [Create Index request](/rest/api/searchservice/indexes/create). You need fields for document identification (keys), storing searchable text, and fields for supporting filters, facets, and sorting. You might also need fields for data that a user never sees. For example, you might want fields for profit margins or marketing promotions that you can use in a [scoring profile](index-add-scoring-profiles.md) to boost a search score.
 
 If incoming data is hierarchical in nature, you can represent it within an index as a [complex type](search-howto-complex-data-types.md), used for nested structures. The sample data set, [Hotels](https://github.com/Azure-Samples/azure-search-sample-data/tree/main/hotels), illustrates complex types using an Address (contains multiple subfields) that has a one-to-one relationship with each hotel, and a Rooms complex collection, where multiple rooms are associated with each hotel. 
 
@@ -91,21 +97,22 @@ If incoming data is hierarchical in nature, you can represent it within an index
 
 Field attributes determine how a field is used, such as whether it's used in full text search, faceted navigation, sort operations, and so forth. 
 
-String fields are often marked as "searchable" and "retrievable". Fields used to narrow search results include "sortable", "filterable", and "facetable".
++ String fields are often marked as `searchable` and `retrievable`. 
++ Fields used to narrow or order search results are marked as `sortable`, `filterable`, and `facetable`.
 
 |Attribute|Description|  
 |---------------|-----------------|  
-|"searchable" |Full-text or vector searchable. Text fields are subject to lexical analysis such as word-breaking during indexing. If you set a searchable field to a value like "sunny day", internally it's split into the individual tokens "sunny" and "day". For details, see [How full text search works](search-lucene-query-architecture.md).|  
-|"filterable" |Referenced in $filter queries. Filterable fields of type `Edm.String` or `Collection(Edm.String)` don't undergo word-breaking, so comparisons are for exact matches only. For example, if you set such a field f to "sunny day", `$filter=f eq 'sunny'` finds no matches, but `$filter=f eq 'sunny day'` will. |  
-|"sortable" |By default the system sorts results by score, but you can configure sort based on fields in the documents. Fields of type `Collection(Edm.String)` can't be "sortable". |  
-|"facetable" |Typically used in a presentation of search results that includes a hit count by category (for example, hotels in a specific city). This option can't be used with fields of type `Edm.GeographyPoint`. Fields of type `Edm.String` that are filterable, "sortable", or "facetable" can be at most 32 kilobytes in length. For details, see [Create Index (REST API)](/rest/api/searchservice/indexes/create).|  
-|"key" |Unique identifier for documents within the index. Exactly one field must be chosen as the key field and it must be of type `Edm.String`.|  
-|"retrievable" |Determines whether the field can be returned in a search result. This is useful when you want to use a field (such as *profit margin*) as a filter, sorting, or scoring mechanism, but don't want the field to be visible to the end user. This attribute must be `true` for `key` fields.|  
+|searchable |Full-text or vector searchable. Text fields are subject to lexical analysis such as word-breaking during indexing. For details, see [How full text search works](search-lucene-query-architecture.md).|  
+|filterable |Referenced in $filter queries. Filterable fields of type `Edm.String` or `Collection(Edm.String)` don't undergo word-breaking, so comparisons are for exact matches only. Given the string "sunny day", `$filter=f eq 'sunny'` finds no matches, but `$filter=f eq 'sunny day'` succeeds. |  
+|sortable |By default the system sorts by a search score, but you can configure an explicit sort based on fields in the documents. Fields of type `Collection(Edm.String)` can't be sortable. |  
+|facetable |Typically used in a presentation of search results that includes a hit count by category (for example, hotels in a specific city). This option can't be used with fields of type `Edm.GeographyPoint`. Fields of type `Edm.String` that are filterable, sortable, or facetable can be at most 32 kilobytes in length. For details, see [Create Index (REST API)](/rest/api/searchservice/indexes/create).|  
+|key |Unique identifier for documents within the index. Exactly one field must be chosen as the key field and it must be of type `Edm.String`.|  
+|retrievable |Determines whether the field can be returned in a search result. This is useful when you want to use a field (such as *profit margin*) as a filter, sorting, or scoring mechanism, but don't want the field to be visible to the end user. This attribute must be `true` for `key` fields.|  
 
 Although you can add new fields at any time, existing field definitions are locked in for the lifetime of the index. For this reason, developers typically use the Azure portal for creating simple indexes, testing ideas, or using the Azure portal pages to look up a setting. Frequent iteration over an index design is more efficient if you follow a code-based approach so that you can rebuild the index easily.
 
 > [!NOTE]
-> The APIs you use to build an index have varying default behaviors. For the [REST APIs](/rest/api/searchservice/indexes/create), most attributes are enabled by default (for example, "searchable" and "retrievable" are true for string fields) and you often only need to set them if you want to turn them off. For the .NET SDK, the opposite is true. On any property you do not explicitly set, the default is to disable the corresponding search behavior unless you specifically enable it.
+> The APIs you use to build an index have varying default behaviors. For the [REST APIs](/rest/api/searchservice/indexes/create), most attributes are enabled by default (for example, searchable and retrievable are true for string fields) and you often only need to set them if you want to turn them off. For the .NET SDK, the opposite is true. On any property you don't explicitly set, the default is to disable the corresponding search behavior unless you specifically enable it.
 
 <a name="index-size"></a>
 
@@ -115,10 +122,13 @@ In Azure AI Search, the physical structure of an index is largely an internal im
 
 You can monitor index size on the **Search management > Indexes** page in the Azure portal. Alternatively, you can issue a [GET INDEX request](/rest/api/searchservice/indexes/get) against your search service or a [Service Statistics request](/rest/api/searchservice/get-service-statistics/get-service-statistics) to check the value of storage size.
 
+> [!NOTE]
+> If you're actively [deleting content](search-how-to-delete-documents.md), index storage and size are updated every few minutes. Deletion runs as a background process. Expect a small delay on metric updates.
+
 The size of an index is determined by the:
 
 + Quantity and composition of your documents.
-+ Attributes on individual fields: "retrievable" doesn't bloat your index, but "filterable", "sortable", "facetable" consume more storage for storing non-tokenized text.
++ Attributes on individual fields: retrievable doesn't bloat your index, but filterable, sortable, and facetable consume more storage for storing non-tokenized text.
 + Index configuration. Specifically, whether you include suggesters or specialized [analyzers](search-analyzers.md). If you use the edgeNgram tokenizer to store verbatim sequences of characters (`a, ab, abc, abcd`), the index is larger than if you use the standard analyzer.
 
 Document composition and quantity are determined by what you choose to import. Remember that a search index should only contain content that's useful for your search application. If source data includes binary fields, omit those fields unless you're using AI enrichment to crack and analyze the content to create text-searchable information.
@@ -157,12 +167,13 @@ All indexing and query requests target an index. Endpoints are usually one of th
 | `<your-service>.search.windows.net/indexes` | Targets the indexes collection. Used when creating, listing, or deleting an index. Admin rights are required for these operations and available through admin [API keys](search-security-api-keys.md) or a [Search Contributor role](search-security-rbac.md#built-in-roles-used-in-search). |
 | `<your-service>.search.windows.net/indexes/<your-index>/docs` | Targets the documents collection of a single index. Used when querying an index or data refresh. For queries, read rights are sufficient and available through query API keys or a data reader role. For data refresh, admin rights are required. |
 
-#### How to connect to Azure AI Search
+#### How to connect to an index
 
-1. [Start with the Azure portal](https://portal.azure.com). Azure subscribers, or the person who created the search service, can manage the search service in the Azure portal. An Azure subscription requires Contributor or above permissions to create or delete services. This permission level is sufficient for fully managing a search service in the Azure portal.
+1. [Start with the Azure portal](https://portal.azure.com) and your search service dashboard.
 
 1. Try other clients for programmatic access. We recommend the quickstarts for first steps:
 
+   + [Quickstart: Connect to a search service](search-get-started-rbac.md)
    + [Quickstart: REST](search-get-started-text.md)
    + [Quickstart: Full-text search](search-get-started-text.md)
    + [Quickstart: Agentic retrieval](search-get-started-agentic-retrieval.md)

@@ -8,7 +8,7 @@ ms.service: azure-ai-search
 ms.custom:
   - build-2024
 ms.topic: how-to
-ms.date: 11/21/2025
+ms.date: 01/28/2026
 ---
 
 # Use embedding models from the Microsoft Foundry model catalog for integrated vectorization
@@ -41,11 +41,11 @@ Supported embedding models from the model catalog vary by usage method:
 
 ## Deploy an embedding model from the model catalog
 
-1. Follow [these instructions](/azure/ai-foundry/how-to/deploy-models-openai) to deploy a supported model to your project.
+1. Follow [these portal instructions](/azure/ai-foundry/how-to/deploy-models-openai) to deploy a supported model to your project.
 
 1. Make a note of the target URI, key, and model name. You need these values for the vectorizer definition in a search index and for the skillset that calls the model endpoints during indexing.
 
-    If you prefer [token authentication](#connect-using-token-authentication) to key-based authentication, you only need to copy the URI and model name. However, make a note of the region to which the model is deployed.
+    If you prefer [token authentication](#connect-using-token-authentication) to key-based authentication, you only need to copy the model name. However, make a note of the region to which the model is deployed.
 
 1. Configure a search index and indexer to use the deployed model.
 
@@ -81,6 +81,67 @@ Supported embedding models from the model catalog vary by usage method:
    + To use the model as a vectorizer at query time, see [Configure a vectorizer](vector-search-how-to-configure-vectorizer.md). Be sure to use the [Microsoft Foundry model catalog vectorizer](vector-search-vectorizer-azure-machine-learning-ai-studio-catalog.md) for this step.
 -->
 
+## Deploy an embedding model as a serverless deployment
+
+The AML skill and Microsoft Foundry model catalog vectorizer only accept serverless deployments of Cohere embedding models. Serverless deployments via the Microsoft Foundry portal aren't supported for these models, so use the Azure CLI to create the deployment. For more information, see [Deploy models as serverless API deployments](/azure/ai-foundry/how-to/deploy-models-serverless).
+
+To create a Cohere serverless deployment:
+
+1. Install the Azure CLI with the `ml` extension.
+
+    ```azurecli
+    az extension add -n ml
+    ```
+
+1. Sign in to Azure and set your defaults.
+
+    ```azurecli
+    az login
+    az account set --subscription <subscription-id>
+    az configure --defaults workspace=<project-name> group=<resource-group>
+    ```
+
+1. Create a `subscribe.yaml` file to subscribe to the marketplace subscription for the model.
+
+    ```yaml
+    name: cohere-embed-v3-english-subscription
+    model_id: azureml://registries/azureml-cohere/models/Cohere-embed-v3-english
+    ```
+
+    For other supported models, replace the model ID with one of the following values.
+    
+    | Model | Model ID |
+    | ----- | -------- |
+    | Cohere-embed-v3-english | `azureml://registries/azureml-cohere/models/Cohere-embed-v3-english` |
+    | Cohere-embed-v3-multilingual | `azureml://registries/azureml-cohere/models/Cohere-embed-v3-multilingual` |
+    | Cohere-embed-v4 | `azureml://registries/azureml-cohere/models/Cohere-embed-v4` |
+
+1. Run the following command to create the subscription.
+
+    ```azurecli
+    az ml marketplace-subscription create --file subscribe.yaml
+    ```
+
+1. Create an `endpoint.yaml` file to create the serverless endpoint.
+
+    ```yaml
+    name: cohere-embed-v3-english-endpoint
+    model_id: azureml://registries/azureml-cohere/models/Cohere-embed-v3-english
+    ```
+
+1. Run the following command to create the endpoint.
+
+    ```azurecli
+    az ml serverless-endpoint create --file endpoint.yaml
+    ```
+
+1. For key-based authentication, get the endpoint URI and key for use in the skill or vectorizer.
+
+    ```azurecli
+    az ml serverless-endpoint show --name cohere-embed-v3-english-endpoint --query "scoring_uri"
+    az ml serverless-endpoint get-credentials --name cohere-embed-v3-english-endpoint
+    ```
+
 ## Sample AML skill payload
 
 When you deploy embedding models from the model catalog, you connect to them using the [AML skill](cognitive-search-aml-skill.md) in Azure AI Search for indexing workloads.

@@ -25,7 +25,7 @@ If you're using integrated vectorization to create the vector arrays, the skills
 
 + A [Microsoft Foundry hub-based project](/azure/ai-foundry/how-to/hub-create-projects) or an [AML workspace](../machine-learning/concept-workspace.md) for a custom model that you create.
 
-+ For hub-based projects only, a serverless deployment of a [supported model](#vectorizer-parameters) from the Microsoft Foundry model catalog. You can use an [ARM/Bicep template](https://github.com/Azure-Samples/azure-ai-search-multimodal-sample/blob/42b4d07f2dd9f7720fdc0b0788bf107bdac5eecb/infra/ai/modules/project.bicep#L37C1-L38C1) to provision the serverless deployment.
++ For hub-based projects only, a serverless deployment of a [supported model](#vectorizer-parameters) from the Microsoft Foundry model catalog. You can use [use the Azure CLI](vector-search-integrated-vectorization-ai-studio.md#deploy-an-embedding-model-as-a-serverless-deployment) to provision the serverless deployment.
 
 ## Vectorizer parameters