Flow vs Apex Decision Matrix & Build vs Buy Scenarios
Quick-reference decision matrices for the two most common D4 decisions: (1) when to use Flow vs Apex, and (2) when to build custom vs buy from AppExchange. Print this page and have it next to you during mock boards.
Flow vs Apex Decision Matrix
Use this table to make instant decisions. Find your scenario on the left, read across.
| Scenario | Recommendation | Rationale |
|---|---|---|
| Simple field update on triggering record | Before-Save Flow | Zero DML cost, admin-maintainable |
| Field update on related records | After-Save Flow | Declarative, handles moderate volume |
| Complex calculation with conditional logic | Apex + Invocable | Cleaner in code, testable, callable from Flow |
| Processing > 50K records | Batch Apex | Flow struggles past 50K; Batch handles millions |
| Multi-object transaction with rollback | Apex Trigger | Explicit savepoint/rollback control |
| Simple REST callout with OpenAPI spec | External Services + Flow | No code needed, admin-maintainable |
| Complex callout with retry/circuit breaker | Apex Callout | Full control over error handling |
| Guided wizard with standard inputs | Screen Flow | Fast to build, admin-maintainable |
| Complex UI beyond standard components | Screen Flow + Custom LWC | LWC handles the custom part, Flow orchestrates |
| Scheduled batch cleanup | Scheduled Flow (simple) / Schedulable + Batch (complex) | Volume and complexity determine which |
| Event-driven async processing | Platform Event + Flow or Apex | Decoupled, separate transaction |
| Lead assignment with geo-rules | Flow + Invocable Apex | Admins manage routing; Apex handles geo-calc |
| Real-time lead scoring | Before-Save Flow | Simple field calculation, no DML |
| Nightly ERP data sync | Batch Apex + Schedulable | Volume, error handling, retry logic |
Decision Flowchart — Condensed
flowchart TD
START([New Requirement]) --> Q1{Only modifying<br/>triggering record?}
Q1 -->|Yes| BSF["Before-Save Flow"]
Q1 -->|No| Q2{Volume > 50K?}
Q2 -->|Yes| BATCH["Batch Apex"]
Q2 -->|No| Q3{Complex multi-object<br/>transaction?}
Q3 -->|Yes| APEX["Apex Trigger"]
Q3 -->|No| Q4{External callout?}
Q4 -->|Yes| Q5{Simple REST<br/>+ OpenAPI?}
Q5 -->|Yes| EXT["External Services\n+ Flow"]
Q5 -->|No| CALL["Apex Callout"]
Q4 -->|No| Q6{User interaction?}
Q6 -->|Yes| Q7{Custom UI needed?}
Q7 -->|Yes| HYBRID["Screen Flow\n+ Custom LWC"]
Q7 -->|No| SF["Screen Flow"]
Q6 -->|No| ASF["After-Save Flow"]
style BSF fill:#2d6a4f,stroke:#1b4332,color:#fff
style ASF fill:#2d6a4f,stroke:#1b4332,color:#fff
style SF fill:#2d6a4f,stroke:#1b4332,color:#fff
style EXT fill:#4ecdc4,stroke:#3ab5ad,color:#000
style HYBRID fill:#f4a261,stroke:#d4823e,color:#000
style BATCH fill:#e76f51,stroke:#c45a3f,color:#fff
style APEX fill:#e76f51,stroke:#c45a3f,color:#fff
style CALL fill:#e76f51,stroke:#c45a3f,color:#fff
Legend: Green = Declarative. Teal = Declarative + External. Orange = Hybrid. Red = Programmatic.
Trade-Off Comparison Table
| Factor | Flow | Apex | Board Talking Point |
|---|---|---|---|
| Dev speed | Faster (simple logic) | Faster (complex logic) | “I chose Flow for speed since the logic is straightforward” |
| Maintenance | Admin-friendly | Developer-required | ”The customer’s team is admin-heavy, so Flow reduces ongoing cost” |
| Testing | Manual, limited | Automated, CI/CD-ready | ”Apex gives us automated regression testing in the pipeline” |
| Performance | Good (simple ops) | Better (complex ops) | “Performance is critical here; Apex is compiled and optimized” |
| Debugging | Flow Debug UI | Logs, stack traces, IDE | ”Debugging complex orchestration requires Apex’s tooling” |
| Error handling | Fault paths (basic) | Try-catch (full control) | “Integration error handling requires Apex’s retry patterns” |
| Bulk ops | Careful design needed | Natural with collections | ”Data loader operations demand Apex’s native bulkification” |
| Version control | Metadata export | Native source tracking | ”CI/CD pipeline requires source-trackable Apex” |
Order of Execution — CTA Must-Know
flowchart LR
A["1 System\nValidation"] --> B["2 Before-Save\nFlow"]
B --> C["3 Before\nTrigger"]
C --> D["4 After\nTrigger"]
D --> E["5 After-Save\nFlow (Sync)"]
E --> F["6 Commit"]
F --> G["7 After-Save\nFlow (Async)"]
style B fill:#2d6a4f,stroke:#1b4332,color:#fff
style C fill:#e76f51,stroke:#c45a3f,color:#fff
style D fill:#e76f51,stroke:#c45a3f,color:#fff
style E fill:#2d6a4f,stroke:#1b4332,color:#fff
style G fill:#2d6a4f,stroke:#1b4332,color:#fff
Recursion Trap
After-save flows that update the triggering record re-enter the entire order of execution. Before-save flows do NOT cause re-entry. Apex triggers use static variables to prevent infinite loops. Know this — the board will ask.
Build vs Buy — Quick Decision Table
| Capability Type | Default Recommendation | Reasoning |
|---|---|---|
| CPQ / Complex pricing | Buy (Salesforce CPQ, Conga) | Commoditized, extremely complex to build |
| E-Signature | Buy (DocuSign, Adobe Sign) | Legal compliance, audit trail — never build this |
| Document generation | Buy (Conga, Nintex) | Not competitive advantage, proven at scale |
| Telephony / CTI | Buy (Five9, Amazon Connect) | Infrastructure-heavy, PCI concerns |
| Data quality / dedup | Buy (DemandTools, RingLead) | Ongoing maintenance burden too high to build |
| Advanced analytics | Buy (CRM Analytics, Tableau) | ML/AI capabilities hard to replicate |
| Payment processing | Buy — ALWAYS | PCI-DSS compliance makes build impossible |
| Core business process | Build custom | Competitive advantage, unique requirements |
| Simple notifications | Platform native | Flow email alerts, platform events |
| Basic reporting | Platform native | Standard reports and dashboards |
TCO Comparison — The 3-Year Rule
| Year | Custom Build | AppExchange Buy |
|---|---|---|
| Year 1 | HIGH (dev + test + deploy) | MEDIUM (license + implement + integrate) |
| Year 2 | LOW-MEDIUM (maintenance) | ONGOING (license + config + upgrade testing) |
| Year 3 | MEDIUM (feature dev + tech debt) | ONGOING (license + customization gaps growing) |
| Year 4-5 | HIGH (debt compounds, dev turnover) | ONGOING (license, may increase) |
The TCO Formula
Build: Initial Dev + (Annual Maintenance x Years) + Enhancement Cost + 20-40% Risk Premium
Buy: (License Cost x Users x Years) + Implementation + Integration + Upgrade Testing
The risk premium for build accounts for scope creep, developer turnover, and unforeseen complexity. Always include it.
AppExchange Evaluation — The Disqualifiers
These are instant “do not proceed” signals:
| Disqualifier | Why |
|---|---|
| Failed or no Salesforce security review | Non-negotiable for enterprise use |
| No recent updates (12+ months inactive) | Vendor may be abandoning product |
| Does not meet functional requirements | Cannot fill the gap even with customization |
| Unacceptable governor limit impact | Breaks your transaction budget |
| Unacceptable data model impact | Pollutes your schema, blocks future design |
Reverse-Engineered Use Cases
Scenario 1: Healthcare — Patient Intake
Situation: Hospital network needs multi-step patient intake form with insurance verification callout, document upload, and HIPAA-compliant data handling.
Decision: Screen Flow + Custom LWC (for document upload component) + Apex Invocable (for insurance verification callout with retry logic). NOT OmniStudio — the client does not have Industry Cloud licensing, and the ROI does not justify the additional license cost for this single use case.
Board defense: “I chose Screen Flow as the orchestration layer because the admin team can maintain the form steps. The insurance verification requires Apex because it needs retry logic and structured error handling that External Services cannot provide. The custom LWC handles the document upload with preview, which exceeds standard Screen Flow components.”
Scenario 2: Manufacturing — ERP Price Sync
Situation: Manufacturer needs real-time price lookups from SAP during quoting. 10K quotes/month, prices change daily.
Decision: Buy Salesforce CPQ for the quoting engine + Apex integration for SAP price callout (not External Services — needs caching, fallback pricing, and retry). Platform Event for async price cache refresh overnight.
Board defense: “CPQ is commoditized — building a custom quoting engine would take 6 months and cost 3x the 5-year license TCO. For the price integration, I chose Apex over External Services because we need a local price cache with fallback logic when SAP is unavailable.”
Scenario 3: Non-Profit — Donation Processing
Situation: Non-profit with 3 admins, no developers. Needs donation tracking, receipt generation, and basic reporting.
Decision: Platform native (custom objects, validation rules, before-save Flows) + AppExchange for receipt generation (Conga or similar). Do NOT build Apex — the team cannot maintain it. The entire solution must be admin-maintainable.
Board defense: “The declarative-first principle is not just a best practice here — it is an operational necessity. With zero developer capacity post-go-live, every piece of automation must be Flow-based. I chose an AppExchange package for receipts because building PDF generation in Apex would create an unmaintainable dependency.”
LWC vs Aura vs Visualforce — One-Line Answer
| Situation | Answer |
|---|---|
| New component | LWC — always |
| Existing Aura, working fine | Keep Aura, new features in LWC |
| Existing Aura, unstable | Rewrite in LWC |
| Existing VF, business value in migration | Phased migration to LWC |
| Existing VF, low usage, working fine | Keep VF, add to tech debt backlog |
Board Sound Bite
“Never migrate for migration’s sake. The board values pragmatic architecture. Migrating a stable Visualforce page used by 5 people monthly is a poor use of resources.”
Deep Dive Links
- Declarative vs Programmatic — Full analysis with code examples
- Build vs Buy — Complete vendor scorecard and TCO framework
- Decision Guides — All visual decision flowcharts
- Trade-Offs — Every trade-off matrix for D4
- D4 Quick Reference Overview — Back to overview