The official Salesforce guidance is unambiguous: use declarative tools first, Apex only when configuration cannot solve the problem. Flow, validation rules, formula fields, and approval processes should be your first stop. Apex is the escape hatch when the platform’s no-code surface can’t express the rule cleanly, safely, or performantly.
When Apex is the right tool
Reach for Apex in these scenarios:
- Complex business logic that Flow would model with deeply nested decisions, fault paths, and assignments — at some point Flow becomes harder to maintain than a well-written handler class.
- Callouts to external systems where you need fine-grained control over the HTTP request, retries, response parsing, or named credentials —
HttpCalloutandHttpRequestgive you this. (Flow’s HTTP Callout action is fine for simple GETs; it isn’t for OAuth flows or complex payloads.) - Bulk operations beyond Flow’s limits — Flow has its own governor limits, and processing 200 records with many SOQL queries inside a Flow loop will fail. Apex with proper bulkification handles 10,000+ rows in batch jobs.
- Asynchronous work —
@future,Queueable,Batch Apex, andSchedulableare the only ways to defer expensive work off the synchronous transaction. - Custom REST or SOAP endpoints — exposing your org as a service via
@RestResourceor@WebServicerequires Apex. - Lightning Web Component server methods —
@AuraEnabledcontrollers run Apex on the server for LWCs that need data the wire service can’t fetch. - Trigger logic that runs before/after DML events on objects.
When NOT to use Apex
Apex carries real costs:
- Test coverage — you cannot deploy Apex to production without 75% coverage. Flows have no such requirement.
- Maintenance debt — admins can edit Flows; only developers can change Apex.
- Governor limit exposure — bad Apex blows limits and breaks transactions; bad Flow usually fails more gracefully.
If a validation rule, formula field, or simple Flow can do the job, do not write Apex. The Salesforce architect community calls this the clicks-not-code principle, and it holds up across release after release.
A decision shortcut
| Requirement | Use |
|---|---|
| Field validation | Validation rule |
| Derived value from same record | Formula field |
| Roll-up on a master-detail | Roll-up summary |
| Record updates on events | Flow (Record-Triggered) |
| Multi-step business process with branching | Flow |
| Cross-system callouts beyond simple HTTP | Apex |
| Bulk data processing (> 2,000 records) | Batch Apex |
| Scheduled jobs | Schedulable Apex |
| Custom REST/SOAP API | Apex @RestResource |
| LWC server-side data | @AuraEnabled Apex |
| Trigger logic beyond Flow’s record-triggered scope | Apex Trigger |
What interviewers are really looking for
The signal here is judgement. A developer who reaches for Apex first looks expensive — they’ll write code where a formula would do. A developer who knows when to step up to Apex and why is the one teams want. Mention test coverage, maintenance handoff to admins, and Flow’s bulkification limits, and you’ve answered the real question.
Verified against: Apex Developer Guide — Introducing Apex, Trailhead module Apex Basics for Admins. Last reviewed 2026-05-17 for Spring ‘26 release.