An interviewer that actually talks back

The question I actually ask is whether the record has an Id yet. In a before trigger it does not, so Trigger.new is still writable and I can set fields with no DML at all. In an after trigger the Id exists, and that is the only reason to be there — related records, anything keyed on Id. Trigger.new is read-only in an after trigger, and touching it throws System.FinalException: Record is read-only. Doing the same field default after the save instead costs an extra update, which re-enters the trigger and spends part of the 100-query budget on a second pass I did not need.

Mechanically it is an @InvocableMethod — static, one per class, taking a List of an inner request class and returning a List, with each input marked up as an @InvocableVariable. Then register it as an Agent Action, attach it to a Topic, and grant the class on the agent user's permission set. What decides whether it ever runs is none of that: the planner reads the label and description on the annotation and the description on each variable, and nothing else. It never sees the body. So description='Cancels an order' competes badly against a sibling Action, and description='Use when the customer asks to stop an order that has not shipped' wins. A vague description is a working Action that is never chosen.

Every path needs a handler, and there are three. A wire puts its failure in error rather than throwing, so the template needs a branch for it. An imperative call rejects, so it needs a catch. And a DML error from Apex is not one message — it arrives as error.body.pageErrors and error.body.fieldErrors, so pulling out error.body.message alone will show undefined for exactly the errors users care about, the validation rules. I normalise all of them through one helper and show the result in a toast, or inline if the error belongs to a field.

Lightning Out. The page includes apex:includeLightning, creates an app reference, and calls $Lightning.createComponent to mount the component into a div. The component needs to be exposed for that target in its metadata, and I need a Lightning app as the dependency container. It is the normal route for modernising a page I cannot replace outright — the old page stays, the new part is a component I can reuse elsewhere.

Before-save updates the record in memory on its way to the database, so there is no second save and no second pass through the automation. That makes it dramatically cheaper than the after-save equivalent, which had to issue its own DML and re-enter the order of execution to change the same field. What it cannot do is the whole reason after-save exists: no related records, no callouts, no email, no Apex actions, and on an insert there is no record Id yet because the row does not exist. So the split is not about preference — anything that only touches Trigger.new-equivalent fields belongs in before-save, and everything else has no choice.

The count is rarely what stops me. The 120 second cumulative budget is, because it is shared: three endpoints at 40 seconds each and the fourth call fails no matter how healthy it is. So I set an explicit setTimeout per call rather than leaving the 10 second default and hoping. The one that actually catches people is You have uncommitted work pending — a callout after DML in the same transaction throws, and the fix is not reordering the statements, it is moving the callout into a Queueable so the DML gets its own transaction to commit in.

Because the bugs that matter in Apex are bulk bugs, and one record cannot see them. A query inside a loop passes with one record and fails at 101; a handler that reads Trigger.new[0] passes with one record and silently ignores the other 199. Inserting 200 in the test is the cheapest way to catch both, and 200 specifically because that is the trigger batch size the platform uses, so it is the size real automation will meet.

When access depends on something the sharing model cannot see. A rule can target owners, roles and groups; it cannot say "the two people named on this record's fields, plus their managers, until the close date passes". For that I insert share rows — AccountShare, or MyObject__Share for a custom object — with the user or group Id, the access level, and a sharing reason I declared on the object. The cost is that it is now code: nothing in Setup explains it, and recalculating after a rule change is something I have to write.

Custom metadata types for configuration that belongs to the application — they deploy with their records, so the same rows exist in every org and a release does not need somebody retyping values in production. Hierarchy custom settings for anything that has to vary by profile or user, because metadata types cannot do that. The other practical difference is limits: Type__mdt.getAll() and a custom setting's getInstance() both read from cache and cost no SOQL query, but a SOQL query against a metadata type does count, which surprises people.

The Import Wizard for small, supervised loads on the objects it supports — up to 50,000 records, with built-in duplicate matching, and no delete. Data Loader for everything else: all objects, up to 5,000,000 records, insert, update, upsert, delete and hard delete, and the Bulk API option for volume. The rule of thumb is that the wizard is for a person doing a one-off and Data Loader is for anything repeatable or large.