Exam checklist

• Flow types & before-save vs after-save ordering · Flow-vs-Apex decision criteria · declarative-first principle
• Apex OOP: access modifiers, static/final, interfaces vs abstract classes, enums, Comparable
• Collections: List/Set/Map gotchas, sObject casting, Iterable/Iterator
• Trigger recursion prevention, handler pattern, undefined multi-trigger order
• Async Apex + Invocable Methods (the Flow ↔ Apex bridge, bulkification contract)
• Formula vs Roll-Up Summary (and what to do when neither works) · Custom Metadata/Settings/Labels · Platform Events vs CDC

Flow types

Full order of execution — with Flow's exact position ⭐

Flow Builder elements to know

• Data elements: Get Records, Create Records, Update Records, Delete Records (each configurable for filters/sort/how-many)
• Logic elements: Decision (branching outcomes), Loop (iterates a collection, "for each" + after-last exit), Assignment (set variable values)
• Screen components: input fields, display text, choice/picklist — Screen Flows only
• Subflow: calls another flow

Access modifiers — exact rules ⭐

Enums, inner classes, constructors & the Comparable interface

public enum Season { WINTER, SPRING, SUMMER, FALL }

public class Employee implements Comparable {
    public Decimal salary;
    public Integer compareTo(Object compareTo) {
        Employee that = (Employee) compareTo;
        return this.salary == that.salary ? 0
             : this.salary > that.salary ? 1 : -1;
    }
}
// employees.sort();  -- now sorts by salary

• Enums are backed by integers in declaration order; cannot add methods; can't be a generic type parameter.
• Inner classes can be public/private/virtual/abstract, but not global unless the outer class is global too.
• Apex has no default/named parameters — overload constructors/methods explicitly instead.
• Comparable is required to .sort() a List of custom objects — must return negative/0/positive, and must handle nulls explicitly. System.Comparator<T> lets you pass an external comparator instead of modifying the class.

sObject casting

SObject s = new Account(Name = 'Acme');
Account a = (Account) s;              // OK — safe downcast

SObject s2 = new Contact();
Account bad = (Account) s2;           // throws System.TypeException at RUNTIME
                                       // (not a compile error!)

Casting between unrelated sObject types compiles fine but throws at runtime — a classic exam trap for candidates expecting a compile-time catch.

Recursive trigger prevention (static boolean guard)

public class TriggerHandler {
    public static Boolean isFirstRun = true;
}

trigger AccountTrigger on Account (before update) {
    if (TriggerHandler.isFirstRun) {
        TriggerHandler.isFirstRun = false;
        // logic that might re-fire this trigger via its own DML
    }
}

Works because static variables persist for the whole transaction — a second entry into the trigger within the same transaction sees the flag already flipped.

Why "one trigger per object" is best practice ⭐

• Best practice: a single thin trigger per object dispatches to a Handler class (beforeInsert(), afterUpdate(), etc.) — keeps logic testable and centralized.
• The real reason: if multiple triggers exist for the same object + event (e.g., two before update triggers on Account), the order they fire in is undefined/unpredictable by Salesforce.
• Each trigger still receives the full Trigger.new/Trigger.old list for the whole bulk operation, but a later-firing trigger will see whatever mutations an earlier (unknown-which) trigger already made — pure uncertainty.

Async Apex quick recap

@InvocableMethod — exact contract ⭐

public class AccountScoreAction {
    @InvocableMethod(label='Score Accounts' description='Returns risk score')
    public static List<Result> scoreAccounts(List<Request> requests) {
        List<Result> results = new List<Result>();
        for (Request r : requests) {
            Result res = new Result();
            res.score = r.revenue > 1000000 ? 'High' : 'Low';
            results.add(res);
        }
        return results;
    }
    public class Request {
        @InvocableVariable(required=true)
        public Decimal revenue;
    }
    public class Result {
        @InvocableVariable
        public String score;
    }
}

• Method must be public static (or global static), on a top-level class. Only one @InvocableMethod per class.
• Parameter must be exactly one List<T> — even though each Flow interview logically passes "one record," Flow batches (boxcars) multiple invocations into a single Apex call.
• Return type is void or a List<T> of a class with @InvocableVariable fields.

When native roll-up isn't possible — alternatives

1. Relationship is Lookup, not Master-Detail → use an Apex trigger, a record-triggered Flow that aggregates and updates the parent, or a free tool like DLRS (Declarative Lookup Rollup Summaries).
2. Need aggregation beyond COUNT/SUM/MIN/MAX (median, weighted average) → must use Apex.
3. Need real-time recalculation without child DML (e.g., time-based) → a formula field, not a roll-up (roll-ups only recalc on child DML).

Custom Metadata Type vs Custom Setting vs Custom Label ⭐

Platform Events vs Change Data Capture

• Platform Events — custom event objects (MyEvent__e), explicitly published via EventBus.publish() (Apex/Flow/REST), consumed by subscribers. Fire-and-forget, pub/sub, decoupled — good for custom business events.
• Change Data Capture (CDC) — automatically publishes change events (ObjectName__ChangeEvent) whenever a record is created/updated/deleted/undeleted, after commit. You enable it on the object; you don't write publish code.

Custom exceptions & chaining

public class OrderException extends Exception {}

try {
    processOrder();
} catch (DmlException original) {
    throw new OrderException('Order failed', original);   // chaining
}
// later: ex.getCause() retrieves the original DmlException

Custom exceptions must extend Exception; Apex auto-generates constructors accepting (String message) and (String message, Exception cause).

Built-in exceptions — exact behavior

• Multiple catch blocks are matched top-to-bottom — most specific first, generic Exception last. Apex actually enforces this: an unreachable catch block (generic before specific) is a compile error.
• finally always executes, regardless of a return or throw in try/catch.