Project Overview
What this project was about
In the Apex Property Operations system, Work Orders are created from Maintenance Requests.
Each Maintenance Request already has a related Property, but Salesforce still allows users to manually select a Property when creating a Work Order.
This led to a recurring problem:
- Users selected the wrong Property
- Data inconsistencies appeared across Work Orders
- Reporting and downstream processes became unreliable
The goal of this project was to remove user error from the process by ensuring that the Work Order Property always matched the Property on the related Maintenance Request.
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.
The Core Problem
At first glance, the requirement sounded simple:
“When a Work Order is created from a Maintenance Request, automatically populate the Property.”
However, Salesforce introduced several constraints:
- The Property field still appears on the create modal
- The field cannot be auto-populated at create time
- Removing the field from the page layout does not remove it from the create modal
- Making the field read-only was not feasible in this context
This meant users could still select any Property — even though the system already “knew” the correct one.
3. Initial (Tempting) Solutions — and Why They Didn’t Work
❌ Option 1: Remove the Property field entirely
Not possible. Salesforce still renders the field in the standard create modal.
❌ Option 2: Make the field read-only
Not supported in a way that worked consistently across the create experience.
❌ Option 3: Validation Rule
A validation rule could block saving when the Property didn’t match —
but this would:
- interrupt the user
- create friction
- solve the problem after the mistake rather than preventing it
This led to an important design decision:
Do not block the user — automatically correct the data.
4. The Chosen Solution: Record-Triggered Flow
I implemented a record-triggered flow on Work Order that runs when a record is saved.
Flow logic (high level)
- Trigger when a Work Order is created or updated
- Check if a related Maintenance Request exists
- Retrieve the Property from the Maintenance Request
- Populate (or overwrite) the Property on the Work Order
- Save the corrected record
This ensured:
- The correct Property is always applied
- User selections are overridden safely
- Data integrity is maintained without user disruption
5. Why This Runs On Save, Not On Create
One of the key lessons in this project was understanding Salesforce timing.
Although users select values during record creation:
- Salesforce does not allow certain fields to be auto-populated before the record exists
- The create modal UI behaves differently from the save lifecycle
By allowing the record to save first and then correcting it via Flow:
- The process remains seamless for the user
- The system ends up with the correct data every time
This was a deliberate trade-off:
correction over prevention.
6. The “Clumsy but Correct” Reality
Ideally, the Property field would:
- either not show at all
- or be auto-populated and locked
Salesforce did not allow this cleanly.
Rather than over-engineering or fighting the platform, I chose a pragmatic solution:
- Accept that the field appears
- Let users proceed
- Ensure the system corrects the value reliably on save
This was a conscious decision to choose maintainability and user experience over visual perfection.
7. Key Lessons Learned
🔹 Salesforce UI ≠ Salesforce Save Logic
What users see on screen is not always where control should live.
🔹 Automation Can Be Corrective
Flows don’t always need to prevent actions — sometimes they should fix them.
🔹 Validation Rules Aren’t Always the Answer
Blocking users can feel clean technically but messy operationally.
🔹 Choose Your Battles
Not every UI imperfection is worth complex workarounds.
8. Outcome
- Property consistency across all Work Orders
- No reliance on user accuracy
- Cleaner reporting
- A scalable solution that can be extended later
This project laid the foundation for the wider Apex Property Operations automation design, including additional flows to enforce consistency and manage related records.
9. What This Demonstrates as a Salesforce Admin
- Practical understanding of Flow timing
- User-centric design decisions
- Comfort working within Salesforce constraints
- Focus on data integrity over theory
This automation later influenced how I approached validation rules and multi-flow design in Apex Property Operations.