Clases de servicio

Soporte está contento: la prioridad ya sale bien. Tan contento que pide más: un botón «Recalcular prioridad» para los casos antiguos, creados antes de que existiera la regla. Y Operaciones quiere revisar cada noche los casos del día. La regla es la misma; lo que cambia es la puerta por la que se entra. Si la regla vive en beforeInsert, ninguna de esas puertas tiene sentido llamándola.

La nutria: Ya lo hacías con subflows

Yo lo hacía constantemente: cuando dos flows necesitaban la misma lógica (calcular un descuento, asignar una cola), la sacaba a un autolaunched flow y la llamaba como subflow desde los dos. Cambiabas la regla una vez y todos la heredaban. Una clase de servicio es eso: el subflow de Apex. El trigger, un botón o un proceso programado son los flows que lo llaman.

Qué es del handler y qué es del servicio

Con la clase de servicio, el handler adelgaza hasta quedarse en lo que de verdad es suyo: decidir qué reglas se aplican en cada evento y en qué orden. Cada método del handler pasa a ser una lista de llamadas al servicio. Los métodos del servicio son static porque no guardan nada entre llamadas: reciben una lista, hacen su trabajo y terminan, como una fórmula que no recuerda la ejecución anterior (Módulo 5).

public with sharing class CaseTriggerHandler {
    public void beforeInsert(List<Case> newCases) {
        CaseEscalationService.applyPriorityRules(newCases);
    }
    public void afterInsert(List<Case> newCases) {
        CaseEscalationService.createReviewTasks(newCases);
    }
}

public with sharing class CaseEscalationService {
    public static void applyPriorityRules(List<Case> cases) { /* la regla */ }
    public static void createReviewTasks(List<Case> cases)  { /* las tareas */ }
}

Quién guarda: la pregunta que decide el diseño

applyPriorityRules cambia la prioridad en memoria y NO hace update. Parece un olvido, pero es la clave. Cuando la llama el handler en before insert, los casos todavía no se han guardado y Salesforce los guardará solo; un update ahí, además, fallaría, porque en un trigger before no se permite hacer DML sobre los propios registros de Trigger.new. Cuando la llama el botón, en cambio, los casos ya existen, y quien tiene que guardarlos es el botón. El servicio cambia los registros; quien lo llama decide si hace falta guardar.

public with sharing class CaseActions {
    // El botón «Recalcular prioridad»: otra puerta, la misma regla
    public static void recalculatePriority(Set<Id> caseIds) {
        List<Case> cases = [
            SELECT Id, Origin, AccountId, Priority
            FROM Case
            WHERE Id IN :caseIds
        ];
        CaseEscalationService.applyPriorityRules(cases);
        update cases;   // aquí sí: estos casos ya existen
    }
}