Headless Salesforce and existing Lightning interfaces run on the same platform, against the same data model, under the same permissions engine. Introducing headless custom applications alongside standard Lightning users does not break anything. The two coexist by design, and most organisations that move in this direction will do so gradually, building out headless surfaces for specific workflows while internal teams continue using the standard interface.
Salesforce confirmed this explicitly at TDX 2026 when announcing Headless 360. The Lightning App Builder, Flow, Apex, reports, and dashboards all remain. The platform will run in hybrid mode for years because it still runs the operations of hundreds of thousands of organisations that have no reason to abandon what works.
What headless actually changes
Headless decouples the front end from the platform. Instead of a person logging into a browser and navigating Salesforce screens, an application calls the platform directly via API or MCP tools. The underlying business logic, validation rules, sharing model, and automation all still fire. A record created through a custom headless application is subject to the same field-level security and workflow triggers as one created by someone clicking through Lightning.
The platform does not care whether a human or an application created the record. The governance layer fires either way.
The practical implication is that a fund manager could run a custom headless portal for advisers, handling specific workflows built around how those advisers actually work, while the distribution team continues using standard Salesforce internally. Both surfaces read and write to the same data.
The licence question
This is where the picture becomes less clear. Standard Salesforce operates on a named-user, per-seat model. Every person who accesses Salesforce requires a licence, and the type of licence determines what they can see and do.
For internal staff accessing Salesforce through a custom headless application rather than the standard interface, the named-user model still applies. A person is still a person from Salesforce’s perspective, regardless of the front end they use. Platform licences, cheaper than full Sales Cloud or Service Cloud seats, exist precisely for this scenario: internal people who need access to custom objects and applications but not the full CRM functionality. Platform Starter and Platform Plus are the two current tiers.
For external access at scale, the model shifts. Salesforce provides Integration licences for system-to-system API connections, including five free with Enterprise editions, designed for server-to-server calls rather than individual human access.
The unresolved question is what the headless MCP and Agentforce consumption layer costs at enterprise scale. Salesforce has not published a transparent tier model for this. Industry analysts have noted publicly that organisations should get pricing confirmed in writing with their account executive before committing to architectural dependencies on Headless 360 features.
The user model and audit trails
There is a more consequential question sitting underneath the licence question. Salesforce’s governance infrastructure, record ownership, created-by and modified-by fields, audit trail, profile and permission set enforcement, is built around named users. When every action in the system is attributed to a real person with a real licence, compliance reporting is straightforward.
A common approach in headless architectures is to authenticate via a single Integration User, one service account credential shared by the application. From Salesforce’s perspective, that service account is doing everything. Record ownership, audit history, and data access logs all point at a single technical user rather than the individual people whose actions are actually being recorded.
For organisations with compliance obligations around adviser interaction history, data access, and record ownership, this is a material issue. The workaround is to build a parallel identity layer outside Salesforce: a custom object tracking the real person behind each action, custom fields capturing who actually did what. That is technically achievable. It is also a deliberate step outside Salesforce’s native governance model, replacing a mature compliance infrastructure with a homegrown one.
The alternative is to keep individual named licences for anyone whose activity carries compliance significance, and use the Integration User pattern only for genuinely system-level operations where individual attribution is not required.
The hybrid model is sound. The question of which people remain named Salesforce users, and why, is not a technical decision. It is a governance decision, and it belongs with whoever owns compliance, not whoever builds the application.
Q: Can existing Salesforce Lightning applications and automations continue running alongside headless custom applications?
Yes. Headless Salesforce and the standard Lightning interface run on the same platform and the same data model. Flows, Apex triggers, validation rules, and reports are unaffected by the introduction of headless applications. Both surfaces operate under the same sharing rules and permissions model. A hybrid approach, with some people on Lightning and others accessing Salesforce through custom applications, is a standard architectural pattern.
Q: What Salesforce licence does a person need to access a custom headless application?
A named Salesforce licence is still required for any internal person accessing Salesforce data through a custom application, regardless of the front end. Salesforce Platform licences, available as Platform Starter or Platform Plus, are designed for people who need access to custom objects and applications but not full CRM functionality, and are priced accordingly. The full Sales or Service Cloud seat is only required where access to core CRM objects is also needed.
Q: What happens to audit trails and record ownership in a headless Salesforce architecture?
When a headless application authenticates via a single Integration User rather than individual named users, all record ownership and audit history in Salesforce points to that service account, not the individual people taking actions. Organisations with compliance obligations around data access and adviser interaction records should either maintain individual named licences for compliance-relevant users, or build a separate identity tracking layer outside Salesforce’s native governance model.
Q: Has Salesforce published pricing for Headless 360 MCP and API consumption?
Not transparently. As of mid-2026, Salesforce has not published a standardised tier model for Headless 360 MCP tool usage and Agentforce consumption pricing at enterprise scale. Industry analysts have explicitly advised organisations to confirm costs in writing with their Salesforce account executive before committing to architectural dependencies on these features.