Cuatro formas en que una regla que se lee bien hace lo incorrecto. Las cuatro son baratas de evitar y caras de descubrir con un cliente real.
Cadenas que no encadenan
Lo natural es pensar que la regla A mueve la tarea a En revisión, y la regla B observa Estado cambiado, así que B se ejecuta después. No pasa. Un estado, una fase o un estado de revisión cambiado por una automatización no dispara tus reglas de Estado cambiado, Fase cambiada ni Estado de revisión cambiado.
Pon los pasos en una sola regla. Una automatización puede ejecutar varias acciones en orden, y así es como las reglas incluidas mueven una tarea, la marcan para revisión y comparten el video en un solo paso.
Los bloqueos son la excepción, y es a propósito. Una regla que define o quita un bloqueo sí dispara tus reglas de Bloqueo agregado y Bloqueo quitado, porque si no, un bloqueo quitado por una regla dejaría el reloj del plazo pausado para siempre. Esa excepción provoca la siguiente trampa.
El orden de acciones que se deshace solo
Quitar un bloqueo dispara tus reglas de Bloqueo quitado, y el conjunto incluido tiene una que devuelve la tarea a Por iniciar. Así que una regla escrita como:
- Cambiar estado En curso
- Definir bloqueo Quitar bloqueo
termina con la tarea en Por iniciar, porque quitar el bloqueo se ejecutó en segundo lugar y su propia cadena sobrescribió tu estado.
Escríbela al revés: primero quita el bloqueo y al final define el estado. Las acciones se ejecutan en el orden en que las listas, así que la última acción gana.
Reglas que llegan al cliente en el momento equivocado
Todo lo que solo mueve un campo se puede recuperar. Enviar correo, Activar compartir video y Disparar webhook, no, porque un cliente que recibió un corte no puede “desrecibirlo”.
Vincula las acciones que llegan al cliente al paso que significa que terminaste, como una subtarea de revisión completada o un bloqueo que defines a mano, y no a un disparador amplio como Video subido. Mantén exactamente una regla que le envíe correos a un cliente, porque con dos es como un cliente recibe la misma entrega dos veces. Y mientras tu proceso de revisión todavía se está asentando, deja manual la decisión de enviar al cliente: Enviar al cliente es un clic, así que la regla te ahorra el clic, no el criterio.
Probar con un cliente real
Crea un cliente llamado Prueba, con su propio código interno, y pasa cada regla nueva primero por una tarea de ese cliente. El tablero se comporta igual, y las alarmas y los cambios de estado quedan dentro de tu espacio de trabajo.
El cliente de prueba solo te aísla cuando pones tu propia dirección como su contacto. Una acción Enviar correo con el destinatario client va a los contactos configurados del cliente, así que con una lista de contactos vacía o real el correo sale exactamente como saldría en producción.
Disparar webhook sigue activo en cualquier caso, porque el endpoint se configura por espacio de trabajo y no por cliente. Una regla de webhook se dispara contra tu endpoint real incluso desde una tarea de prueba, así que apúntala a una URL de prueba mientras experimentas, o deja la acción de webhook fuera de la regla hasta que el resto funcione.
Cuando una regla te sorprenda, el historial de actividad de la tarea indica qué automatización hizo el cambio, así encuentras la regla en lugar de adivinar: Ver quién cambió qué en una tarea.
Atención: No hay un historial de ejecuciones de automatizaciones que puedas consultar. El historial de actividad de la tarea es el registro, otra razón para probar en una tarea que controlas en lugar de mirar todo el tablero.
Siguiente paso
Arma un tablero que quepa en una pantalla. La mayoría de los problemas de automatización terminan siendo problemas de forma del flujo de trabajo.