5.3 When to Use Apex vs Declarative Tools

5.3 When to Use Apex vs Declarative Tools

Quick Answer: Use Flow when declarative automation fully and maintainably meets the requirement (field updates, related DML, screens, approvals handoffs). Use Apex when you need complex bulk logic, robust recursion control, advanced integrations, or packageable algorithms that do not fit Flow cleanly. Prefer hybrid designs—invocable Apex called from Flow, or Apex starting an autolaunched Flow—when business users should own the path but code must own a hard step. On the exam, “best” means the simplest platform-native solution that covers all stated needs.

Section 2.3 introduced declarative versus programmatic thinking. This section is the Process Automation deep dive: how to choose Flow vs Apex (and when to combine them) under real blueprint pressure.

The Decision Standard (Memorize This)

For every scenario, run four checks in order:

1. Completeness — Does the option satisfy every requirement in the stem (including bulk volume, security, and error behavior if mentioned)?
2. Fit — Is this the Salesforce feature intended for that job (Flow, Approval, validation, trigger, queueable, and so on)?
3. Simplicity — Among options that fully work, pick the least complex maintainable one.
4. Platform safety — Governors, multi-tenant limits, and recursion must remain acceptable.

Code is not “more senior.” Unnecessary Apex that duplicates a before-save Flow is a wrong answer. Conversely, insisting on Flow when the stem describes recursive multi-object bulk logic with callouts is also wrong.

Decision Matrix: Prefer Flow

Flow strengths on the exam: speed of delivery, visibility in Flow Builder, and alignment with Salesforce’s automation strategy. If the stem emphasizes admins maintain or no code, and no technical constraint blocks Flow, choose declarative.

Decision Matrix: Prefer Apex

Apex strengths: precision, testability with Apex tests, and expressiveness for algorithms. The cost is deployment discipline, code review, and lower change velocity for non-developers.

Gray Areas and How the Exam Resolves Them

Before-save Flow vs before trigger

• Before-save Flow wins for straightforward field defaults, stamps, and simple branching on the triggering record.
• Before trigger wins when you need maps of related data loaded once for the whole batch, complex correlations across Trigger.new, or shared handler logic already standardized in the org’s trigger framework.

If the stem only says “set Delivery_Date__c = CloseDate + 7 when Stage is Closed Won,” Flow is enough. If it says “for up to 200 Opportunities, allocate capacity from related custom inventory rows without double-booking, using a locking query pattern,” Apex is the serious answer.

After-save Flow vs after trigger

Same theme: related DML and notifications → Flow first; sophisticated bulk orchestration, recursion suppression, or callout initiation after save → Apex (often async).

Validation rules vs Apex addError vs Flow

• Validation rules: formula-expressible field constraints on save.
• Apex addError: cross-object or bulk-aware rules validation formulas cannot express.
• Flow: not the primary “prevent save with error message” tool compared with validation rules; use Flow for process, not as a substitute for every validation.

Approvals vs custom status Apex

Covered in 5.2: human multi-step + lock + history → Approval Process. Exotic routing graphs → code or external BPM.

Hybrid Patterns (Often the Professional Answer)

Real orgs—and many advanced exam stems—mix layers intentionally.

Flow → invocable Apex

Expose an Apex method as invocable (@InvocableMethod) so Flow can pass collections of inputs and receive outputs. Use when:

• Admins own the branching and entry criteria in Flow
• One step needs a callout, complex calculation, or bulk-safe service
• You want a single tested Apex service reused by multiple flows

Design invocable methods to be bulk-friendly (list inputs, list outputs), not one-record-only, so Flow interviews in bulk contexts do not fan out poorly.

Apex → autolaunched Flow

Less common on entry-level scenarios but valid: Apex finishes a computation and starts a Flow interview for admin-owned follow-up (notifications, task templates, flexible field updates). Useful when packaging code should not hardcode every email template id.

Trigger handler calls service; service may enqueue work; UI still uses Screen Flow

Architecture layers can coexist: Screen Flow for UX, record-triggered Flow for light automation, trigger framework for core invariants, queueable for callouts. The exam rarely requires a full enterprise diagram—but if a stem describes multiple concerns, pick the option that assigns each concern to the right tool rather than forcing everything into one trigger.

Classic “Best Solution” Scenario Patterns

Train on these stem shapes:

1. “Admin should be able to update the criteria without code” → Flow / declarative (unless impossible).
2. “Must work for bulk API updates of 200 records with complex cross-object rules” → bulkified Apex; pure unoptimized Flow loops are suspect.
3. “Call an external credit service and update the account” → Apex callout path (usually async after save); not a simple before-save Flow alone.
4. “Guided wizard for agents” → Screen Flow (or LWC if the UI requirements exceed Flow screens—but PDI often stops at Flow when screens suffice).
5. “Prevent save when formula-expressible condition fails” → Validation rule, not a trigger, when the formula can express it.
6. “Manager then finance approval with lock” → Approval Process.
7. “Same record field stamp only” → Before-save Flow over after-save Flow or trigger.
8. “Existing heavy trigger framework; add a one-line field default” → Still prefer Flow if allowed; if the org standard is triggers-only and the stem says maintain the framework, follow the stem.

Always read all constraints: volume, user type, package context, callouts, and maintainers.

Anti-Patterns to Avoid on Both Sides

Flow anti-patterns

• After-save same-record updates that should have been before-save
• Get Records inside loops
• Duplicate overlapping record-triggered flows fighting each other
• Using Flow where validation rules alone solve a prevent-save rule

Apex anti-patterns

• Writing a trigger for a single field stamp a before-save Flow handles
• SOQL/DML inside loops
• Ignoring bulk and recursion until production data volume arrives
• Rebuilding approval history and locking from scratch

Putting the Chapter Together

• 5.1 taught Flow types, before vs after save, entry conditions, order of execution, and governors.
• 5.2 taught Approval Process structure and when not to code routing.
• 5.3 chooses among those tools and Apex with a completeness-first, simplicity-second rubric, plus hybrid invocable patterns.

If you can articulate why an option is best in one sentence that cites a constraint from the stem (“because only Apex can…”, “because before-save Flow efficiently…”), you are thinking like the scoring key.

Quick Reference Card

Use this matrix under time pressure; expand into design detail only when the stem’s constraints demand it.