Orden de ejecución en Salesforce

«La regla de validación salta aunque mi trigger ya rellenó el campo.» «El flow ve el valor viejo.» «El roll-up no se actualiza hasta que refresco.» Casi todos los misterios de automatización en Salesforce se resuelven con la misma herramienta: saber en qué orden ocurren las cosas cuando se guarda un registro. Salesforce lo llama orden de ejecución, y es de lo más preguntado en el examen Platform Developer I.

La nutria: El paralelo de Admin

Yo usaba Flow Trigger Explorer para ver, en un objeto, qué flows corren antes de guardar y cuáles después, y para ordenarlos entre sí. Es un trozo del orden de ejecución. Aquí vas a ver el mapa completo: dónde encajan tus triggers, tus validation rules, las reglas de asignación, los workflows heredados y los roll-ups, todo en la misma línea de tiempo.

El recorrido de un guardado, paso a paso

Pulsa Reproducir y sigue al registro. Puedes pararlo, ir hacia atrás o pulsar cualquier paso para leer qué ocurre en él. Los dos pasos marcados como «tu código» son tus triggers.

Cinco consecuencias que te ahorran horas

1. Los flows «Fast Field Updates» corren antes que tus triggers before. Si los dos tocan el mismo campo, gana el trigger, porque escribe el último.
2. Las validation rules corren después de los triggers before. Por eso un trigger before puede rellenar un campo que una regla de validación exige, y la regla ya lo verá relleno.
3. Los triggers after corren antes que los flows «Actions and Related Records». Si un flow after necesita algo que crea tu trigger after, ya estará.
4. Un roll-up en el padre no es parte de tu guardado: el padre pasa por su propio guardado, con su propio orden de ejecución y sus propios triggers.
5. Nada es definitivo hasta el commit. Si un flow after-save falla, también se deshace lo que hizo tu trigger before. Es la misma transacción del Módulo 4, con el mismo presupuesto de límites.

Un caso práctico: rellenar lo que la validación exige

Imagina una regla de validación en Contact: «el país es obligatorio». Los contactos que llegan de una integración vienen sin país, pero su cuenta sí lo tiene. Como los triggers before corren antes que las validation rules, un trigger before insert puede copiar el país de la cuenta antes de que la regla mire. La consulta a la cuenta se hace con la receta del Módulo 4: juntar Ids, una consulta, un Map.

trigger ContactCountry on Contact (before insert) {
    Set<Id> accountIds = new Set<Id>();
    for (Contact c : Trigger.new) {
        if (String.isBlank(c.MailingCountry) && c.AccountId != null) {
            accountIds.add(c.AccountId);
        }
    }

    Map<Id, Account> accounts = new Map<Id, Account>(
        [SELECT Id, BillingCountry FROM Account WHERE Id IN :accountIds]
    );

    for (Contact c : Trigger.new) {
        Account acc = accounts.get(c.AccountId);
        if (String.isBlank(c.MailingCountry) && acc != null) {
            c.MailingCountry = acc.BillingCountry;   // antes de que mire la validación
        }
    }
}

La nutria: Ver el orden de verdad: los Debug Logs

Mi consejo: no imagines el orden de ejecución, míralo. Setup → Debug Logs → añade un Trace Flag para tu usuario, guarda un registro y abre el log. Aparecen, en el orden real en que ocurrieron, tus triggers, las reglas de validación que se evaluaron y los flows que se lanzaron. Cuando algo «a veces sale mal», el log es la primera parada, igual que el historial de un flow cuando depurabas con clics.

La nutria: ¿Y por qué no un Flow? La salida en Flow existía

Te lo cuento como fue: el flow after-save llegaba tarde a la regla de validación, y la salida en Flow era pasarlo a before-save, que corre antes que las reglas de validación y puede leer $Record.Account.BillingCountry. Se migró porque la integración de eventos ya tenía un trigger en Contact y la guía de Salesforce pide no mezclar. Lo que te llevas de esta lección, el orden de ejecución, vale igual para los dos.