Case Study: When a Missing Validation Rule Cost a Full Sprint
Sometimes bugs are complex.
Sometimes bugs require deep investigation.
And sometimes bugs exist simply because no one asked a basic question:
“Should the user even be allowed to save this?”
The Setup
The client had a strict rule:
“Opportunities must have a Contract Start Date before they can be marked Closed Won.”
Simple enough.
But the system didn’t enforce it.
So users did this:
- Create Opportunity
- Forget to fill Contract Start Date
- Mark as Closed Won
- Trigger automation
- Automation crashed spectacularly
Support was drowning in errors.
The Real Root Cause
There was no validation rule.
None.
Zero.
Nothing preventing wrong data.
Automation wasn’t broken —
it was choking on inputs that should never have existed.
The Fix
We wrote a simple validation rule:
AND(
ISPICKVAL(StageName, “Closed Won”),
ISBLANK(ContractStartDatec)
)
This prevented the bad data from ever saving.
After this:
- No more automation failures
- No more broken processes
- No more panic
Why It Cost a Full Sprint
Because before we found the root cause, the team tried to fix:
- Flow elements
- Apex logic
- Page layouts
- Permission sets
- Record types
- Old Process Builders
Everyone looked everywhere except at data validation.
The simplest solution is often the last one people check.
The Lesson
Before debugging automation, always ask:
“Is invalid data even allowed?”
If the answer is yes →
your system is a ticking time bomb.
Final Thoughts
This case taught everyone involved:
Validation rules are the cheapest, fastest form of quality assurance.
And they prevent more production incidents than any amount of testing.