before vs after

En la lección anterior viste que Trigger.new se puede cambiar en before y no en after. No es una regla caprichosa: sale directamente de en qué momento del guardado se ejecuta cada uno. Entender ese momento te dice, casi siempre, qué evento elegir.

La nutria: El paralelo de Admin

Cuando creaba un Record-Triggered Flow, Salesforce me preguntaba para qué optimizarlo. «Fast Field Updates» corre antes de guardar y solo puede cambiar campos del propio registro: por eso es tan rápido. «Actions and Related Records» corre después y puede crear tareas, actualizar la cuenta o mandar correos. Es exactamente before y after. Si alguna vez elegiste bien entre esas dos opciones, ya sabes la mitad de esta lección.

before: cambiar el propio registro, gratis

En before, el registro está en camino hacia la base de datos pero todavía no ha llegado. Si le cambias un campo, ese cambio viaja con él. No hace falta update, y no debes hacerlo: el guardado ya está en marcha. Es el sitio para rellenar valores por defecto, normalizar textos (el trim y toUpperCase del Módulo 1) o calcular un campo a partir de otros.

trigger LeadClean on Lead (before insert, before update) {
    for (Lead l : Trigger.new) {
        if (l.Company != null) {
            l.Company = l.Company.trim();
        }
        if (String.isBlank(l.LeadSource)) {
            l.LeadSource = 'Web';
        }
    }
    // ni una consulta, ni un DML: el guardado ya está en marcha
}

after: el Id existe y puedes tocar otros registros

En after, el registro ya se ha escrito (aunque todavía no se ha confirmado). Eso trae dos cosas. Primero, en insert ya tiene Id, así que puedes crear hijos que apunten a él: tareas, contactos, líneas. Segundo, Trigger.new pasa a ser de solo lectura: el registro ya se escribió y cambiarle un campo en memoria no serviría de nada. Si necesitas modificar otros registros, lo haces como en el Módulo 4: construyes una lista y haces un solo DML.

trigger AccountOnboarding on Account (after insert) {
    List<Task> tasks = new List<Task>();
    for (Account a : Trigger.new) {
        tasks.add(new Task(
            WhatId = a.Id,              // el Id ya existe
            OwnerId = a.OwnerId,
            Subject = 'Llamada de bienvenida',
            ActivityDate = Date.today().addDays(3)
        ));
    }
    insert tasks;                       // un DML para todo el lote
}

El error típico: arreglar en after lo que era de before

Como en after no puedes cambiar Trigger.new, hay quien consulta los mismos registros y les hace update. Funciona, pero es el peor de los mundos: gasta una consulta y un DML que en before no necesitabas, el registro se guarda dos veces, y ese segundo update vuelve a disparar el trigger de update. Es el origen clásico de la recursión de la lección 5.

La nutria: Tus flows y tu Apex comparten los mismos límites

Un detalle que yo descubrí tarde, como muchos Admins: cuando un registro se guarda, todos los flows y todos los triggers que dispara corren en la MISMA transacción, y comparten sus límites. Si un flow after-save hace tres Update Records y un trigger hace dos inserts, ya son cinco de los 150 DML disponibles. Por eso hacer en before lo que se puede hacer en before no es una manía: cada DML que te ahorras es margen para toda la automatización del objeto.

La nutria: ¿Y por qué no un Flow? Porque Account ya tiene trigger

Los dos flows del alta funcionaban. Pero Account ya tiene el trigger de otro equipo (el de la tarea 5), y con dos flows más el objeto tenía tres puntos de entrada: justo la mezcla que la guía de Salesforce pide evitar, porque nadie ve de un vistazo qué pasa al guardar una cuenta. Un solo trigger con sus dos momentos, before y after, lo deja todo en un sitio.