5.3 When to Use Apex vs Declarative Tools

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

5.3 When to Use Apex vs Declarative Tools

Key Takeaways Explain This Topic AI

Choose Flow for admin-maintainable field updates, related-record automation, screen wizards, and standard declarative paths that fully meet requirements

Choose Apex for complex bulk algorithms, fine-grained recursion control, advanced callouts, and packageable logic that Flow cannot express cleanly

Hybrid patterns—Flow invoking invocable Apex, or Apex launching autolaunched Flow—combine maintainability with code power

Exam “best solution” means simplest platform-aligned option that satisfies every stated requirement, not the most code-heavy design

Before-save Flow often beats a before trigger for simple same-record stamps; triggers/classes win when logic needs maps, re-entrancy guards, or multi-object bulk orchestration

Last updated: August 2026

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:

Completeness — Does the option satisfy every requirement in the stem (including bulk volume, security, and error behavior if mentioned)?

Fit — Is this the Salesforce feature intended for that job (Flow, Approval, validation, trigger, queueable, and so on)?

Simplicity — Among options that fully work, pick the least complex maintainable one.

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

• Requirement signal Why Flow
• Simple same-record field updates on create/update Before-save Flow is efficient and admin-friendly
• Create related Tasks, child records, notifications on save After-save Flow actions
• Guided multi-screen data capture Screen Flow without LWC
• Nightly criteria-based maintenance Scheduled Flow within limits
• Reusable no-UI logic admins can edit Autolaunched Flow / subflows
• Standard multi-step human approval Approval Process (± Flow submit)
• Business team must change criteria often without releases Declarative entry conditions and decisions

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

Requirement signal Why Apex

Complex bulk logic with maps/sets, cross-record aggregation in one transaction, or carefully bulkified multi-object graphs Triggers/services express bulk patterns clearly

Recursive control (static flags, one-time re-entrancy, bypass frameworks) under heavy automation Fine-grained control is awkward or fragile in pure Flow

Callouts with non-trivial auth, chaining, parsing, or error compensation Apex HTTP callouts + async patterns (future/queueable/batch)

Packageable complex algorithms for AppExchange or managed packages Apex classes version, test, and package more naturally

Transactional logic needing custom exception handling and partial success strategies Apex DML options and structured service layers

Performance-critical inner loops over large collections with custom indexing strategies in memory Apex collections and CPU-efficient patterns

Triggers required to enforce rules that must run for all save channels including integrations Centralized trigger handler frameworks

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:

“Admin should be able to update the criteria without code” → Flow / declarative (unless impossible).

“Must work for bulk API updates of 200 records with complex cross-object rules” → bulkified Apex; pure unoptimized Flow loops are suspect.

“Call an external credit service and update the account” → Apex callout path (usually async after save); not a simple before-save Flow alone.

“Guided wizard for agents” → Screen Flow (or LWC if the UI requirements exceed Flow screens—but PDI often stops at Flow when screens suffice).

“Prevent save when formula-expressible condition fails” → Validation rule, not a trigger, when the formula can express it.

“Manager then finance approval with lock” → Approval Process.

“Same record field stamp only” → Before-save Flow over after-save Flow or trigger.

“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

• Choose When
• Before-save Flow Same-record stamps; efficiency; admin ownership
• After-save Flow Related DML, alerts, submit approval, invocable actions
• Screen Flow Human-guided multi-step UX
• Approval Process Multi-step human approve/reject with lock/history
• Apex trigger/service Complex bulk, recursion control, packageable algorithms
• Apex async + callout Integrations after save
• Invocable Apex from Flow Declarative shell, coded core step
• Validation rule Formula-expressible prevent-save rules

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