5 Process Builders, 3 Flows, 2 Triggers on One Object
“Stacked automations from three different consultants over two years. Nobody knew what fired when.”
What Happened
Inherited an org where Opportunity had 5 Process Builders, 3 record-triggered flows, and 2 Apex triggers — all built by different consultants over two years. Nobody documented what any of them did. They conflicted with each other. One Process Builder set the Stage based on Amount, then a Flow overwrote it based on a different condition, then a trigger overwrote that. The client said 'Opportunities keep changing Stage randomly.' It took me a week just to map out the order of execution.
The Wrong Way
// Opportunity automations (accumulated over 2 years): // Process Builder 1: Set Owner based on Region (v1) // Process Builder 2: Set Owner based on Region (v2, "fixed") // Process Builder 3: Create Task on Stage change // Process Builder 4: Update Account field // Process Builder 5: Send email on Close // Flow 1: Validate Amount > 0 // Flow 2: Set Stage based on Amount // Flow 3: Create Renewal Opportunity // Trigger 1: Roll up Amount to Account // Trigger 2: Sync to external system // // None documented. All interact. Good luck.
The Right Way
// ONE trigger per object. ONE handler class. // ALL record-triggered automation in ONE flow // (or call sub-flows for organization). // // Opportunity: // Trigger: OpportunityTrigger → Handler class // Flow: Opportunity - Record Triggered (one flow, // organized with sub-flows if complex) // // Document the order of execution: // 1. Before-save flow (field defaults) // 2. Validation rules // 3. After-save flow (related record updates) // 4. Trigger (complex Apex-only logic) // // Consolidation project: map all existing // automations → rebuild in unified architecture
The Lesson
One trigger per object. One record-triggered flow per object per timing (or consolidate). Document everything. If you inherit spaghetti, budget time to consolidate before adding more.
Enjoyed this? Get more like it.
Glen's Musings — AI, investing, and building things. Occasional. Free.
More Architecture Mistakes
Building Custom Objects When Standard Objects Already Exist
Built a custom Project_Tracker__c object. Turns out Salesforce has a perfectly good Task and Event system.
Read morePainfulHardcoded Config Values Instead of Custom Metadata Types
Hardcoded thresholds, API endpoints, and business rules in Apex. Every change required a deployment.
Read morePainfulThe God Object: One Custom Object to Rule Them All
Created one custom object with 200 fields to handle every use case. It handled none of them well.
Read more