Agentforce Integration Steps: A Controlled First Release

An Agentforce integration should start with one task and a clear boundary: what the agent can read, what it can change and what happens when the connection fails. Turning on an agent doesn’t answer those questions.

This checklist takes an existing Salesforce integration from inventory to a controlled first release. It’s about delivery order, not choosing a new integration stack. If you’re still comparing APIs and MCP, start with integration patterns for existing orgs.

What should you define before building an action?

Write a short task description. For example: a verified customer asks for an order’s delivery status. The agent looks it up, returns the status and passes exceptions to support. Changing the order is out of scope.

Record the required inputs, permitted outputs and failure response. Identify who owns the source system and who can approve changes to the integration. Keep read and write capabilities separate so a lookup doesn’t quietly become an update operation later.

Which existing integration can you reuse?

Inventory the Flows, Apex callouts, External Services and middleware already connecting Salesforce to the target system. An agent can use custom actions backed by autolaunched flows or invocable Apex; an existing API may need that action layer to validate inputs and shape the response.

Use deterministic code or Flow for required sequencing rather than asking the model to improvise every step. If an external system already offers suitable MCP tools, evaluate those too. MCP adds tool discovery and invocation; it doesn’t remove authentication or your responsibility for the business operation.

The deliverable here is one chosen path, not a list of every possible connector.

Whose identity will execute the request?

Write down both the Salesforce execution identity and the external system identity. Don’t assume the person chatting is automatically the user every action runs as. The context depends on the agent type, channel and verification configuration.

For private service-agent actions, verify the customer and scope the data to that identity. An order number supplied in chat isn’t sufficient authorization to read an order. Salesforce’s custom-action security guidance explicitly separates the agent’s execution identity from the customer’s right to access a record.

For Apex callouts, use Named Credentials and External Credentials. The named credential defines the endpoint; the external credential defines authentication and maps principals to permissions. Keep secrets out of action descriptions, prompts and frontend code.

How do you define a safe action contract?

Give the action a specific name and description, and specify:

• Which inputs come from verified context and which can come from the conversation.
• Which records and fields the operation may access.
• Whether it reads data or changes it.
• What success, not-found, denied and unavailable responses look like.
• When confirmation or a handoff to a person is required.

Check Flow execution context and Apex database access modes. Current Apex database operations default to user mode from API version 67.0, but older code and explicit system-mode operations need review. A friendly action description isn’t an access-control mechanism.

What should you test before connecting a customer channel?

Build a sandbox test set around the contract, not just the wording of the response:

• A verified customer requests their own order.
• The same customer requests another customer’s order.
• Verification is missing or expired.
• The source system returns no result, times out or rejects access.
• A repeated request would repeat a write operation.
• A prompt injection attempt asks the agent to ignore its restrictions.

Check both the returned answer and any records changed. Use Agentforce Testing Center for repeatable agent tests, alongside tests of the underlying integration. Salesforce warns that agent tests can modify CRM data, so run them in a sandbox. Tests consume requests and credits; include them in the usage plan.

What belongs in the release and support plan?

Release the required credentials, permissions, action configuration and agent changes together through your normal controlled process. Verify access using the intended identities rather than an administrator account.

Start with a limited audience and a named support owner. Define how to disable the action, route work back to a person and investigate failures without exposing sensitive customer content in ad hoc logs. Monitor denied requests, external errors, latency and incorrect results separately; a successful API response doesn’t prove the agent answered the right question.

Expand only after the first task meets its acceptance criteria. Adding another system is another access and failure review, not merely another tool name.

FAQ

Must every integration use MCP?

No. Reuse a stable API or existing Flow/Apex integration when it fits. MCP is useful when an appropriate tool server exists or several clients need the capabilities.

Do agent permissions replace customer verification?

No. Private service-agent actions must check the verified customer’s entitlement to the data, as well as the execution identity’s platform access.

Is Data 360 required for every action?

Don’t assume it. An action using an existing Flow or Apex integration isn’t the same as a retrieval feature using Data 360 (formerly Data Cloud). Check the requirements of the features you select.

When should a write action be enabled?

After its authorization, confirmation, retry behavior and failure handling have been tested, with a clear owner and a way to stop it.

Sources: Custom-action security, Named Credentials, Apex access modes, agent testing.

Book an intro call below.