Salesforce made a much bigger Headless 360 announcement on August 19. The marketing version is that Salesforce can now work anywhere an AI agent works. The practical version is more interesting: the data, automation, permissions, and business rules you already have in Salesforce can be used by an authorized AI client without forcing that client through the Lightning interface.

That does not mean the Salesforce user interface is disappearing. It means the interface is no longer the only front door.

For customers, admins, and consultants, this is an architectural change worth understanding. It could make Salesforce far more useful outside Salesforce. It could also expose years of sloppy permissions and fragile automation faster than anything we have seen before.

What Headless 360 actually is

“Headless” is an old software term. It means the user interface is separated from the system behind it. The backend owns the data and business logic, while different interfaces can use those capabilities.

Salesforce is applying that idea across the platform. According to the August 19 Headless 360 announcement, Salesforce capabilities can be exposed to authorized AI agents and applications through APIs, Model Context Protocol servers, command line tools, reusable skills, and a new experience layer.

In plain English, Salesforce can remain the system of record while the work happens somewhere else. A salesperson might update an opportunity from Slack. A service employee might resolve a case through a conversational assistant. A developer might ask an AI coding tool to configure an integration. A customer might interact with Salesforce logic through a custom mobile app and never know Salesforce is underneath it.

The surface changes. The Salesforce security model, automation, and data model remain underneath.

What Salesforce added

The latest expansion is broader than the original Headless 360 announcement from April. It includes:

• The Headless 360 MCP Server, which lets compatible AI clients discover and use Salesforce capabilities
• A Data 360 MCP Server for trusted customer context
• More than 100 reusable agent skills
• A Headless Experience Layer for web, mobile, embedded, and conversational experiences
• Salesforce Multi-Framework support for modern React applications
• Expanded capabilities across Sales, Service, Marketing, Commerce, Tableau, MuleSoft, Informatica, and other Salesforce products

The most important part is the MCP server. MCP gives an AI client a standard way to discover tools, understand what they do, and call them. Salesforce is not simply handing an agent a giant list of thousands of APIs. The Headless 360 MCP Server exposes four tools:

• Discover finds the Salesforce operation that fits the request.
• Describe returns the requirements, parameters, dependencies, and order of operations.
• Dispatch performs the selected operation.
• Dispatch Read Only performs operations that do not change Salesforce.

That smaller tool surface matters. An AI model does not need to burn time and tokens sorting through thousands of individual tools before it can act.

The Salesforce UI is not going away

This is where some of the online discussion has gone off the rails. Headless 360 does not mean everyone stops logging into Salesforce next month. Lightning pages, reports, dashboards, consoles, and admin screens still have a job.

It does mean that Salesforce customers should stop assuming every process needs another Salesforce screen.

If the user already works in Slack, Teams, a custom portal, a mobile app, or an AI assistant, it may be better to bring the Salesforce action to that surface. The question changes from “How do we get the user into Salesforce?” to “How do we safely bring the right Salesforce capability to the user?”

That is a meaningful shift.

Before you set it up

The Headless 360 MCP Server is currently a beta service. Start in a sandbox or developer environment, not production. The current Salesforce reference documentation lists API version 67.0 or later as a requirement.

You will need:

• System Administrator access, or equivalent permissions
• A Salesforce sandbox or other safe test org
• An MCP compatible client such as ChatGPT, Claude, Cursor, or Postman
• The OAuth callback URL required by that client
• A clear first use case and a test user with limited permissions

Do not start by connecting a highly privileged administrator to production and asking the agent to “clean things up.” That is not a pilot. That is an incident waiting for a date.

Detailed Headless 360 setup instructions

1. Activate the Headless 360 MCP Server

1. In Salesforce Setup, enter MCP Servers in Quick Find.
2. Select MCP Servers under API Catalog.
3. Click Salesforce Servers.
4. Find and open headless-360.
5. Click Activate.

The production server URL is:

https://api.salesforce.com/platform/mcp/v1/platform/headless-360

The sandbox and scratch org server URL is:

https://api.salesforce.com/platform/mcp/v1/sandbox/platform/headless-360

2. Create an External Client App

This is important: Salesforce says to use an External Client App. A traditional Connected App is not supported for this connection.

1. In Setup, enter External Client in Quick Find.
2. Open External Client App Manager.
3. Click New External Client App.
4. Complete the basic information.
5. Expand API (Enable OAuth Settings).
6. Select Enable OAuth.
7. Enter the callback URL for your MCP client.

Salesforce currently lists these examples:

• Claude: https://claude.ai/api/mcp/auth_callback
• Postman desktop: https://oauth.pstmn.io/v1/callback
• Postman web: https://oauth.pstmn.io/v1/browser-callback
• Cursor: http://localhost:8787/callback, with some versions also using cursor://anysphere.cursor-mcp/oauth/callback
• ChatGPT: copy the callback URL shown in ChatGPT Advanced settings

The callback URL must match what the client actually sends. A mismatch is one of the easiest ways to turn a ten minute setup into an hour of unnecessary troubleshooting.

3. Add the required OAuth scopes

Add these scopes to the External Client App:

• Access MCP servers (mcp_api)
• Perform requests at any time (refresh_token)

Under Security, use the settings Salesforce specifies for hosted MCP connections:

• Deselect Require secret for Web Server Flow.
• Deselect Require secret for Refresh Token Flow.
• Select Require Proof Key for Code Exchange (PKCE) extension for Supported Authorization Flows.
• Select Issue JSON Web Token (JWT) based access tokens for named users.

Do not skip the JWT option. Salesforce warns that OAuth can appear to succeed without it, while later MCP calls fail with INVALID_AUTH_HEADER or INVALID_JWT_FORMAT.

Create the app. Salesforce notes that a new External Client App can take up to 30 minutes to become operational. After it is ready, open the app settings and retrieve the consumer key under OAuth Settings. That consumer key is the client ID your MCP client will use.

Create a separate External Client App for each client type. For example, use one for ChatGPT and another for Claude. Salesforce recommends this because it makes permissions and activity easier to control and audit.

Create a separate External Client App for each client type. For example, use one for ChatGPT and another for Claude. Salesforce recommends this because it makes permissions and activity easier to control and audit.

4. Restrict who can use the connection

By default, access can be broader than most organizations should accept for a pilot. Create a dedicated permission set for approved MCP users, then configure the External Client App OAuth policy to require preauthorization through that permission set.

Assign it only to the people participating in the pilot.

Then review the Salesforce permissions those users already have. Headless 360 respects CRUD, field level security, sharing rules, profiles, permission sets, validation rules, triggers, approval logic, and governor limits. That is good, but it also means an agent acting for an overpowered user can be overpowered too.

For a production design, also consider:

• Refresh token validity of 30 days or less
• Refresh token rotation
• Single logout so revoking the Salesforce session ends the MCP client session
• A client secret for web based clients that can store it safely
• IP restrictions only when the client uses stable address ranges that fit Salesforce limits

5. Configure the MCP client

In your chosen AI client, add a custom MCP connection using the appropriate Headless 360 server URL. Provide the consumer key from the External Client App and use the same OAuth callback URL you registered in Salesforce.

Start the OAuth sign in and authenticate as your limited pilot user. The user identity matters. Every operation will run within that user’s Salesforce access.

Configuration screens vary by client, so use the client’s current connection instructions for the final fields. The Salesforce side should remain the same: server URL, External Client App, mcp_api and refresh_token scopes, OAuth, and a named Salesforce user.

6. Test read only before allowing changes

Your first test should be boring. Boring is good.

Try a request such as:

Tell me which open opportunities assigned to me are expected to close this month. Do not change any records.

Confirm that the agent uses read only dispatch, returns only records the user can access, and does not expose restricted fields.

Next, try a narrow write in the sandbox:

Log a test call on Account ABC with the comment “Headless 360 sandbox test.” Show me the planned action and ask for approval before making the change.

Verify the record in Salesforce and check that the action is attributed to the correct user. Also test the negative case. Ask for a record or field that the user should not be able to access and confirm it is blocked.

7. Add production guardrails

Before a real rollout:

1. Define the approved use cases. Do not start with “anything the agent can do.”
2. Use a dedicated permission set and least privilege access.
3. Require confirmation before write operations, especially for admins and developers.
4. Create repeatable tests for successful requests, denied requests, bad data, and ambiguous instructions.
5. Review validation rules, flows, Apex, and integrations that will fire when the agent changes a record.
6. Monitor the audit trail and client activity.
7. Document ownership, support, rollback, and token revocation procedures.
8. Measure both business value and consumption cost before expanding the pilot.

Headless 360 MCP Server versus Agent API

These are related, but they solve different problems.

The Headless 360 MCP Server lets an external AI client discover and execute Salesforce capabilities. Use it when you want a client such as ChatGPT, Claude, or an AI coding tool to work with Salesforce data, setup, and business operations.

The Agent API lets an application communicate with an Agentforce agent through REST. It manages sessions, messages, streaming responses, variables, feedback, and session completion. Use it when you are building a custom website, mobile application, or other channel that needs to talk to a specific Agentforce agent.

If your goal is “let this AI assistant work across Salesforce,” look at MCP. If your goal is “embed this Agentforce agent in my application,” look at the Agent API.

What this means for admins and consultants

Good Salesforce architecture becomes more valuable in a headless world, not less.

Your object model gives the agent context. Your flows and Apex provide reusable business behavior. Your permission design defines the agent’s boundaries. Your validation rules and approvals remain the guardrails. If those pieces are clean, you have a strong foundation. If they are a mess, Headless 360 will not fix them. It will simply give the mess more ways to run.

This is why I would not treat Headless 360 as a tool installation project. Start with process design and security. Decide what work should happen outside the Salesforce interface, who should be allowed to initiate it, what needs human approval, and how you will know the result was correct.

If you are already preparing Agentforce for production, the testing and prompt controls in Salesforce Summer ’26 belong in the same conversation.

Helpful resources and independent coverage

If you want to keep going, these are the sources I would use:

• Salesforce Help: Understand the Headless 360 Architecture for the official architectural view.
• Salesforce Developers: Try Headless 360 for a guided three step connection exercise.
• Salesforce Developers: Create an External Client App for current callback URLs, OAuth scopes, and security settings.
• Salesforce Admins: Introduction to Headless 360 for Admins for what this means to declarative builders and governance.
• Salesforce Ben: Headless 360 and Agentforce Vibes 2.0 for independent coverage of the original announcement.
• Salesforce Ben: A First Look at Headless Data 360 for a useful hands on practitioner perspective.

Helpful resources and independent coverage

If you want to keep going, these are the sources I would use:

• Salesforce Help: Understand the Headless 360 Architecture for the official architectural view.
• Salesforce Developers: Try Headless 360 for a guided three step connection exercise.
• Salesforce Developers: Create an External Client App for current callback URLs, OAuth scopes, and security settings.
• Salesforce Admins: Introduction to Headless 360 for Admins for what this means to declarative builders and governance.
• Salesforce Ben: Headless 360 and Agentforce Vibes 2.0 for independent coverage of the original announcement.
• Salesforce Ben: A First Look at Headless Data 360 for a useful hands on practitioner perspective.

The bottom line

Headless 360 is not the end of the Salesforce interface. It is Salesforce admitting that the most useful interface may be wherever the user already is.

That is a smart direction. It makes years of Salesforce investment more reusable and gives AI agents a governed way to do real work. But the value will not come from connecting an agent and hoping for magic. It will come from clean data, dependable automation, least privilege access, deliberate testing, and a use case worth solving.

Start small. Use a sandbox. Prove one read only use case, then one controlled write. If those work reliably and save someone meaningful time, expand from there.