Bring Your Own LLM: Register an External Model in Einstein Studio

The scenario

Helix Pharma runs clinical-trial recruitment on Salesforce. The medical affairs team wants AI drafts of investigator outreach emails — but pharma compliance killed the first proposal in one meeting: model traffic must run on the company's existing Azure OpenAI enterprise agreement (negotiated retention, EU region, committed pricing), not on a new provider relationship.

That constraint rules out the plain native Models API path, which serves Salesforce-managed models under Salesforce's provider agreements. But it does not mean writing raw callouts and rebuilding masking and audit by hand. The middle path is BYO LLM: register the company's own Azure OpenAI deployment in Einstein Studio (Model Builder), and Salesforce treats it as a first-class model — usable from Prompt Builder, Agentforce and the Models API, with the Einstein Trust Layer in front of every request.

For beginners: Einstein Studio is the model management workspace inside Data 360 / Einstein setup. Its generative AI side ("Model Builder") is where you configure foundation models — including connecting external ones on supported providers: Azure OpenAI, OpenAI, Amazon Bedrock and Google Vertex AI. If you chose your path with the decision guide (Part 1), this is Path 2.

Step 1 — Prepare the provider side

Everything Salesforce needs comes from your provider console. For Helix's Azure OpenAI deployment that means:

• Endpoint URL — the base URL of the Azure OpenAI resource (their EU-region instance).
• Deployment name — Azure serves models per named deployment; Helix's fine-tuned outreach model is deployed as helix-outreach-v2.
• API key — from the Azure resource. Treat it like a password: it goes into Model Builder's credential fields, never into Apex, custom settings or code.
• API version — Azure OpenAI requests carry an API version parameter; note the one your deployment supports.

Bedrock and Vertex AI differ in auth details (IAM-style credentials instead of a flat key) but the shape is the same: region, model identifier, credentials.

Step 2 — Register the model in Einstein Studio

In Setup, with Einstein generative AI enabled:

1. Open Einstein Studio and go to the generative models area.
2. Choose to add a foundation model and pick the connection type — Helix selects Azure OpenAI.
3. Enter the endpoint, deployment name, API version and key from Step 1. Model Builder validates the connection with a live test call.
4. Name the configuration. The name matters: it generates the API name your code will reference — Helix's becomes Helix_Outreach_Model.
5. Test it in the playground: send a few real prompts, compare output against the same prompts run in the provider's own console. Same model, same answers — if not, you're pointed at the wrong deployment.

That's the whole registration. No Named Credential, no Apex callout plumbing, no remote site settings — Model Builder owns the connection and the secret.

Step 3 — Call it from Apex

Here's the payoff: the Apex is identical to the native path — only the model name changes. Helix's email-draft service:

public with sharing class OutreachDraftService {

    // Configured model API names are referenced as
    // 'sfdc_ai__<YourConfiguredModelApiName>' — check the model's
    // detail page in Einstein Studio for the exact value.
    private static final String MODEL = 'sfdc_ai__Helix_Outreach_Model';

    public static String draftOutreach(Id contactId, String trialCode) {
        Contact inv = [SELECT Name, Title,
                              Account.Name, Account.BillingCountry
                       FROM Contact WHERE Id = :contactId
                       WITH USER_MODE];

        aiplatform.ModelsAPI.createGenerations_Request request =
            new aiplatform.ModelsAPI.createGenerations_Request();
        request.modelName = MODEL;

        aiplatform.ModelsAPI_GenerationRequest body =
            new aiplatform.ModelsAPI_GenerationRequest();
        body.prompt =
            'Draft a short, formal outreach email inviting this ' +
            'investigator to discuss trial ' + trialCode + '. ' +
            'Use ONLY the details below. Do not promise outcomes ' +
            'or mention compensation.\n\n' +
            'Investigator: ' + inv.Name + ', ' + inv.Title + '\n' +
            'Institution: ' + inv.Account.Name +
            ' (' + inv.Account.BillingCountry + ')';
        request.body = body;

        aiplatform.ModelsAPI.createGenerations_Response res =
            new aiplatform.ModelsAPI().createGenerations(request);

        return res.Code200.generation.generatedText;
    }
}

Compare this with the summarizer in the Models API post — same namespace, same request classes, same response handling. Which means:

• Everything built on the Models API keeps working. Swap the model name and an existing prompt template, agent action or Apex service now runs on your own model. Migration is a constant, not a rewrite.
• The trust layer applies unchanged — data masking before the request leaves, toxicity scoring, and the audit trail compliance asked for. Your model, Salesforce's guardrails.
• Prompt Builder and Agentforce see it too: registered models appear in the model pickers, so admins can select Helix's model in prompt templates without any code.

What BYO LLM doesn't solve

Honest limits, so you pick this path for the right reasons:

• Provider list is fixed. A model self-hosted on your own GPUs, or on a provider Model Builder has no connection type for, can't be registered. That's the genuine case for the direct callout path (Part 3).
• Request shape is the platform's. You get the Models API surface — generations, chat, embeddings. Exotic provider-specific parameters or response streaming into a custom UI are not what this path is for.
• Grounding is still your job. The model only knows what the prompt carries. Part 4 covers building CRM context safely, and the platform's native options.

Sources: Bring Your Own Large Language Model — Salesforce Help · AI Models (Einstein Studio) — developer guide · Supported Models · Access Models API with Apex