Claude + Salesforce Integration: CRM AI Automation Architecture

Integration Architecture Options

There are three architectural patterns for Claude Salesforce integration, each suited to different use cases and technical environments. Understanding which pattern fits your requirements determines the build complexity, maintenance overhead, and capability ceiling of your integration.

Pattern 1: MCP Server for Claude Cowork and Claude Code

The Model Context Protocol provides the cleanest path for teams using Claude Cowork or Claude Code. An MCP server exposes Salesforce as a set of tools — query_records, create_record, update_record, search_accounts — that Claude can invoke as part of multi-step workflows. A sales rep using Claude Cowork can ask "Summarise the last 6 months of activity for Acme Corp and draft a renewal pitch based on their deal history" and Claude will call the Salesforce MCP server to retrieve the account data, synthesise it, and generate the email — without the user needing to copy and paste anything from Salesforce.

Our MCP server development team builds production Salesforce MCP servers that handle authentication via OAuth 2.0 JWT flows, respect Salesforce field-level security, and expose only the objects and fields your use case requires. We've deployed this pattern for sales teams at financial services firms where the Salesforce data model is complex and security is non-negotiable.

Pattern 2: Middleware Integration Layer

For organisations building Claude-powered applications that need to read and write Salesforce data at scale, a dedicated middleware integration layer is the correct architecture. This typically involves a backend service (Node.js, Python, or a serverless function) that: receives events from Salesforce (via Platform Events or Outbound Messages), enriches or processes them with Claude, and writes results back to Salesforce via the REST API or Bulk API.

This pattern is appropriate for batch processing use cases: nightly account scoring, automated opportunity qualification, mass email personalisation, or data quality remediation across thousands of records.

Pattern 3: Apex Callouts for In-Org Processing

For organisations that need Claude processing to happen within Salesforce flows and triggers — without external middleware — Apex callouts provide a direct path. An Apex class makes a callout to the Claude API (or to your cloud provider's managed Claude endpoint), passes Salesforce record data as context, and processes the response within the Org. This keeps logic within Salesforce's declarative and programmatic layer, reducing external dependencies.

High-Value Claude Salesforce Use Cases

Before designing architecture, identify the highest-value use cases for your sales and service teams. These are the patterns we see delivering consistent, measurable ROI in production:

MCP Server Implementation for Salesforce

Building a Salesforce MCP server requires defining the tools Claude can invoke, implementing authentication, and deploying the server as a persistent endpoint that Claude Cowork or Claude Code can connect to.

Core Tool Definitions

from mcp.server import Server
from mcp.types import Tool
import simple_salesforce

app = Server("salesforce-mcp")

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="query_salesforce",
            description="Execute a SOQL query against Salesforce",
            inputSchema={
                "type": "object",
                "properties": {
                    "soql": {"type": "string",
                             "description": "The SOQL query to execute"}
                },
                "required": ["soql"]
            }
        ),
        Tool(
            name="get_account",
            description="Get account details including opportunities and contacts",
            inputSchema={
                "type": "object",
                "properties": {
                    "account_id": {"type": "string"},
                    "include_opportunities": {"type": "boolean"},
                    "include_contacts": {"type": "boolean"}
                },
                "required": ["account_id"]
            }
        ),
        Tool(
            name="update_record",
            description="Update a Salesforce record field",
            inputSchema={
                "type": "object",
                "properties": {
                    "object_type": {"type": "string"},
                    "record_id": {"type": "string"},
                    "fields": {"type": "object"}
                },
                "required": ["object_type", "record_id", "fields"]
            }
        )
    ]

Authentication via OAuth 2.0 JWT

For server-to-server integration (no user login flow), use the OAuth 2.0 JWT Bearer Token flow — the MCP server authenticates to Salesforce as a Connected App using a private key, without prompting users to log in. This is the correct pattern for background processes, middleware, and automated workflows.

Generate a certificate/key pair, upload the certificate to a Salesforce Connected App, and use the private key in your MCP server to sign JWT assertions. The MCP server exchanges the JWT for an access token, which is refreshed automatically before expiry. Store the private key in your secret management system (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) — never in code or environment variables committed to version control.

Apex Callout Pattern for In-Org Claude Integration

For teams that prefer to keep logic inside Salesforce, Apex callouts provide a direct integration path. The pattern is: Salesforce Flow or Trigger calls an Apex class, the class constructs a Claude API request with the record data as context, makes the callout, parses the response, and updates the record.

public class ClaudeOpportunityBriefing {

    @InvocableMethod(label='Generate Opportunity Briefing')
    public static List<String> generateBriefing(
        List<String> opportunityIds
    ) {
        List<String> results = new List<String>();

        for (String oppId : opportunityIds) {
            Opportunity opp = [
                SELECT Id, Name, Amount, StageName, CloseDate,
                       Account.Name, Account.Industry,
                       (SELECT Subject, ActivityDate, Description
                        FROM ActivityHistories ORDER BY ActivityDate DESC LIMIT 5)
                FROM Opportunity WHERE Id = :oppId
            ];

            String prompt = buildPrompt(opp);
            String briefing = callClaudeAPI(prompt);
            results.add(briefing);
        }
        return results;
    }

    private static String callClaudeAPI(String prompt) {
        HttpRequest req = new HttpRequest();
        // Use Named Credential for auth
        req.setEndpoint('callout:Claude_API/v1/messages');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setHeader('anthropic-version', '2023-06-01');

        Map<String, Object> body = new Map<String, Object>{
            'model' => 'claude-sonnet-4-6-20261001',
            'max_tokens' => 1024,
            'messages' => new List<Object>{
                new Map<String, Object>{
                    'role' => 'user', 'content' => prompt
                }
            }
        };

        req.setBody(JSON.serialize(body));
        HttpResponse res = new Http().send(req);

        Map<String, Object> response =
            (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
        // Extract text from response
        List<Object> content =
            (List<Object>) response.get('content');
        Map<String, Object> firstBlock =
            (Map<String, Object>) content[0];
        return (String) firstBlock.get('text');
    }
}

Configure a Named Credential in Salesforce Setup pointing to the Claude API endpoint (or your cloud provider's managed endpoint for Bedrock/Vertex/Azure). The Named Credential stores the API key securely and substitutes the callout: prefix automatically. Never hardcode the API key in Apex.

Data Security and Salesforce Field-Level Security

Any Claude Salesforce integration must respect Salesforce's existing field-level security (FLS) model. The connected user or service account's FLS permissions determine which fields are readable and writable. Ensure your integration's service account has only the permissions required for its specific use case — don't use a System Administrator profile for integrations. Create a dedicated integration profile with the minimum FLS required.

For MCP server integrations, implement field allowlisting at the MCP tool layer — don't expose raw SOQL query capability that could return any field. Instead, define specific tools that return specific field sets, mapping to your security requirements. This provides defence in depth: even if Claude was instructed to retrieve sensitive fields, the MCP tool implementation enforces the boundary.

Review your Salesforce data classification before connecting Claude. Fields containing PII, financial data, or regulated information should be explicitly excluded from Claude context unless the use case requires them and data handling agreements with Anthropic have been reviewed. Our Claude security and governance service covers the data classification and handling framework for CRM integrations.

Production Architecture Patterns

Production Claude Salesforce integrations need more than a working integration — they need error handling, retry logic, rate limit management, and observability. The Claude API has rate limits measured in requests per minute and tokens per minute. At enterprise scale, multiple Salesforce flows or triggers firing simultaneously can exhaust rate limits and cause failures that are invisible to users unless you've built explicit handling.

Implement a queuing layer between Salesforce and Claude for high-volume workflows. Rather than making direct synchronous callouts from Salesforce flows, enqueue jobs to an AWS SQS queue, Google Pub/Sub topic, or Azure Service Bus. A worker service consumes jobs from the queue, calls Claude with appropriate throttling, and writes results back to Salesforce via the REST API. This architecture absorbs Salesforce event bursts, handles Claude rate limits gracefully, and makes failures visible in your operations tooling.

For lower-volume, user-initiated use cases (briefing generation, email drafting), synchronous callouts are acceptable — users expect a 2–5 second wait for AI-generated content. Monitor callout latency with Salesforce Debug Logs and Apex CPU time to ensure you're within Salesforce's governor limits. If latency spikes, the async queue pattern becomes necessary even for interactive use cases.

For the broader picture of Claude CRM integration alongside HubSpot, ServiceNow, and SAP, see our related articles: MCP Servers for Salesforce, Jira, Slack & HubSpot and the Claude AI agent tutorial for end-to-end workflow automation examples.

Continue Reading