2.3 Declarative vs Programmatic Decisions

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

2.3 Declarative vs Programmatic Decisions

Key Takeaways Explain This Topic AI

Prefer declarative tools (Flow, validation rules, formula/rollup, App Builder, approvals) when they fully and maintainably meet the requirement

Choose Apex/LWC when logic, UI, bulk complexity, or integration needs exceed declarative capabilities or clarity

Heroku (or similar external platforms) fits specialized compute, custom web apps, or tech stacks outside native multi-tenant Salesforce constraints—not everyday CRM field updates

Exam “best solution” questions reward the simplest platform-aligned option that satisfies all stated requirements

Trade off speed of delivery and admin maintainability against flexibility, testability, and long-term code cost

Last updated: August 2026

2.3 Declarative vs Programmatic Decisions

Quick Answer: Use declarative features when they completely solve the need with acceptable limits and maintainability. Use Apex/LWC when requirements demand complex logic, specialized UI, or patterns declarative tools cannot express cleanly. Use Heroku/external platforms when you need capabilities outside the native multi-tenant Salesforce app model.

The Exam Mindset: “Best” Means Fit, Not Flashiest

Platform Developer I loves scenario stems: A company needs X. Which solution is best? “Best” almost always means:

Meets all stated requirements (and does not invent unstated ones).

Prefers simplest maintainable Salesforce-native approach.

Respects governor limits, security, and multi-tenant realities.

Avoids code when configuration is sufficient—and avoids configuration-only answers when code is clearly required.

You are not scored for writing the most clever Apex. You are scored for choosing the right layer of the platform.

Declarative Customization: Common Use Cases

Declarative means clicks-not-code (or low-code) configuration the platform runs for you.

Need Strong declarative options Notes
Field defaults & simple derived values Formula fields, default values Calculated at read/save per field rules
Parent totals from children (MD) Roll-up summary fields Limited to supported operations/relationships

Point-and-click UI composition Lightning App Builder, page layouts, dynamic forms No Apex required for many UX changes

Record-triggered automation Record-triggered Flows Preferred modern declarative automation path
Guided multi-screen process Screen Flows Great for wizard-like UX without LWC
Entry criteria approvals Approval processes Routing, lock records, submit actions
Simple field-level rules Validation rules Block saves with formulas

Sharing at scale (patterns) Sharing rules, teams, territory (as licensed) Not a substitute for Apex managed sharing in complex cases

Email alerts / outbound messages (legacy patterns) Declarative alert actions Prefer modern integration patterns when appropriate

Reports/dashboards Report Builder Analytics without code
When declarative shines

Business users/admins can maintain rules after handoff.

Logic is well-expressed in Flow formulas, decision elements, and CRUD on related records within limits.

UI needs are standard Lightning composition, not highly custom DOM/UX.

You want faster delivery and fewer deployment artifacts than a full code stack.

Declarative limits you must respect in answers

Declarative is not infinite. Watch for requirements that mention:

Extremely complex branching better unit-tested in Apex
Fine-grained bulk processing patterns with custom locking or elaborate in-memory structures
Pixel-perfect or highly interactive UI beyond Flow/LDS comfort
Callout-heavy orchestration with complex retry/error frameworks
Logic that must run in trigger contexts with careful recursion control and shared handler frameworks
Transactions that need custom exception taxonomies, sophisticated caching, or selector/service layer patterns

If the stem piles on these constraints, declarative-only answers become incomplete.

Programmatic Customization: Apex and LWC
Apex — when code is required (or strongly preferred)

Choose Apex when you need:

Complex business rules spanning multiple objects with nuanced bulk behavior
Trigger-centric enforcement that must run for every DML path (UI, API, integration)
Custom REST/SOAP services, sophisticated callout handling, or platform event consumers with code
Batch/queueable/schedulable processing for large data volumes
Reusable service layers shared by multiple UIs and automations
Logic that is clearer, safer, and more testable in code than in a sprawling flow

Apex is still subject to governor limits—it is not an escape hatch from multi-tenancy. It is a more expressive way to stay within them.

LWC — when custom UI is required

Choose Lightning Web Components when you need:

Interactive UI beyond Screen Flow comfort (complex client state, specialized widgets, advanced UX)
Reusable components dropped on many record pages via App Builder
Performance-sensitive client experiences using modern web standards
Tight integration with Lightning Data Service or Apex for custom reads/writes

Prefer standard Lightning pages + Flow when they meet the UX bar. LWC is powerful; it is also more costly to build and maintain than configuration.

Visualforce still appears

Legacy or specialized cases (certain PDF generation patterns, existing VF investments, some embedded experiences) may still use Visualforce controllers/extensions. On modern greenfield UI, LWC is generally preferred—but exam scenarios may still reference VF correctly as a programmatic UI option.

Decision Framework for “Which Solution Is Best?”

Work the stem in order:

Step 1 — Extract hard requirements

List must-haves: objects touched, user experience, volume, API access, callouts, admin maintainability, timing (before save vs after), and whether logic must fire for all entry points.

Step 2 — Can declarative fully cover it?

If yes—and no constraint forbids it—pick the most specific declarative tool :

Validation rule for simple field comparisons on one record
Flow for multi-step updates, branching, and orchestration
Approval process for submit/approve/reject routing
Formula/rollup for calculated display/storage within their rules
App Builder/layouts for arrangement-only UI changes
Step 3 — If code is needed, pick the right code surface
Apex trigger + handler for database event enforcement
Apex service/invocable for reusable logic callable from Flow and LWC
LWC for custom UI
Async Apex when synchronous limits or user wait time demand it
Step 4 — Consider platform boundaries

If the need is a full custom web application, polyglot microservices, long-running non-Salesforce compute, or OS-level control, look outside native app customization—commonly Heroku or another external system— integrated with Salesforce via APIs, events, or middleware.

Quick chooser

Requirement signal Lean toward
Admin-owned simple automation Flow / validation / formula
Multi-object bulk-safe complex rules Apex
Custom interactive UI LWC (or Flow screens if simple)
Large data volumes overnight Batch Apex (or external ETL when appropriate)
Specialized Node/Java app + Salesforce data Heroku (or similar) + integration
Only rearrange fields on record page App Builder / layouts
Heroku vs Native Salesforce

Heroku is an external application platform (part of the broader Salesforce ecosystem story) used for apps and services that do not fit neatly inside org metadata and multi-tenant Apex limits.

Good Heroku / external platform use cases
Customer-facing web/mobile apps with custom stacks and scaling models
CPU-heavy or long-running compute unsuitable for synchronous Apex transactions
Using languages/frameworks not hosted as Apex
Isolating workloads that need different compliance or runtime characteristics
Microservices that integrate to Salesforce as a system of record
Poor Heroku answers on the exam
Updating a field when Opportunity stage changes (use Flow/Apex)
Adding a related list or simple wizard (use App Builder/Flow/LWC)
Enforcing a validation on save (validation rule/Apex trigger)
Anything fully solvable with native declarative or modest Apex/LWC

If a distractor says “build a Heroku app” for ordinary CRM automation, it is almost certainly wrong.

Maintenance and Cost Tradeoffs

Approach Build speed (typical) Who maintains Flexibility Test/deploy cost

Declarative Fast for medium problems Admins + developers Bounded by tool features Lower ceremony; still needs UAT

Apex Medium–slower Developers High within platform limits Unit tests required; CI discipline
LWC Medium–slower Developers High UI flexibility Jest/UI testing practices + Apex tests for server

Heroku/external Variable; often higher end-to-end DevOps + developers Highest outside platform Separate app lifecycle, auth, monitoring

Total cost of ownership includes debugging, package upgrades, release management, and who can safely change production . A clever 2,000-element flow can cost more than a clean Apex service. Conversely, writing Apex for a one-line validation rule wastes budget and blocks admin agility.

Exam-friendly tradeoff language

Prefer declarative for clarity and admin maintainability when complete.

Prefer Apex when complexity, bulk, or multi-channel enforcement demands it.

Prefer LWC when UX requirements exceed declarative UI tools.

Prefer external platforms when native multi-tenant constraints cannot meet non-CRM app needs.

Worked Scenarios
Scenario A — stage-based task creation

When Case status becomes Escalated, create a Task for the owner and email a queue.

Best lean: Record-triggered Flow (declarative). Apex is unnecessary unless extra complexity is stated.

Scenario B — prevent save across related histories

Before Opportunity closes, evaluate custom child metrics, related contracts, and historical usage objects with bulk API loads in mind.

Best lean: Apex trigger/service (programmatic) with bulkification; possibly invocable Apex if Flow orchestrates UX but code does the heavy rule evaluation.

Scenario C — animated product configurator UI

Sales needs a highly interactive configurator embedded on the Opportunity page with client-side state and custom rendering.

Best lean: LWC (+ Apex as needed). Screen Flow may be too limited if the stem stresses rich interaction.

Scenario D — public marketing site with custom Node services

Company wants a public site with custom Node.js services and Salesforce as system of record for leads.

Best lean: External app platform (e.g., Heroku) integrated to Salesforce—not pure Apex pages for the entire public stack—unless the exam points to Experience Cloud with specific constraints.

Scenario E — rearrange fields only

Users want fields in two columns with a highlight panel change.

Best lean: Lightning page / layout configuration—not LWC, not Apex, not Heroku.

Anti-Patterns the Exam Punishes

Code-first vanity — Apex for problems validation rules solve.

Flow-or-die — giant unmaintainable automation when Apex would be simpler and safer.

UI-only validation — rules only in LWC that API integrations can bypass.

Externalize everything — Heroku for trivial CRM field updates.

Ignoring bulk/API paths — choosing a tool that only works for interactive UI clicks.

Practical Study Checklist

Before selecting an answer option, ask:

Does declarative cover every requirement in the stem?

Must logic run for API and UI equally?

Is the UI standard, Flow, or fully custom ?

Is volume/async/callout complexity stated?

Is the workload still a native Salesforce app problem?

If you practice that checklist on sample scenarios, declarative-vs-programmatic items become systematic instead of guesswork. This decision skill also transfers to real projects: ship the lightest solution that remains correct under multi-tenant limits and long-term maintenance reality.