Do not let a model write your canonical CRM fields. Have it write its conclusions into separate proposal fields, and let a deterministic rule decide whether that proposal becomes the value your forecast runs on. Everything else in this article follows from that one decision.
It is a boring pattern and it is the difference between a CRM your revenue leader trusts and a CRM full of plausible values nobody can account for. We are an Official Salesforce Consulting Partner, and the ordering above comes from cleaning up write paths that were built the other way round.
Why the direct write is the wrong default
The appeal of a direct write is obvious. The agent reads the call transcript or the email thread, decides the opportunity has moved to negotiation, and sets the stage field. Done.
The problem is that the stage field is not a note. It is the input to the forecast, to the pipeline review, to whatever reporting the board sees, and in many orgs to automation that fires on stage change. When a model sets it directly, three things become impossible: you cannot tell which values were human and which were inferred, you cannot audit why a value changed, and you cannot roll back a bad run without guessing.
Split it instead. The agent writes to fields it owns exclusively: a proposed value, the evidence it used, a timestamp, and the source. Nothing reads those fields for reporting. Then a separate evaluator, written in Flow or Apex, decides whether to promote the proposal into the real field.
That evaluator is where your business rules live, and they should be explicit. Which transitions are allowed. Whether a stage can move backwards and under what conditions. Which statuses are terminal. What happens when a proposal arrives for a record that has been closed. Those rules already exist in someone’s head. Writing them into a gate is the work, and it is work that survives a change of model, a change of vendor, and a change of the person who built it.
The four things that break a CRM write path
Restricted picklists. Most well-run orgs restrict their important picklists, which means the field will reject any value not on the list. This is a feature. An agent that produces a sensible-sounding label rather than the actual option value will fail the write, and if the failure is not handled it will fail silently. So the mapping from what the agent concluded to the real option values happens at the integration layer, against the field’s actual metadata, and an unmatched value becomes an exception for a person rather than an invented new value.
Validation rules. If the integration is configured in a way that bypasses validation, you have not solved data quality, you have moved the problem somewhere harder to see. Salesforce’s own guidance for agent actions points at declaring sharing explicitly and running queries and data changes in user mode, so object permissions and field-level security apply to the agent exactly as they would to a person. Follow it. When a write fails because a validation rule caught it, that is the system working, and the right response is an exception with the rule name attached.
Conflict with a human edit. This is the one that destroys trust fastest. A rep updates the close date on Tuesday afternoon. The agent processes Tuesday morning’s call at four o’clock and proposes a different close date based on what was said. If the agent wins, the rep watches the system overwrite them, and within a fortnight the team has decided the automation is unreliable. The gate needs to compare when the field was last changed and by whom. If a person touched it more recently, the agent defers and flags rather than overwrites. Always.
The trigger path. Reasoning and external calls do not belong inside a trigger. Keep the transaction short, write the proposal, and let the promotion logic run where it can take its time. Anything that has to reconcile stale state or expire an old proposal runs on a schedule, not in the heat of a save.
What activity capture already does, and where it stops
Being precise about this changes the scope of what you actually need to build.
Native activity capture in Salesforce logs that contact happened. Emails and meetings attach themselves to the record, the timeline fills up, and the “no activity on half the pipeline” problem largely goes away. It is usually already in your licence, it costs nothing extra to switch on, and it should be the first thing you do.
What it does not do is change the deal. Stage, close date, next step, decision maker, competitor, qualification fields: those all stay exactly as the rep left them, which in practice means exactly as the rep did not fill them in. That gap between “we can prove we spoke to them” and “we know where this deal actually is” is the gap an agent is worth building for. It is also a much smaller scope than “automate the CRM”, which is a large part of why it can be delivered as one workflow rather than a programme.
Enrichment has a shelf life
Enrichment gets treated as a project and it is a schedule. Firmographic data decays continuously: people change jobs, companies get acquired, headcounts move, domains get consolidated. A one-off enrichment run makes the CRM look good for a quarter.
Two rules keep it honest. Tag the provenance of every enriched value, so you know which fields came from a data source, which came from a rep, and when. And never let the enrichment path overwrite a human-entered value without flagging it, because the rep who typed the contact’s direct line probably knows something the data provider does not.
Matching matters here too. Without lead-to-account matching before assignment, the same company arrives repeatedly as new leads and two reps work it independently. That is an unpleasant conversation with a prospect and it is entirely preventable at the routing layer.
What stays with a person
Outreach, discounts, and anything a customer will read. The agent enriches, scores, writes the fields the gate allows, prepares the next conversation and produces a list of records it could not finish. It does not email prospects and it does not approve pricing.
One related limit belongs here too. None of this makes a rep pick up the phone. If your inbound leads sit unworked, cleaning the data helps a little and coverage helps a lot. We would rather say that at the start than deliver a beautifully populated CRM into a team that still is not calling anyone.
When to fix the CRM before automating it
If your picklists are unrestricted and every rep has invented their own values, an agent will faithfully write into the mess. Standardise the small number of fields your reporting actually depends on first. That is a week of decisions, not a project, and it makes everything after it cheaper.
If nobody can state the rule for when a deal moves stage, the gate has nothing to enforce. Get that written down. It is a useful exercise even if you never automate anything.
If your CRM is being replaced or consolidated inside the next few months, wait. The field mapping is most of the build, and none of it survives the migration.
How we approach it
We put a supervised agent on one existing workflow, inside the CRM the client already runs, with a person on anything a customer will see. The specifics of that in a revenue operations context are on the sales operations workflow page.
If you want to know whether your CRM is ready for a write path, the first step is a free thirty-minute assessment with a delivery lead, looking at your actual records. Broader platform work, including Salesforce implementation and integration, sits under Salesforce and MuleSoft rather than in this package.