How to put language models safely inside Salesforce

Why the CRM is where LLMs earn their keep

Language models are good at reading a lot of messy context and producing a focused piece of text or a decision. A CRM is a pile of messy context attached to the people who matter most to the business: accounts, contacts, cases, emails, calls, opportunities. The match is obvious, which is why summarising a case, drafting a reply, preparing for a renewal call or suggesting a next step are the AI features sales and service teams use.

The CRM is also where the hardest governance questions live. Sharing rules, field-level security, personal data and audit trails exist for good reasons. An LLM integration that bypasses them is a data breach waiting for a prompt. The three patterns below differ mainly in how they handle that.

Three integration patterns

Pattern 1 uses native Agentforce and Einstein

Salesforce ships AI inside the platform. Agentforce lets you configure agents that work with your objects and flows; Einstein features cover summarisation, reply drafting, scoring and more. Salesforce describes a trust layer that applies controls such as data masking and grounding to prompts before they reach a model.

Strengths. Permissions, audit and data handling are the platform's problem. It is configuration rather than code, and fast to pilot for use cases the platform already supports.

Limits. You use the models and behaviours Salesforce offers. Knowledge outside the org has to be brought in. Usage-based pricing needs watching as volume grows. Complex multi-step logic can be awkward to express in configuration.

This is the right starting point for service and sales teams whose data is in the org. Our Agentforce and Einstein service covers set-up, grounding and evaluation.

Pattern 2 calls an external model from Apex or Flow

Apex can call an external model API; Flow can invoke an Apex action that does. The org stays the system of record and the user interface; the model is a service it calls for one step, such as classifying a case, extracting fields from an email or drafting a response from a template and the record's context.

Strengths. You can use any model, including a private deployment, and you control the prompt and the output format. It fits into existing automation, and the data sent can be minimised field by field.

Limits. Platform callout limits and timeouts shape what is feasible synchronously. You own the prompt, the evaluation, the error handling and the retries. Knowledge retrieval has to live on the AI side.

This is the pattern for a specific, well-defined step in a process, built by a team comfortable with Apex and LWC. It is often how an existing automation gets a language model inside it without changing anything else.

Pattern 3 gives an external agent MCP or API access

Here the intelligence lives outside the org. An assistant or agent, perhaps one your staff already use, reaches into Salesforce through an MCP server or a scoped API integration to read records, search cases and, with approval, write back. The agent may combine Salesforce data with documents, email and other systems in one task.

Strengths. One assistant serves many systems, with any model and rich retrieval over knowledge outside the org. The MCP server is reusable by every client that supports the protocol, as explained in MCP explained.

Limits. The agent must act as the user, or as a deliberately scoped integration user, or it bypasses sharing. Writes need an approval step. You are responsible for the full security model, as set out in the LLM security checklist.

This is the pattern for cross-system work: meeting preparation that draws on CRM, email and documents, or a sales copilot that lives where the rep already works. Our Salesforce integrations team builds the connector side.

Choosing a pattern

Most organisations end up with pattern 1 for the common cases and one of the others for the specific ones. A Salesforce AI roadmap is largely the exercise of sorting use cases into these columns.

Data governance across all three

Whatever the pattern, four rules hold. First, the model sees only what the user may see: sharing rules and field-level security apply to every record retrieved, which means retrieval goes through the platform's API in the user's context, never through a warehouse copy. Second, send only the fields the task needs; a summarisation prompt does not need the account's bank details. Third, mask or omit personal data where the task allows, and use providers with no-training and defined-retention terms. Fourth, log what was sent, what came back and which user triggered it, so audit questions have answers.

If any of your use cases make or influence decisions about people, such as lead scoring that affects service levels or anything touching employment, check the EU AI Act classification before you build.

Use cases we recommend

• Case summarisation for service agents, on open or before escalation. It is measurable in handle time, reviewed by the agent and uses data already in the org. It is the usual first win, often via Service Cloud.
• Reply drafting grounded in knowledge articles and case history, always sent by a human.
• Account and opportunity briefs before calls: recent activity, open issues, contract terms, suggested talking points.
• Email and call extraction: pulling next steps, commitments and dates into fields that currently go unfilled.
• Next-best-action suggestions, shown as suggestions with reasons rather than silent automation.
• Knowledge answers for agents and, with care, customers, grounded in your own articles. See customer support AI.

Pitfalls

What matters most

• The CRM holds the context a model needs and the permissions it must respect.
• There are three patterns: native Agentforce and Einstein, an external model from Apex or Flow, and an external agent via MCP or API.
• Start native for in-org use cases; go external for specific models, outside knowledge or cross-system tasks.
• Retrieval always runs in the user's context through the platform API, never a replica.
• Send only the fields the task needs, mask personal data and log everything.
• Suggest before you write; keep a human on every consequential action.
• Case summarisation is the usual first win: measurable, reviewed and in-org.

Related services