📖 Read · 20 XP

Flow vs Apex: choosing the right tool

Flow vs Apex: choosing the right tool

You now know the declarative toolbox. Here's the decision guide pros actually use:

Choose declarative when…

Requirement	Tool
Show a calculated value	Formula
Summarise children (master-detail)	Roll-up summary
Block invalid data	Validation rule
Update fields on the same record when it's saved	Before-save flow
Create/update related records, send email, simple logic	After-save flow
Guided UI wizard	Screen flow
Run something on a schedule (simple)	Scheduled flow

Choose Apex when…

• The logic is complex (nested loops, maps, recursion, heavy string or JSON work)
• You're processing large volumes and need precise control over limits (Batch Apex)
• You need integrations with custom auth, error handling and retries
• You need unit-tested, reusable services shared across many automations
• Flow would be so big that no admin could maintain it anyway

The hybrid pattern

These aren't enemies. A very common pattern is a Flow that calls Apex: admins own the orchestration, and developers write a small, tested @InvocableMethod for the hard part.

public with sharing class QuestScorer {
    @InvocableMethod(label='Score Quests')
    public static List<Integer> score(List<Id> questIds) {
        // complex logic here, bulk-safe and tested
        return new List<Integer>();
    }
}

🦝 That's the end of the Platform Orientation track. Next stop: Apex. Quill is stretching.