ChatGPT
Claude
Google AI
Copilot
The most common failure in a Sales Cloud automation estate is not a broken Flow. It is a working one that reps have quietly learned to satisfy without telling it the truth.
That failure produces no error, no debug log and no support ticket. The record saves. The stage advances. The report populates. Somewhere in the middle a rep typed a value they knew was wrong, because the alternative was to stop working on a deal, and nothing in the platform is capable of noticing the difference.
Automation serves the rep or it serves the report
Every rule in a Sales Cloud org can be sorted into one of two piles, and the sorting predicts almost everything about how it will be received.
The first pile removes work a rep was already doing. Creating the follow-up task they would have written down anyway. Populating the fields that can be derived from the account. Routing the lead so nobody has to decide who owns it. Sending the internal notification the rep would otherwise have chased by hand. These are adopted without a change programme, because from the rep's seat they are indistinguishable from the system simply being good.
The second pile takes time from the rep so that a report elsewhere can be populated. Required fields the rep gains nothing from. Justification text nobody reads. A checkbox that exists because a director asked for a slice they could not otherwise cut. Each of these is individually defensible, and each of them asks a person who is measured weekly to spend part of their week producing an input for someone else's output.
Reps do not usually refuse the second pile. Refusal would be visible. What happens instead is that they satisfy it at the lowest possible cost, which means the field gets a value, the value clears the rule, and the report is built on it. Sales automation that pays for itself in reporting is spending a currency the reporting then quietly debases.
Required-field creep is the classic failure
No organisation sets out to have eleven required fields on an opportunity. It arrives one field at a time, over about two years, and every single addition was reasonable.
Sales wanted competitor captured so win-loss analysis was possible. Finance wanted the billing contact so invoices did not bounce. Marketing wanted the original campaign preserved through the handover. Product wanted a use case picklist. The revenue operations lead wanted next step written out, because reviews were being run off memory. None of those requests is unreasonable, and none of them was ever weighed against the accumulated cost of the ones already in place, because nobody owned that total.
What the rep experiences is not eleven reasonable requests. It is a wall between them and saving a record they are trying to progress. The behaviour that follows is entirely rational. Competitor becomes Other. Use case becomes the first value in the picklist. Next step becomes a full stop, or the word Follow, or whatever cleared the rule last time. The record saves, the analysis gets run, and the win-loss review concludes something confident about a field where half the rows say Other.
The remedy is not a shorter list chosen by taste. It is an owner for the total, and a standing question asked of every addition: what decision changes if this field is populated, and who will notice if it is populated wrongly. Fields that fail the second half of that question do not need to be required. They need to be optional, and if nobody fills them in voluntarily, that is a finding rather than a problem.
Validation rules that fire at the wrong moment
Timing is where most validation rules go wrong, and it is almost never the thing that gets reviewed.
A validation asking for a close date at opportunity creation is the common example. On a long sales cycle, a rep at first contact has no defensible close date and never did. What they have is a rule requiring one, so they enter the end of the current quarter, or the end of the next, and that guess becomes a data point in a pipeline report. Nobody in the review knows it was a guess. It looks exactly like the close dates that were negotiated with a customer.
The same rule attached to the transition into a late stage would be correct. At that point the rep genuinely knows, the answer is defensible, and the validation is checking rather than inventing. The rule did not need to be removed. It needed to fire fourteen weeks later.
The general form is worth stating plainly. A validation rule is only a control if the person who triggers it can answer it truthfully at the moment it fires. Otherwise it is a fiction generator with an error message, and it is a particularly expensive one, because the fiction it produces is indistinguishable in the database from a fact.
Two practical tests are enough for most rules. Can the rep know this now, and if they cannot, what will they type instead. If you can predict the workaround value, you have already predicted your data.
Automation that fires on a field the rep does not control
A related and quieter failure is automation keyed to something outside the rep's hands.
Territory-derived owner fields, integration-populated firmographics, lead source written by a marketing system, product codes set by a pricing sync: all of these are legitimate fields, and all of them sit outside the rep's control. When a rule fires on one of them, the rep experiences an effect with no visible cause. Their opportunity gets reassigned. An approval appears. A stage will not advance, and the message names a field they did not touch and cannot edit.
The rep's response is not to raise a data issue with the integration owner. It is to find the shape of record that does not trigger the behaviour, and then to make records that shape. That might mean creating opportunities under a different account, leaving a product line off until after the approval has cleared, or waiting until the sync has run before entering anything at all. Each of these is a competent local solution to a problem the rep was given no other way to solve, and each one costs the organisation a category of data it believed it had.
Where a rule genuinely must depend on a system-owned field, the fix is not to hide the dependency better. Surface the field on the page layout as read only, name it in the error message, and give the rep a route to get it corrected. Automation is allowed to depend on things the rep cannot change. It is not allowed to be invisible about it.
The anti-patterns, and what each one produces
The workarounds are more predictable than the automations that cause them. This is the mapping we use in design reviews, and it is usually enough to settle an argument about whether a proposed rule is worth its cost.
| Anti-pattern | What the rep does instead | What the data looks like afterwards |
|---|---|---|
| Required field the rep cannot yet answer | Enters a placeholder that clears the rule | A populated field carrying a confident wrong value |
| Free-text justification nobody reads | Types a full stop, or copies the previous entry | High completion rate, no information |
| Validation at creation for a late-stage fact | Guesses, then never revisits the guess | Forecast dates that were never negotiated |
| Approval triggered at a discount threshold | Structures the quote to land just underneath it | Discounting that looks disciplined and is not |
| Stage gate with an unreachable exit criterion | Skips the stage, or works the deal outside the record | A pipeline stage nobody occupies |
| Rule firing on a system-owned field | Shapes records so the rule never triggers | A whole category of deal missing from the segment |
| Notification sent on every update | Filters the alert into a folder | An escalation path that no longer escalates |
| Automation that overwrites a rep's own entry | Stops maintaining the field at all | A field that ages quietly into uselessness |
Read the third column rather than the first. In every row the data passes validation, populates the report and looks like evidence. That is the whole problem: the organisation is not missing this data, it has the worse thing than missing data, which is confident data that is not true.
Anything a rep cannot see the reason for will be defeated
This is the principle underneath every row of that table, and it is worth stating on its own, because it is the one that changes designs.
Reps are not hostile to process. They are hostile to cost with no visible return, and they are extremely good at finding the cheapest path through a system, because that skill is the same skill that makes them good at the job. Give a competent person a rule whose purpose is not apparent and a deal that has to progress, and they will find the way through in about a week. That is not a training failure. It is the predictable behaviour of someone optimising for the thing they are actually measured on.
The design consequence is that the reason has to travel with the rule, and it has to be visible at the moment the rule fires. An error message saying the field is required teaches nothing. An error message saying the close date drives the forecast the rep will be asked about on Friday tells them why the field matters to them, and that is the only version of why that changes behaviour.
Where automation should stop
Some work should stay manual, and choosing that deliberately is a design decision rather than a gap in the roadmap.
Automation should stop where the input is not yet knowable, for the timing reasons above. It should stop where the judgement is the value: qualification calls, stage advancement on complex deals, and anything where two experienced people would reasonably disagree. It should stop where it would overwrite something a rep is measured on, because a field that gets overwritten silently is a field that stops being maintained. And it should stop where the cost of being wrong lands outside the organisation, on a customer with no context for the error.
The Sales Cloud platform will happily let you automate all of it. The restraint has to come from the design. A useful sanity check is to ask what the rep is left doing once the automation lands. If the answer is that they are checking the automation's work, the automation has moved the labour rather than removed it, and the checking will stop long before the automation does.
The boundary between rule-based work and work that needs interpretation is a separate question, and one worth settling explicitly rather than by habit. We set out the placement test in Agentforce or Flow, and the same discipline applies to whether a requirement belongs in Flow or in Apex, which we cover in write the decision down before you build.
Design from the rep's day, not from the data model
The most reliable way to get this right is unglamorous. Watch three reps work for an hour each, at a moment when they are busy.
Watch where they hesitate, what they retype, which screens they abandon, and what they do immediately after saving a record. Note every point where they stop to satisfy the system rather than the deal. That list is your automation backlog, in priority order, and it will not match the list produced in a requirements workshop, because a workshop asks people what they want while an observation shows you what is costing them.
The same watching exposes the rules that are already being defeated. A rep who tabs straight past a field to the value they always use is telling you that field is dead, whatever the completion rate says. A rep who keeps a spreadsheet is telling you the record does not hold something they need. Neither signal appears in a report, and both are free to collect.
Where AI-assisted capabilities enter the picture, the same test applies unchanged: does it remove work, or does it add a step. We looked at how that plays out on a sales floor in Agentforce for sales, and the pattern is the one described here arriving in newer clothing. Agentforce does not change the economics of a rep's attention, and a capability that costs them two minutes will be abandoned however well it reasons.
The question worth asking of every rule
When a Sales Cloud automation is proposed and the room cannot agree, one question tends to resolve it faster than a debate about requirements.
If a rep cannot answer this honestly in the time they have, what will they type instead. Everyone in the room can usually predict the answer, and once it has been said out loud, the discussion stops being about whether the data would be nice to have. It starts being about whether the value you are about to receive is the value you asked for.
