Checkpoint del Módulo 7

Las cuatro tareas anteriores no añadieron ni una sola funcionalidad que Soporte pudiera ver: ordenaron. Esta es la tarea en la que se cobra ese trabajo. Llega una regla nueva, y la diferencia entre una org ordenada y una que no lo está es cuánto hay que tocar para meterla.

Lo que has construido, capa por capa

1 · Un trigger por objeto. Como en Flow Trigger Explorer pero sin campo de orden: la única manera de controlar el orden es que no haya dos. Dentro, switch on Trigger.operationType decide el evento y nada más. Importa porque dos triggers «que funcionan» dan resultados distintos según el día.

2 · El handler. El trigger es el Start del flow; el handler, el lienzo. Un método por evento, que recibe Trigger.new por parámetro para no depender del contexto. Importa porque el trigger cabe en una pantalla aunque el objeto tenga veinte reglas.

3 · El servicio. El subflow de Apex: métodos static que reciben listas y no saben nada de triggers, así que el trigger, un botón o un proceso nocturno los llaman igual. Cambia los registros; guardar es cosa de quien lo llama. Importa porque una regla que cambia se cambia en un solo sitio.

4 · La guardia y el interruptor. Un static Set<Id> en el servicio impide hacer dos veces lo mismo en una transacción, incluso cuando una regla de workflow vuelve a disparar el trigger con el Trigger.old de antes. Y un permiso personalizado apaga todas las reglas para quien hace una migración, igual que tu NOT($Permission.Bypass…) en las reglas de validación.

La regla nueva: el traspaso de Soporte a Ventas

Ventas se queja de que se entera tarde de los problemas de sus clientes. La regla: cuando se CIERRA un caso de prioridad 'High' de una cuenta, el propietario de esa cuenta (el comercial, no el agente) recibe una tarea de seguimiento para el día siguiente. Fíjate en tres decisiones antes de escribir nada.

• ¿Qué evento? «Cuando se cierra» es un cambio sobre un registro que ya existe: after update, comparando IsClosed nuevo con el de oldMap. El trigger ya escucha after update: no se toca.
• ¿En qué servicio? Es una regla de Ventas, no de escalado. Meterla en CaseEscalationService mezclaría dos negocios; merece su propia clase, CaseHandoffService. El handler solo añade una línea.
• ¿Qué protecciones? Su propia guardia (la de tasksCreatedFor es de otra regla) y el interruptor… que ya existe arriba del trigger y la cubre sin hacer nada.

La nutria: El propietario de la cuenta, no el del caso

Aquí tropecé yo la primera vez: el caso tiene su propietario (el agente o la cola) y la cuenta, el suyo (el comercial). Para llegar al segundo hay que subir del caso a la cuenta: una consulta con los AccountId de todos los casos, como en el Módulo 3, y un Map para encontrar cada uno sin recorrer nada. En Flow habría sido un Get Records; aquí, uno para todos los casos a la vez.

Lo que viene: el Módulo 8

Todo este módulo ha supuesto que las cosas salen bien. ¿Y si el comercial de una cuenta está inactivo y la tarea no se puede asignar? ¿Y si Soporte quiere impedir cerrar un caso sin una solución escrita, con un mensaje en pantalla como una regla de validación? Eso son excepciones y addError, y es el Módulo 8.