2.3 Declarative vs Programmatic Decisions

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:

1. Meets all stated requirements (and does not invent unstated ones).
2. Prefers simplest maintainable Salesforce-native approach.
3. Respects governor limits, security, and multi-tenant realities.
4. 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.

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

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

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

1. Code-first vanity — Apex for problems validation rules solve.
2. Flow-or-die — giant unmaintainable automation when Apex would be simpler and safer.
3. UI-only validation — rules only in LWC that API integrations can bypass.
4. Externalize everything — Heroku for trivial CRM field updates.
5. 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.