The Recap
Salesforce field enrichment used to be slow, custom, and engineering-led. Every new field took roughly a week, GTM teams had no direct control over how fields were populated, and the same kind of work happened over and over again.
The first version of the Salesforce Enrichment Platform changed that. Instead of building each automation by hand, Haren shipped one shared AI engine with a config-driven, self-service interface. Field operations could select a field, let the platform analyze historical data, choose from AI-generated prompt options, test outputs against real opportunities, and deploy the automation themselves. A roughly week-long engineering cycle compressed into about 45 minutes to an hour.
That gave field operations the ability to launch automations. The next problem was what happened after launch.
The New Capabilities
Once a field automation was live, the platform did not give field operations much insight into how it was actually performing. The stopgap was an AI descriptor string in the text fields marking which entries had been written by an automation, and the rest of the feedback came from account executives raising issues directly. Proper automation tracking fields are on the roadmap, but until that lands, the system was not really self-service after launch.
The update changes that. From any live field, field operations can now run an evaluation against the most recent 50 writes pulled from the platform logs and Salesforce. The evaluation looks at what landed correctly, what landed incorrectly, and produces concrete suggestions for improving the underlying prompt.
In one live example, an earlier version of a next steps prompt was not prescriptive enough about handling cases with no signal. Roughly 15 opportunities ended up populated with a sentence explaining that there was no signal to draw from, which is not what should be written into the field. The evaluation flagged that pattern, recommended adding a clear no-signal branch, and pointed out a secondary issue where the model occasionally produced multi-paragraph output. Both fixes landed in the prompt without requiring engineering.
A second evaluation in the same demo surfaced a merge logic issue: the prompt was not reliably distinguishing the previous next steps from the new ones. A single-line suggestion from the evaluation, dropped straight into the prompt, materially improved its behavior.
The Impact
The shift here is that field operations now owns the automation end to end. They can build it, test it, launch it, and evaluate it without coming back to Haren when something looks off.
That keeps two workstreams cleanly separated. Field operations iterates on prompts. Haren iterates on the platform. The platform improvements compound across every field automation rather than getting absorbed into one-off prompt debugging.
It also raises the floor on quality. Issues that previously surfaced through account executive feedback now surface through structured sampling against production data. The evaluations do not just say something is wrong, they suggest the specific edit to make it right. That collapses the loop between noticing a problem and fixing it.
What's Next
Proper automation tracking fields are still on the roadmap. The current evaluations work by sampling logs and Salesforce, which is enough to diagnose live behavior, but dedicated tracking fields will give field operations and downstream consumers a more permanent record of which entries came from automation and how they performed.
The bigger direction is the same one the platform has been moving toward all along: more ownership in field operations, less engineering involvement per field. Each release pushes one more capability across that line, from launching automations to evaluating them, and the long-term picture is a system where the people closest to the data can run the full lifecycle themselves.
