For a decade, Salesforce users have interacted with the platform the same way: log in, navigate Lightning, click through the UI your admin built for you. That’s changing. With AIforce — announced at Dreamforce ’26 and unpacked further in Salesforce Ben’s recent analysis — Salesforce is moving toward a future where the interface itself becomes personal, dynamic, and built on the fly, wherever you happen to be working: Claude, Slack, Microsoft Teams, mobile, or the browser.
At ABSYZ, we work with Salesforce orgs every day, building them, securing them, and helping teams get more value out of the platform. This shift is one of the more consequential ones we’ve seen since Lightning itself, and it’s worth breaking down what it actually means for admins, architects, and business teams who’ll be living with it.
From Fixed Screens to "Surfaces"
The core idea is that the UI is no longer bolted to the application. Salesforce is introducing the concept of a “surface” — any interface where a person can interact with their org’s data. Today, that’s Lightning and the mobile app. Going forward, thanks to the Headless Experience Layer, it extends to AI tools like Claude, to Slack, to Microsoft Copilot and Teams, and likely more surfaces over time.
The premise is simple to state but significant in practice: instead of people going to Salesforce, Salesforce comes to them. Two people on the same team, looking at the same underlying data, could soon be working through two entirely different interfaces, one built for how they think, not how an admin laid out a page.
Why This Works: The Metadata Layer Was Always the Real Platform
This is only possible because of something Salesforce has quietly gotten right for two decades: its metadata-driven architecture. The UI has always technically sat on top of the platform, not inside it. Metadata defines your objects, relationships, sharing rules, and automation, completely independent of how a screen renders that information.
That separation is exactly what makes a personalized UI layer viable. When someone builds their own interface in Claude or Slack, they’re not redefining your security model or automation logic — that’s still governed centrally, as it always has been. They’re only building the presentation layer. From an architecture standpoint, this is a validation of good Salesforce design practice: keep logic and access control in the platform, not the page layout.
The Governance Wake-Up Call
Here’s the part we think deserves the most attention, and where we’re already fielding questions from clients: this change will expose orgs that have been quietly relying on the UI itself as a security boundary.
If your org hides sensitive fields by removing them from page layouts rather than locking them down with proper Field-Level Security, that gap has mostly been invisible — because the only way in was the UI you controlled. Once users can build their own interface and pull data through the Headless Experience Layer, a UI-only restriction no longer holds. The data was never actually protected; it was just out of view.
This is precisely the kind of technical debt that surfaces during any major platform shift, and it’s one we specialize in resolving. Before any org starts encouraging teams to build agentic UIs, we’d recommend an honest audit of:
- Field-Level Security across every profile and permission set — not just what’s hidden on a page layout
- Sharing rules and record access, to confirm they reflect actual business need rather than legacy UI workarounds
- Permission set groups, to make sure access is deliberate rather than inherited from years of ad hoc changes
- Data quality and metadata hygiene, since a personalized UI built on messy metadata will surface that mess faster, not hide it
Getting this right now is far cheaper than discovering the gap after a well-meaning team member builds a custom Claude interface that exposes something it shouldn’t.
What This Means for Different Roles
Admins will need to think less about designing a single “correct” page layout for every user and more about whether the underlying permission model can safely support many different, self-built views of the same data. Training and SOPs also get more complex when everyone’s interface can look different; “here’s how to find X on the screen” stops being a reliable instruction.
Architects gain a strong argument for the platform investment they’ve likely already been making: clean, well-modeled metadata and rigorously enforced security aren’t just best practice anymore, they’re the prerequisite for this entire vision to work safely.
Business teams and end users get something genuinely exciting: the ability to describe the view they want and have it built, rather than waiting on a development backlog for a new report or dashboard layout. Used well, this could meaningfully cut the time between “I need this data represented differently” and actually seeing it.
Our Take
We think this is the right long-term direction for enterprise software, and Salesforce is unusually well-positioned to leap because of its metadata-first architecture. But the transition isn’t just a UI upgrade — it’s a forcing function for governance discipline that many orgs have deferred for years.
Our recommendation for clients evaluating AIforce: treat this as your cue to run a full security and metadata health check before rolling out agentic UI building to end users, not after. The orgs that get the most value from this shift will be those whose underlying platform is already clean, well-governed, and ready for exposure beyond a single controlled Lightning experience.
If you’re weighing how AIforce and the Headless Experience Layer fit into your org’s roadmap — or want a clear-eyed audit of where your current UI-dependent security gaps might be — that’s exactly the kind of assessment our Salesforce team can help you run before you flip the switch.
