Qué es un trigger y cuándo se dispara

Hasta ahora tu código se ejecutaba cuando tú lo lanzabas: pulsabas Execute en la Developer Console y ya. Un trigger es distinto: nadie lo lanza. Salesforce lo ejecuta solo, cada vez que ocurre algo con un registro. Es el paso que convierte lo aprendido en los Módulos 3, 4 y 5 en automatización de verdad.

La nutria: El paralelo de Admin

Tú ya construiste esto con clics, como yo. Un Record-Triggered Flow empieza con tres preguntas: sobre qué objeto, cuándo (se crea, se actualiza, se crea o actualiza, se borra) y si optimizas para «Fast Field Updates» o para «Actions and Related Records». Un trigger responde a las mismas tres preguntas, en una sola línea de código.

La anatomía

trigger AccountOnboarding on Account (before insert, after insert) {
    // tu lógica
}

trigger LeadWelcome on Lead (after insert) {
    for (Lead l : Trigger.new) {
        System.debug('Nuevo lead: ' + l.LastName + ' · ' + l.Company);
    }
}

• trigger: la palabra clave. Un trigger vive en su propio archivo, igual que una clase del Módulo 5.
• El nombre: por convención, el objeto seguido de lo que hace o de «Trigger» (LeadWelcome, OpportunityTrigger).
• on Lead: un solo objeto por trigger, por su nombre de API (Invoice__c si es personalizado).
• (after insert): uno o varios eventos, separados por comas.

Los siete eventos

Un evento combina dos cosas: la operación (insert, update, delete, undelete) y el momento (before, antes de guardar; after, después de guardar). La diferencia entre before y after es la lección 3; por ahora quédate con que existen los dos.

Siempre llega una lista

Es la diferencia más importante con Flow. Un flow trabaja con un registro, $Record, y Salesforce agrupa por ti las interviews. Un trigger recibe todo el lote a la vez en Trigger.new, que es una List: uno si alguien guarda desde la pantalla, hasta 200 si llegan de Data Loader. Por eso el código de dentro es un for: aquí bulkificar no es un consejo, es la forma en que llegan los datos.

Dónde se escribe un trigger… y dónde no

Un flow lo puedes crear y activar directamente en producción; un trigger no. Se escribe en un sandbox o en una Developer Org y se despliega, como un change set, con una condición más: el despliegue solo se acepta si los tests cubren al menos el 75 % del código (Módulo 10). Tu Developer Org es tu laboratorio: en ella sí escribes directamente.

El encargo de este módulo

La nutria: Los seis flows que se migran

Northwind ha decidido migrar a Apex seis de sus flows, y nos toca a nosotros, un taller por flow: 1 · el registro de leads del formulario web; 2 · el rastro de cambios de etapa; 3 · el alta de cuentas con su tarea de bienvenida; 4 · el país de los contactos; 5 · la revisión de oportunidades que se pelea con otro equipo; 6 · el escalado de casos de Soporte, que el Módulo 7 convertirá en una arquitectura profesional.

La nutria: ¿Y por qué migrar flows que funcionan?

Buena pregunta, y la respuesta oficial es de Salesforce: su guía de decisión dice que para cambiar campos del propio registro, el flow before-save es la primera opción. Apex se recomienda cuando hace falta volumen alto, Map y Set (que Flow no tiene), savepoints, reaccionar a undelete, varios errores por campo o una memoria que dure toda la transacción. Y pide no mezclar flows y triggers como punto de entrada del mismo objeto. Cada flow de Northwind se migra por una de esas razones, y en cada lección te digo cuál.

La nutria: ¿Y por qué no un Flow? Porque Flow no escribe en el log

El flow de Marketing no podía escribir sus propios mensajes en el debug log: Flow no tiene nada parecido a System.debug. Así que creaba un registro de un objeto de log por cada lead, y con las cargas nocturnas eran cientos de registros más al día ocupando almacenamiento. En Apex, System.debug escribe en el log sin guardar nada. Es el flow más sencillo, y por eso es el primero.