Azure OpenAI in Salesforce: AI That Stays in Your Own Azure Tenant

Many companies are ready to use generative AI in Salesforce, but their security or data protection team has one condition: AI processing must stay inside the company's own cloud tenant, in a region it chose, under a contract it already has. For organisations that run on Microsoft, the answer is usually Azure OpenAI.

This article explains how Azure OpenAI works as the AI provider for Salesforce with AI Engine, what the setup looks like, and the one trade-off you need to know about before go-live.

Why Azure OpenAI instead of calling OpenAI directly

OpenAI, Anthropic and Azure OpenAI can all power the same CRM features. What differs is who processes your data, where, and under which agreement:

If your procurement and legal teams have already approved Microsoft as a processor, Azure OpenAI often avoids a new vendor review. Requests go to the Azure OpenAI resource you created, in the region you picked, and are billed through your Azure subscription.

How the connection works

AI Engine is a managed package that runs inside Salesforce. It calls your AI provider through a Named Credential, Salesforce's built-in mechanism for authenticated outbound calls. For Azure OpenAI, the setup has four parts:

1. An External Credential that holds your Azure OpenAI key in an api-key header. The key stays in your org; it is not part of the package configuration and is not sent to Cloud Connected.
2. A Named Credential pointing at https://YOUR_RESOURCE.openai.azure.com, with CloudConnected added to its allowed namespaces for callouts.
3. Access to the credential for everyone who uses AI Engine, through a permission set.
4. The Org Profile in AI Engine: choose Azure OpenAI as the provider, enter the Named Credential name, and type your deployment name as the model.

That last point trips people up. On Azure you do not pick "gpt-4o" from a list; you enter the name of the deployment you created in Azure, exactly as it appears there. AI Engine calls your deployment's chat completions endpoint directly. The step-by-step guide is in Connect your AI provider.

The same features, with one exception

With Azure OpenAI you get the same features as with the other providers: plain-language questions about your CRM data, record actions, meeting briefs, AI scoring with written reasons, email drafts and analysis, PDF documents and Magic Snap (image input works on all three providers).

The exception is web search. Azure OpenAI does not offer the web search tool that AI Engine uses for features such as Web Check, Company News, company research in the chat, web search in Meet Prep and Verify Company On The Web in scoring. In an Azure-configured org, these searches are sent to OpenAI instead, through a separate Named Credential that must be named exactly OpenAI.

You have two clean choices:

• Keep everything in Azure. Do not create the OpenAI Named Credential, keep web search off in Meet Prep and scoring, and ask users not to use the web features. Without that credential, web searches simply fail and nothing is sent to OpenAI.
• Allow web search. Create the OpenAI credential. Web searches and their subjects, typically company names, then go to OpenAI under your OpenAI account, while everything else stays on Azure.

Make this decision explicitly and write it down. It is the question a data protection officer will ask. See Choosing a provider for compliance.

What the provider receives, whichever you choose

Choosing Azure decides where the data goes. AI Engine's own controls decide what goes there, and they are the same for every provider:

• The user's own Salesforce permissions. Queries run with the user's sharing rules, object permissions and field-level security.
• An admin allowlist. The AI can only query the objects and fields an admin enabled.
• PII masking. By default, values such as email addresses and phone numbers are replaced with placeholders before a request is sent, and put back in the answer.
• No stored conversations. AI Engine does not store the full text of prompts and answers. The activity log keeps usage metadata, plus a short error message when a call fails.

Choosing deployments: main and fast

AI Engine has two model settings. The main model handles chat, record actions, Meet Prep, scoring, PDFs and Magic Snap. The fast model handles internal steps. On Azure you can leave the fast model blank to use your main deployment, or enter a second, cheaper deployment. Because web search on Azure goes through OpenAI, the Azure fast model only affects Help mode.

After changing a deployment, test the features that return structured results, such as Meet Prep, AI Score and answers shown as cards, before users rely on them. Models differ in how reliably they return structured output.

Switching later is a setting, not a project

The provider is a setting in the Org Profile, not a reinstallation. Many teams start on the provider they already have an account with and move later. Some keep a second provider's credentials set up and tested so they can switch by hand during an outage or a policy change.

Summary

• Azure OpenAI keeps AI processing in your own Azure resource and region, under your Microsoft agreement.
• Setup is a Named Credential plus your deployment name in the AI Engine Org Profile.
• Web search is the one feature that does not run on Azure. Decide whether to allow it through OpenAI or leave it off.
• AI Engine applies the same permissions, allowlist and PII masking whichever provider you use.

Want to see it on your own Salesforce data? AI Engine installs from a managed package and works with your own Azure OpenAI deployment.