Salesforce is becoming a capability provider. DataInbox should govern the connection.

Salesforce has made an architectural move that matters beyond CRM. Its Headless Toolkit exposes platform capabilities through MCP servers, APIs, plug-ins, skills and developer tooling. The practical result is that an external AI client no longer needs a bespoke integration for every Salesforce operation.

Read the Salesforce AIforce announcement

Salesforce presents this as a way to bring Customer 360 and Agentforce into interfaces such as Claude, ChatGPT and Cursor. Our architectural inference is broader: Salesforce can become a capability provider beneath DataInbox while DataInbox remains responsible for state, authority, rules and evidence.

The real question is not whether an agent can call Salesforce

MCP solves an important technical problem: capability discovery and invocation. It can tell an authenticated client which Salesforce tools exist and how to call them. It does not decide whether a particular agent should use a tool for this customer, purpose or business situation.

A direct connection between an AI assistant and Salesforce therefore provides access, but not a complete operating model. The organisation still needs answers to questions such as:

• Which agent, person or system initiated the operation, and for which declared purpose?
• Which current business state and minimum necessary context may be shared?
• Which Salesforce capability is eligible under company policy?
• Must a person approve the proposed action before it changes a record or starts a Flow?
• Does the result satisfy the expected contract, and what happens when it does not?
• Which evidence must remain available for operations, security, compliance and audit?

This is where DataInbox adds a different layer. DataInbox can host company agents inside a governed Agent Runtime and can also govern external agents built with OpenAI, Claude, local models or specialist frameworks. In both cases, an agent receives a bounded task, permitted context and an approved set of MCP or API capabilities instead of general CRM access.

The runtime evaluates identity, purpose, current state, policy and authority before a tool call. It can allow, warn, require approval or block. After execution, DataInbox validates the result, records the decision and outcome, and turns them into the next governed business message.

Explore the DataInbox Agent Runtime

What Salesforce now exposes

The important development is not one product integration. It is the combination of several reusable surfaces:

• Hosted MCP servers for Salesforce records, platform services, analytics and custom tools.
• OAuth 2.0 authentication through a Salesforce External Client App, including PKCE for compatible clients.
• An API Catalog Connect REST API for discovering APIs and MCP servers registered in an organisation, inspecting versions and operations, and managing external MCP servers and their allowlisted tools.
• An open Salesforce skills library for Apex, Flow, SOQL, Lightning Web Components, objects, permissions and related development workflows.
• Salesforce CLI and direct APIs for deterministic operations or capabilities not exposed through the selected MCP server.

Read the Salesforce Hosted MCP setup guide

Explore the API Catalog Connect REST API

Explore the open Salesforce skills library

The open skills library is especially relevant because Salesforce says it follows the open Agent Skills specification and works with Codex, Claude Code, Cursor and other compatible tools. These are not capabilities that DataInbox needs to rewrite from scratch.

Salesforce's own development plug-in also demonstrates a useful resolution pattern: use a validated skill first, fall back to Salesforce CLI, and use Salesforce MCP or direct platform access where appropriate. The exact order is an implementation choice, but the separation between instructions, deterministic tooling and discoverable capabilities is the important part.

See the Salesforce Development plug-in architecture

Do not copy the 37 Claude sales skills blindly

Salesforce in Claude launched in beta with 37 prebuilt sales skills covering activities from prospecting to pipeline hygiene. Those skills are a product-specific Salesforce and Anthropic experience. They should not be confused with the broader open development skills library.

The useful target for DataInbox is not a verbatim copy of proprietary prompts or interface behaviour. It is the underlying business capability.

For example, prepare a renewal can be represented as a governed process:

1. Discover which Salesforce capabilities are available to the authenticated user.
2. Retrieve the permitted account, opportunity, activity and contract context.
3. Apply DataInbox rules, purpose restrictions and company-specific context.
4. Ask an approved model to reason over the resulting projection.
5. Validate the proposed result and request approval when policy requires it.
6. Execute the permitted Salesforce action and store the result as evidence.

That process can be performed with Claude, OpenAI or another eligible model. The durable business contract does not belong to the model provider.

Digital sovereignty means owning the operating contract

Digital sovereignty does not mean isolating the company or rebuilding Salesforce on-premise. It means retaining the practical ability to choose where data and the runtime live, which model or provider may participate, what context may cross a boundary, and which rules remain enforceable when technology changes.

If the policy, prompts, tool selection and process state are embedded in one assistant plug-in, changing the AI provider can mean rebuilding the operation. When DataInbox owns the business message, policy, capability contract and evidence trail, the intelligence becomes replaceable. Salesforce can remain the system of record, an approved model can perform the reasoning, and DataInbox can keep the authority boundary stable.

That independence matters for more than procurement. It lets the organisation:

• Select different approved models by sensitivity, geography, quality, capacity or cost.
• Share only the context required for a specific task instead of opening the entire CRM.
• Replace an assistant, model or hosting provider without redefining the business process.
• Keep company rules, approvals and decision evidence available outside any one vendor conversation.
• Combine Salesforce with AFAS, SAP, Microsoft, banking or other capabilities under the same operating contract.

Read how DataInbox approaches digital sovereignty

AI compliance must exist at execution time

AI compliance cannot rely only on policy documents or a retrospective log. An agent needs a live decision before it reads customer data, changes an opportunity, sends a proposal or invokes a Salesforce Flow.

DataInbox makes relevant controls operational around every call. Before execution it can resolve identity, purpose, permissions, risk conditions, tool eligibility and human approval. After execution it can preserve the selected capability, input contract, policy and configuration version, model or agent identity, approval, result, exception and resulting business state as structured evidence.

This does not automatically make every AI deployment compliant. It creates the runtime controls and evidence an organisation needs to demonstrate how its own requirements were applied. The same evidence can support internal review and existing GRC, security and audit processes.

Explore DataInbox AI agent governance

Salesforce should be a Companion, not a one-off integration

A Salesforce Companion can expose six things to the DataInbox runtime:

• Authentication through OAuth and an External Client App.
• Capability discovery through Salesforce MCP, the API Catalog and installed skills.
• Schemas for standard and custom Salesforce objects.
• Read and write operations for accounts, contacts, opportunities, cases, quotes, orders and custom objects.
• Existing Salesforce automation such as Flows, Apex actions and REST endpoints.
• Events and results that return to DataInbox as governed business messages.

DataInbox then supplies the control plane around those capabilities:

• Rules and validations.
• Permissions and purpose limitations.
• Human approval paths.
• Model and provider eligibility.
• Evidence, lineage and audit.
• Current cross-system business state.

This keeps the architectural boundary clear. Salesforce owns Salesforce data, logic and security. DataInbox owns the company-level decision about when a capability may be used, with which context, and what must happen before and after the call.

Reuse the Salesforce logic that already exists

Salesforce Hosted MCP can expose more than raw record operations. Salesforce documents support for custom tools backed by autolaunched Flows, Apex Invocable Actions, Aura-enabled methods, Apex REST endpoints and selected API Catalog endpoints. Agentforce agents can also be published as MCP tools, while Prompt Builder templates can be exposed as MCP tools or prompts depending on the configuration and client support.

See the Salesforce Hosted MCP capability reference

See how Salesforce Flows can become MCP tools

That means DataInbox does not need to rebuild an existing renewal Flow merely to make it available to an agent. A governed sequence can look like this:

1. DataInbox receives a renewal event.
2. Policy and permissions are checked against current business state.
3. DataInbox invokes the approved Salesforce MCP tool.
4. Salesforce executes the existing Flow or Apex logic in the authenticated user's context.
5. The result returns as a business message.
6. DataInbox stores the outcome, evidence and any required follow-up.

The agent receives a narrow, meaningful capability instead of broad access to a CRM.

Build the generic Companion runtime first

Salesforce is a strong first implementation, but it should not define the DataInbox contract. The same runtime should support AFAS, SAP, Microsoft, Shopify, banks, telecom providers, OCR services and any future MCP or API provider.

Every Companion may contribute APIs, MCP tools, skills, schemas, events, actions and authentication. DataInbox normalises those capabilities behind one governed registry and retains ownership of the cross-system business state.

That is the strategic opportunity in Salesforce's move. We do not need to replace Salesforce, and we do not need to reproduce every Salesforce feature. We can connect its capabilities to a company-owned control layer that decides what may happen and preserves evidence of what did.

Companions adapt capabilities. DataInbox governs the operation.

Explore the Salesforce Companion

Explore the DataInbox architecture