Capabilities move behind a stable contract
Interfaces are no longer the only entry point. Apps, assistants, and automations can all reach the same governed action path.
Page 01
What is Salesforce Headless 360?
The short version: it is Salesforce reframed as something your own experiences, agents, and automations can call directly, instead of something users must always enter through the default interface.
This page keeps one job: define the idea clearly enough that the next click into the architecture feels obvious.
Next: See the architecture“Headless” matters because enterprise teams now deliver value through more than one surface. A customer may work through a portal, a partner workspace, a Slack flow, a mobile app, or an agent-driven assistant. If the platform only works well through the default UI, every new surface becomes expensive.
Salesforce Headless 360 points toward a different operating model. Core capabilities, policies, and context become accessible through contracts that other systems can call. That makes the platform easier to embed inside your own product, your own interface, and your own orchestration layer.
Agents stop screen-scraping the platform
The model becomes cleaner for tool use, API execution, and MCP-style mediated access because the system is designed to be called directly.
Governance stays close to the system of record
Headless does not mean ungoverned. Identity, policy, rate boundaries, and action scope stay inside a managed enterprise boundary.
Teams can ship more than one experience from one foundation
Once the contract is stable, the delivery surface becomes a product decision instead of an architectural constraint.
What it is
A headless delivery layer for Salesforce capabilities
Think governed access paths, reusable contracts, policy-aware execution, and delivery to any surface your team controls.
What it is not
Not just another portal template or customer-facing skin
The center of gravity is the callable capability boundary, not the look of the interface around it.