What a Required Field Knew

Somewhere in a Salesforce org, a validation rule fires when a sales rep moves an opportunity to "Closed Lost." The record won't save until they select a reason. Not at any earlier stage. Only at that moment. Someone decided that information matters, and decided exactly when.

Nobody calls this governance. It's just how the system works. And that small piece of conditional logic encodes an organizational judgment about what "correct" looks like, enforced silently, thousands of times a day, without anyone writing a specification document. The interface was the specification.

Multiply that by every required field, every stage gate that prevents skipping from "Prospecting" to "Closed Won," every dynamic form that surfaces a contract signer lookup only when a deal reaches signature. Decades of accumulated decisions, many undocumented, some understood only by the admin who built them.

Enterprise software is redesigning itself for agents, and the UI is what's being shed. Salesforce announced Headless 360 at TDX. Informatica unveiled headless data services with MCP endpoints designed for agent consumption. As Box's CEO put it: "agents won't use your UI, they'll talk to your APIs." The flexibility gains are real, and so is what travels with the UI when it leaves.

Salesforce's position is that business logic migrates with the headless move. Validation rules fire at the API layer too. True at the API layer, though admins routinely build bypass logic that lets API callers skip validations for data migrations and integrations. That exemption category, designed for occasional bulk operations, becomes the primary operating mode when agents are the main callers. And a field named Custom_Field_47__c that a human admin decodes from screen context is, as one partner noted, meaningless to an agent querying the org programmatically.

Informatica's headless approach takes a different tack: rather than claiming existing governance transfers automatically, they're building governance into their MCP endpoints. Metadata context so agents understand data sensitivity. Master data resolution so agents don't act on duplicates. Quality validation at the point of entry. Worth noting what that design choice implies. Specification has to be actively constructed at the new interface. It doesn't migrate from the old one on its own.

One Salesforce governance guide recommends that every validation rule include a description explaining why it exists and what business requirement it enforces. The recommendation implies most don't. Research on API governance suggests manual specification cycles run hours per endpoint. Scale that across an enterprise CRM with hundreds of custom objects and thousands of validation rules, and the migration starts to look like an organizational excavation project.

That assumes the excavation is possible. Some of what the UI encoded was emergent. Built by dozens of people across years, in response to problems nobody fully remembers. The conditional logic accumulated the way organizational knowledge usually does: unevenly, without a map. Going headless means this implicit specification work now has to be made explicit in API schemas, tool definitions, and agent instructions. There's a plausible scenario where most organizations simply don't do that work, and agents operate against undocumented fields with bypass logic enabled, quietly reproducing every shortcut and inconsistency the interface once held in place.

The people designing enterprise UIs were also, without quite naming it, specifying what "correct" looked like for their organizations. Whether that specification can survive the migration, or whether parts of it were only ever legible through the interface that enforced it, is worth sitting with.