Most Salesforce projects still start with the assumption that users will spend a good amount of time inside Salesforce.
If someone needs to manage an opportunity, service case, member record, or account, we usually think about the Salesforce experience first.
Which Lightning page should they use?
What should appear on the record?
Do we need a Flow?
Does the process need a custom component?
That way of designing Salesforce has been normal for a long time.
Headless 360, along with Salesforce’s work with Claude, makes me think we may have to revisit that assumption more often.
There are going to be more situations where Salesforce is doing the work in the background while the user interacts somewhere else.
Take something simple like preparing for a customer meeting. A salesperson may open the account, check the opportunity, look at recent activities, read notes, check open cases, and perhaps review a dashboard before the call.
There is nothing particularly special about doing all of that through six or seven different screens. If an agent can pull the same information based on the user’s permissions, organize it properly, and present it where that person is already working, that may be a better experience.
The underlying Salesforce setup still matters.
If an agent is reading customer data and taking actions, the permissions have to be right. The data has to be trustworthy. Automation needs to behave predictably. Business rules cannot be scattered everywhere with nobody quite sure which one runs when.
These are not new Salesforce problems. They just become harder to ignore when another interface starts using the platform on behalf of the user.
I think this also changes how we should look at some customization requests.
A requirement comes in, and the natural response is often to design another Salesforce screen. But perhaps the first question should be where the person actually needs to complete the task.
If someone spends most of the day in Slack, Claude, an internal portal, or another application, forcing them into Salesforce for a relatively simple action may not always make sense.
That does not mean every process should become a chat interaction either. There are plenty of situations where a proper Salesforce screen is easier. Large amounts of data are easier to scan visually. Some users need to compare records. Administrators need detailed controls. Complicated transactions often need more structure than a conversational interface can comfortably provide.
So I don’t see the Salesforce UI disappearing. What I do see changing is the assumption that it always has to be the starting point.
If Salesforce capabilities are going to be used from several different interfaces, it becomes more useful to build them in a reusable way.
Today, a process might be designed around a Lightning page with automation sitting underneath it. Tomorrow, that same process may need to work from Salesforce, an agent, Slack, or a customer-facing application.
At that point, the real design problem is not the page. It is the capability underneath it.
What information can this user access?
What action are they allowed to perform?
Which business rules should run?
What gets logged?
What happens if something fails?
Those questions start to matter before deciding what the screen looks like.
There are still a lot of open questions around Headless 360 and agent-driven CRM.
Licensing will matter. Governance will matter. Organizations will have very different comfort levels around what an agent can read or execute. Some use cases will sound impressive in a demo and turn out to be unnecessary in production.
But the direction itself is interesting.
Salesforce has traditionally been both the system holding customer information and the place where users go to work with that information. Those two things do not necessarily have to stay together.
For architects and solution designers, that creates a useful question to start asking more often: Does the user actually need to be inside Salesforce to complete this process?