1. Context: The Temptation of a Validation Rule
During the Apex Property Operations project, I needed to ensure that every Work Order always referenced the correct Property.
At first glance, this looked like a textbook use case for a validation rule:
- If the Property didn’t match the related Maintenance Request → block the save.
Technically, this would have enforced correctness.
But as the solution evolved, it became clear that technical correctness and operational usability are not always the same thing.
Sometimes, the simplest moments hold the deepest wisdom. Let your thoughts settle, and clarity will find you. Use this quote space to share something inspirational or reflective, perfectly aligned with the theme of your article.
2. Why a Validation Rule Seemed Logical
Validation rules are often the default tool for enforcing data quality because they:
- Prevent incorrect data from being saved
- Surface errors immediately to users
- Are simple to implement and understand
In isolation, a validation rule would have solved the problem.
However, Salesforce automation rarely lives in isolation.
The Hidden Cost: User Friction
In this scenario:
- Users were not intentionally selecting the wrong Property
- The system already knew the correct Property via the Maintenance Request
- The incorrect value was a by-product of the create experience, not user negligence
Blocking the save would have:
- Interrupted the user unnecessarily
- Forced them to “fix” something the system could already resolve
- Increased frustration without improving outcomes
This raised an important question:
Should the user be responsible for correcting something the system already knows how to fix?
4. Why Automation Was the Better Tool
Instead of blocking the save, I used a record-triggered flow to correct the data automatically.
The flow:
- Allows the record to save
- Retrieves the correct Property from the related Maintenance Request
- Updates the Work Order behind the scenes
From the user’s perspective:
- The process remains smooth
- No errors appear
- The correct data is stored every time
This approach prioritised experience and reliability over enforcement.
5. Understanding Salesforce Timing (The Key Insight)
A crucial factor in this decision was understanding when Salesforce applies logic.
Validation rules:
- Fire during the save process
- Prevent the record from being committed
Flows:
- Can run before or after save
- Can correct data once the record exists
Because the Property value could not be reliably controlled at create time, enforcing it before save created more problems than it solved.
Letting the save succeed and correcting the data afterwards aligned better with how Salesforce actually behaves.
6. When Validation Rules Are the Right Choice
This wasn’t a rejection of validation rules altogether.
Validation rules are still appropriate when:
- A user must make an intentional decision
- Incorrect data has real business consequences
- The system cannot safely infer the correct value
In this case, none of those applied.
The system already knew the answer.
7. The Design Principle I Took Forward
This experience reinforced an important admin principle:
Don’t block users for system shortcomings — automate around them.
Rather than forcing users to understand technical constraints, the platform should absorb complexity wherever possible.
8. Outcome
- No user-facing errors
- Correct Property values across all Work Orders
- A cleaner, more resilient automation design
- Reduced dependency on user training or vigilance
This decision also informed how I structured subsequent flows in the Apex Property Operations project.
9. What This Demonstrates as a Salesforce Admin
- Sound judgement in tool selection
- Awareness of user experience
- Deep understanding of Salesforce execution order
- Willingness to choose pragmatism over dogma
Lesson Learned
This experience reinforced my approach to balancing data integrity with user experience.