1. The Requirement That Looked Simple
In the Apex Property Operations project, the original requirement sounded straightforward:
Ensure Work Orders always reference the correct Property.
On paper, this felt like something a single Flow could handle.
In practice, the moment I started building, it became clear that trying to force everything into one Flow would create more problems than it solved.
2. The Early Mistake: Overloading One Flow
My initial instinct was to:
- add more decision elements
- handle more scenarios
- “just tweak” the same Flow
Very quickly, the Flow became:
- harder to read
- harder to reason about
- riskier to change
At that point, the problem wasn’t Salesforce — it was design.
3. The Realisation: One Responsibility Per Flow
The breakthrough came when I stepped back and reframed the problem:
What is each piece of logic actually responsible for?
That led to a cleaner architecture built around separation of concerns.
Instead of one oversized Flow, I designed multiple focused flows, each with a single purpose.
4. The Final Flow Architecture
🔹 Flow 1: Derive the Correct Property
- Triggered on Work Order save
- Retrieves the Property from the related Maintenance Request
- Populates or corrects the Work Order Property
Responsibility: Data derivation
🔹 Flow 2: Ensure Consistency
- Runs when relevant fields change
- Verifies alignment between related records
- Applies corrective updates if needed
Responsibility: Ongoing data integrity
🔹 Flow 3: Guardrails and Clean-Up
- Handles edge cases
- Prevents unintended side effects
- Reduces the risk of recursion or conflicting updates
Responsibility: Stability and safety
Each Flow was:
- easier to understand
- easier to test
- safer to maintain
5. Before-Save vs After-Save: A Deliberate Choice
Another key design decision involved when each Flow should run.
Rather than defaulting everything to before-save or after-save, I chose based on intent:
- Before-save where values could be set cleanly
- After-save where related records needed to be queried or corrected
This avoided:
- unnecessary updates
- recursion loops
- unpredictable behaviour
6. Why This Matters More Than “Fewer Flows”
It can be tempting to aim for:
“One Flow that does everything.”
In reality:
- complexity hides bugs
- monolithic flows are fragile
- future changes become risky
By splitting logic across focused flows:
- changes are localised
- intent is clearer
- future admins can reason about the system faster
7. What This Taught Me About Salesforce Design
This project reinforced several principles I now design by:
- Simplicity is about clarity, not fewer components
- Flows should tell a story when read top to bottom
- Maintainability matters more than cleverness
- Salesforce rewards restraint
8. Outcome
- Predictable automation behaviour
- Reduced risk of recursion
- Cleaner debugging
- A solution that can evolve without fear
Most importantly, the system now behaves reliably even as requirements grow.
9. What This Demonstrates as a Salesforce Admin
- Architectural thinking beyond “just building flows”
- Understanding of execution order and automation limits
- Comfort making trade-offs
- Focus on long-term maintainability
✅ This completes the Apex Property Operations automation story
Together, these three posts show:
- How the automation was built
- Why certain tools were chosen
- How the design evolved responsibly
Continuous Learning and Iteration
This solution is not treated as “finished” in the absolute sense. As with most real-world Salesforce implementations, I expect to revisit parts of the design as usage patterns evolve or as I gain further insight. I may refine individual flows, simplify logic, or restructure elements based on hindsight — and I see that as a strength rather than a flaw. Salesforce administration is an iterative discipline, and the ability to reflect, adapt, and improve over time is a core part of building resilient, long-term solutions.