Best Practices: Using Salesforce MCP Servers and Headless 360 with CentroBot

Overview

CentroBot allows users to interact with Salesforce directly from Microsoft Teams using natural language. When CentroBot is connected to Salesforce MCP servers and Salesforce Headless 360, it can provide users with a powerful headless Salesforce experience—allowing them to find information, answer questions, and perform Salesforce actions without opening Salesforce.

Salesforce Hosted MCP Servers provide a standardized, governed way for AI clients to interact with Salesforce data, automation, and platform capabilities. Headless 360 extends this model by providing a broad Salesforce capability surface through MCP.

This article outlines recommended practices for configuring and using Salesforce MCP with CentroBot.

Recommended Architecture

A typical architecture looks like this:

Microsoft Teams → CentroBot → Salesforce MCP / Headless 360 → Salesforce

In this model:

• Microsoft Teams is the user's conversational interface.

• CentroBot interprets the user's request and provides the conversational experience.

• Salesforce MCP exposes Salesforce capabilities as tools that CentroBot can invoke.

• Headless 360 can provide a broader set of Salesforce capabilities through a single MCP connection.

• Salesforce remains the system of record and enforces its existing security and permissions.

Salesforce describes Headless 360 as a way to make Salesforce capabilities available to MCP-aware agents without requiring a traditional Salesforce UI.

1. Start With the Smallest Toolset You Need

One of the most important recommendations is to avoid exposing every available Salesforce capability to CentroBot.

More tools do not necessarily mean a better AI experience. Salesforce recommends creating focused, persona-specific MCP servers because AI clients can have difficulty selecting the appropriate tool when presented with a very large tool surface.

For example, a sales-focused CentroBot configuration might expose:

• Find Accounts

• Find Contacts

• Query Opportunities

• Update Opportunities

• Create Tasks

• Add meeting notes

• Retrieve recent Opportunity activity

A service-focused configuration might instead expose:

• Find Cases

• Retrieve Case details

• Add Case Comments

• Update Case status

• Search Contacts

• Escalate Cases

Best practice: Build MCP configurations around the jobs users need to accomplish rather than exposing every Salesforce object and operation.

2. Use Headless 360 When You Need Broad Salesforce Capabilities

Headless 360 is particularly useful when CentroBot needs to support a broad range of Salesforce operations without creating and maintaining a large collection of individual MCP connections.

The Headless 360 MCP Server provides four tools backed by a growing library of Salesforce operations, allowing the available capabilities to expand without continually expanding the agent's tool surface.

Consider Headless 360 when users need to ask questions such as:

"What opportunities are closing this month?"

"Update the Acme opportunity to Negotiation."

"Create a follow-up task for Sarah after my meeting."

"What open cases does this customer have?"

"Summarize the recent activity on this account."

For highly specialized workflows, however, a focused custom MCP server or custom Salesforce Flow may provide better control.

3. Let Salesforce Permissions Remain the Source of Truth

CentroBot should not be used to create a second authorization model for Salesforce data.

Salesforce Hosted MCP Servers use the permissions of the authenticated Salesforce user. MCP operations respect Salesforce's existing object permissions, field-level security, and record-sharing rules.

This means:

User → CentroBot → MCP → Salesforce permissions

rather than:

User → CentroBot → separate permissions → Salesforce

This is important because a user should only be able to retrieve or modify Salesforce data that they are already authorized to access.

Recommended practice

Before enabling MCP for a group of CentroBot users:

1. Review the Salesforce permission sets assigned to those users.

2. Confirm the users have appropriate object and field access.

3. Verify record-level sharing is working as expected.

4. Test MCP operations using representative users.

5. Avoid granting broad permissions simply to make an AI workflow work.

Salesforce specifically recommends following the principle of least privilege when securing MCP access.

4. Prefer Read Operations Before Write Operations

When implementing a new CentroBot experience, start with read-only use cases.

For example:

Phase 1 — Read

• Find an Account

• Find an Opportunity

• Retrieve Case information

• Summarize recent activity

• Answer Salesforce questions

Phase 2 — Write

• Update Opportunity fields

• Create Tasks

• Add Case Comments

• Create records

• Execute Salesforce Flows

This makes it easier to validate the MCP connection, permissions, tool descriptions, and CentroBot experience before introducing actions that change Salesforce data.

5. Be Deliberate About Write and Destructive Actions

Natural-language interfaces introduce an important difference from traditional Salesforce UI interactions: the user describes an intent rather than explicitly navigating through a series of screens.

For example:

"Close the Acme opportunity."

The system needs to determine exactly which opportunity the user means and what Salesforce operation should be performed.

For write operations, CentroBot should therefore:

• Clearly identify the record being changed.

• Confirm ambiguous requests.

• Avoid guessing when multiple records match.

• Provide the resulting change to the user.

• Require confirmation where appropriate for consequential actions.

• Avoid destructive operations unless they are explicitly required.

Salesforce MCP tools support annotations such as readOnlyHint and destructiveHint to communicate how tools should be treated by MCP clients. Salesforce recommends accurately annotating custom tools, although annotations should be treated as guidance rather than a replacement for security controls.

6. Use Salesforce Flow for Complex Business Processes

MCP tools should expose capabilities that an AI can reason about independently.

If a process requires a specific sequence of steps, extensive business logic, or conditional processing, consider implementing that process as a Salesforce Flow and exposing the Flow through MCP rather than asking the AI to orchestrate every individual step.

For example, instead of exposing:

1. Create Case

2. Find Contact

3. Update Contact

4. Create Task

5. Send Notification

6. Update Case

consider creating a Salesforce Flow such as:

Create and Route Support Case

CentroBot can then invoke the business process as a single meaningful operation.

Salesforce recommends avoiding both extremely granular tools and overly broad tools that contain their own complex decision-making. The goal is a tool that represents a useful unit of work for an AI client.

7. Make Tool Descriptions Extremely Clear

AI agents rely heavily on tool names and descriptions when determining which capability to use.

A tool named:

Update Record

is much less useful than:

Update Opportunity Stage

with a description such as:

Updates the Stage field on an existing Salesforce Opportunity. Use this when the user explicitly requests a change to an Opportunity's sales stage.

Good tool descriptions should explain:

• What the tool does.

• When it should be used.

• What records it operates on.

• Important required inputs.

• Whether it changes Salesforce data.

• Any important limitations.

Salesforce specifically calls out clear tool names and descriptions as an important part of custom MCP server design.

8. Design for Ambiguity

Users interacting with CentroBot will often provide incomplete information.

For example:

"Update the Acme opportunity."

There may be multiple Acme opportunities.

CentroBot should not guess. Instead, it should ask for clarification:

"I found three Acme opportunities. Which one would you like me to update?"

Similarly:

"Add a task for John."

should identify the appropriate John before creating the task.

Best practice: When a Salesforce action could affect the wrong record, resolve the ambiguity before making the change.

9. Keep the User in the Loop

CentroBot should make it clear when it is:

• Retrieving Salesforce information

• Preparing an action

• Changing Salesforce data

• Unable to complete an operation

For example:

Before: "I found the Acme renewal opportunity. Would you like me to move it to Negotiation?"

After: "Done. The Acme renewal opportunity is now in the Negotiation stage."

This provides users with confidence that their natural-language request resulted in the intended Salesforce operation.

10. Test With Realistic User Permissions

Do not test MCP exclusively with a Salesforce administrator.

A Salesforce administrator may have access that ordinary users do not.

Test CentroBot using representative personas such as:

• Sales Rep

• Sales Manager

• Customer Support Agent

• RevOps User

• Salesforce Admin

Verify both positive and negative scenarios.

For example:

Sales Rep

"Show me my open opportunities."

Sales Rep

"Show me an opportunity I don't have access to."

Support Agent

"Update this case."

Support Agent

"Update an Opportunity."

The goal is to confirm that CentroBot behaves correctly within the user's actual Salesforce security context.

Salesforce recommends testing MCP permissions before production deployment and validating behavior for users with different access levels.

11. Avoid Using a Shared Salesforce Identity

For user-driven CentroBot experiences, avoid designing the MCP connection around a single Salesforce service or integration user.

Salesforce Hosted MCP Servers authenticate users individually, and MCP operations execute with the permissions of the user who authorized the connection. Salesforce explicitly describes using a shared principal or service account for all MCP sessions as an anti-pattern.

This is especially important for CentroBot because different Teams users may have significantly different Salesforce permissions.

The desired model is:

Regina → Regina's Salesforce permissions

John → John's Salesforce permissions

Sarah → Sarah's Salesforce permissions

rather than:

Everyone → Integration User's Salesforce permissions

12. Monitor and Review MCP Usage

MCP creates a new way for users and agents to interact with Salesforce, so organizations should include MCP activity in their existing governance and monitoring practices.

Review:

• Which users have access to MCP.

• Which MCP servers are enabled.

• Which tools are exposed.

• Which users are invoking write operations.

• Whether unexpected or excessive operations are occurring.

• Whether permissions remain appropriate as teams change.

Salesforce Hosted MCP provides authentication, authorization, permission enforcement, and logging as part of its security model.

Recommended CentroBot Configuration

For most CentroBot implementations, the following approach is a good starting point:

Summary

The best CentroBot + Salesforce MCP implementations treat MCP as the secure capability layer and CentroBot as the conversational experience.

For most organizations:

1. Start with read-only Salesforce use cases.

2. Authenticate users individually.

3. Let Salesforce enforce access.

4. Use focused MCP servers for specific personas.

5. Use Headless 360 when broad Salesforce capabilities are required.

6. Use Flow for complex business processes.

7. Carefully control write and destructive actions.

8. Make tool descriptions clear and specific.

9. Resolve ambiguity before changing records.

10. Test with real-world Salesforce permissions before production.

The result is a headless Salesforce experience where users can work with Salesforce directly from Microsoft Teams while maintaining the governance, security, and business logic already established in Salesforce.