Business & Revenue OpsFree
CRM Validation Rules Documentation Generator
Send the field export and where data quality breaks, and get each proposed rule justified by a report and costed by the friction it adds.
A validation rule is a permanent tax on every future save that matches its condition, and almost nothing written about them prices that tax before the rule ships. Hendricks Payroll Services, a 60-person payroll software company, tested two proposed rules against two quarters of real Salesforce data before deploying either. The first: require a Loss Reason when Stage moves to Closed Lost. Of 216 opportunities closed lost, 78, 36.1 percent, closed with no reason recorded.
That gap was not cosmetic. On the Loss Reason Distribution report the sales VP reviews monthly, Unknown already outranked every real reason, including the top one, Price, at 61, ahead of Competitor at 45 and No budget at 32. Scoped narrowly, firing only on the transition into Closed Lost, the rule would trigger exactly once per lost deal, 216 times across two quarters, 7.7 stops per rep per quarter, at the moment a rep is already closing the record. Real report, low and well-timed friction: deployed.
The second proposal asked for a Next Steps value on every save to an open opportunity, not just a stage change. Checked against 4,850 actual saves over the same two quarters, 2,950, 60.8 percent, would have been blocked, including bulk updates with nothing to do with next steps. None of the six active reports read that field. Zero verified benefit against 61 percent friction is the trade a documentation template alone never forces anyone to compute.
The formula patterns are solved; the trade-off is not
Salesforce's own Trailhead module and four independent guides agree in detail on how to write a good rule. Name it by object and sequence, scope it with ISCHANGED and ISNEW so it only fires on the transition that matters, write an actionable error message, and build a bypass path for integration users. Every one of those is a real, correct pattern, and every one of them is about the rule in isolation.
None of the five asks the question that decides whether a correctly-written rule should even exist: what does it protect, and what does it cost. BOFC's governance checklist gets closest, telling admins to 'document rule purpose' and 'regularly audit active rules,' which still means recording a reason at write time, not measuring one. Not one of the five suggests running a proposed rule's condition against existing records before turning it on, the step that would have caught Rule B's 61 percent hit rate in advance.
The cost side is checkable before deployment, not just after complaints arrive. Every proposed rule's condition can be run against existing records to count how many would have failed it, which is the same number of times a rep would have hit the error going forward. Pairing that count with the one real report or metric the rule protects turns 'this seems like good practice' into a number two people can actually argue about.
How it works
Send the field export
The field export plus a description of where reports or dashboards currently show wrong or missing data.
Name the reports
Each candidate rule matched to the specific report or decision it would protect, or marked unverified.
Check the hit rate
Each rule's condition run against existing records to count how many would have failed it.
Get the verdict
Keep, redesign or reject per rule, weighed by report value against friction, plus the ready-to-build spec.
What you get
- Every proposed rule matched to the specific report or metric it protects, or flagged as protecting nothing verified
- Each rule's condition run against your existing records, so the historical hit rate is a real count
- A keep, redesign or reject verdict per rule, weighing the report it protects against the friction it adds
- The exact error message a rep will see, plus which workflow or integration the rule might block
- A bypass path specified wherever an integration or bulk-update user needs to skip the rule
- The rule spec written in a form ready to build directly into Salesforce or HubSpot
Common questions
What counts as 'the historical hit rate'?
How many existing records would have failed the proposed rule's condition, which approximates how often a rep would hit the error going forward. A rule scoped to one stage transition typically hits a small, predictable count. A rule scoped to every save on an object can hit a majority of all activity on that object.
What if I don't know which report a rule is supposed to protect?
Say so, and the spec marks that rule as unverified benefit rather than inventing a justification for it. A rule with no traceable report or decision behind it still might be worth keeping for data hygiene alone, but the trade-off changes once the benefit side is honestly zero.
Doesn't a stricter rule always improve data quality?
Only the data quality of records that still get saved through the CRM. A rule with high friction and no report behind it is the textbook case of reps saving elsewhere, in a spreadsheet or a note, and updating the CRM later or never, which the audit usually finds well after the fact.
Can this write the actual formula, not just the spec?
Yes, in Salesforce or HubSpot's own validation syntax, scoped with ISCHANGED or ISNEW where that narrows the friction without weakening the check. The spec sheet carries the formula, the error message, and the field it fires on, ready to paste into Setup or the equivalent HubSpot property validation.
How is this different from the field dictionary?
The field dictionary documents what a field is and who writes it. This tool proposes and prices rules that enforce a field gets written correctly in the first place, which is a natural next step once the dictionary shows which fields the reporting actually depends on.
What happens to rules that get a reject verdict?
They are written down as rejected with the reasoning, which stops the same proposal resurfacing untested in six months. A rejected rule sometimes survives in a redesigned, narrower form instead. Either way the record explains why the obvious-sounding rule did not ship.
Do these rules ever need to change later?
Yes, whenever the report they protect changes or a new integration starts writing to the field. Treating a validation rule as a one-time build rather than something to recheck is how a rule that made sense two years ago quietly becomes the thing support tickets are about today.
CRM Validation Rules Documentation Generator
Fill in the form and your workspace opens with the work already underway.