Reglas de tareas
Una regla de tarea es un paso automático del tipo «cuando ocurre un evento y se cumplen las condiciones, ejecuta una acción». Las reglas eliminan la rutina manual: no hace falta cambiar el estado a mano, asignar un responsable, fijar una fecha límite ni escribir un comentario repetitivo; el portal lo hace por sí mismo según el proceso que usted describa.
Las reglas se configuran en la página de automatización de tareas, en la dirección /tasks/automation, pestaña «Reglas». Es el puesto de trabajo del administrador del proceso de tareas.
Cuándo se necesitan reglas de tareas
Conviene crear una regla allí donde se repite el mismo paso manual sobre las tareas. Casos típicos:
- al crear una tarea de cierto tipo, asignar de inmediato un responsable;
- al pasar la tarea al estado «En revisión», fijar una fecha límite y notificar al supervisor;
- al añadir un comentario del cliente, cambiar la prioridad;
- al cambiar la fecha límite, crear automáticamente una subtarea de recordatorio.
Si el paso ocurre rara vez o cada vez es distinto, no hace falta una regla: es más sencillo hacerlo a mano.
Dónde configurar
Abra /tasks/automation. La página de automatización de tareas se divide en pestañas:
- Reglas — evento → condiciones → acción;
- Verificaciones — verificaciones bloqueantes antes de la operación (ver Verificaciones de protección);
- Periódicas — tareas programadas (ver Tareas periódicas);
- Historial — qué se ejecutó y cuándo.
Esta página trata sobre la pestaña «Reglas». Para gestionarlas se necesitan permisos de automatización de tareas; sin ellos, las reglas solo se ven en modo lectura.
De qué se compone una regla
Cada regla se arma a partir de tres partes:
- Disparador — el evento que pone en marcha la regla.
- Condiciones — verificaciones adicionales bajo las cuales la regla se ejecuta (opcionales).
- Acción — lo que hará el portal. En una regla de tarea la acción es una sola.
Primero describa el proceso con palabras: «cuando… y si… — entonces…», y solo después trasládelo al formulario de la regla.
Disparadores
El disparador se elige de un conjunto de eventos sobre la tarea:
- tarea creada;
- tarea modificada;
- cambió el estado;
- cambió la fecha límite;
- se añadió un comentario;
- se registró tiempo.
Para los eventos de cambio de campo (estado, fecha límite) se puede precisar de qué valor y a qué valor se produjo la transición; esto convierte un disparador general en uno puntual.
Condiciones
Las condiciones acotan la ejecución para que la regla no actúe sobre todas las tareas por igual. Una condición verifica un campo de la tarea: por ejemplo, solo un proyecto, prioridad o tipo determinado, o una transición concreta «de» → «a». Varias condiciones se combinan entre sí, de modo que la regla se ejecuta solo sobre el segmento de tareas que corresponde.
Cuanto más precisas sean las condiciones, menos disparos falsos habrá y más claro será el historial de ejecuciones.
Acción
En una regla de tarea se ejecuta una sola acción. Las acciones disponibles incluyen:
- cambiar el estado;
- asignar un responsable;
- fijar o desplazar la fecha límite;
- añadir un comentario;
- notificar a los participantes;
- crear una subtarea;
- crear una oportunidad vinculada en el CRM.
Si por un mismo evento se necesitan varias acciones en cadena o ramificación, eso ya no es una regla de tarea, sino un robot de CRM o un flujo de trabajo.
Vista previa antes de activar
Antes de activar la regla, ejecútela mediante la vista previa (simulación): el portal mostrará a qué tareas se aplicaría la regla y qué haría, sin modificar los datos. La vista previa está disponible según el permiso correspondiente.
La vista previa es la principal forma de no romper el trabajo: en ella se ven las condiciones demasiado amplias y los disparos inesperados antes de que la regla afecte a tareas reales.
Activación y propiedad
La regla empieza a funcionar solo después de activarla. Cada regla debe tener un propietario claro: la persona responsable del proceso y a quien acudir con preguntas. El historial de cambios de la regla se ve en la lista: quién la modificó y cuándo.
No active una regla «de prueba» sobre tareas reales sin vista previa y sin propietario: una regla olvidada con condiciones amplias genera ruido y errores.
Estados y limitaciones
- regla desactivada — no se ejecuta;
- la vista previa no encontró tareas adecuadas — las condiciones son demasiado estrechas o incorrectas;
- la regla se ejecutó parcialmente — una parte de las tareas no cumplió las condiciones o los permisos;
- sin permisos de gestión — la regla solo está disponible en modo lectura;
- la ejecución fue bloqueada por una verificación de protección — la acción no se realizó, consulte las verificaciones.
Buenas prácticas
- Describa el proceso con palabras antes de configurarlo: «cuando… y si… — entonces…».
- Haga las condiciones lo más precisas posible, no «para todas las tareas».
- Ejecute siempre la vista previa antes de activar.
- Asigne un propietario a cada regla.
- Revise con regularidad la pestaña «Historial»: qué se ejecutó y qué quedó bloqueado.
- Un evento — una acción clara; construya la lógica compleja con un proceso.
Errores frecuentes
Activar la regla sin vista previa. Las condiciones amplias modifican en masa las tareas equivocadas, y revertirlo sale caro.
Hacer un disparador sin condiciones. Una regla «para cualquier cambio de estado» se ejecuta con demasiada frecuencia y satura el historial.
Ocultar varias acciones en una sola regla. Cuando se necesita una cadena o una ramificación, use un robot o un proceso, no un amontonamiento de reglas.
Dejar una regla sin propietario. Cuando la automatización se comporta de forma inesperada, no queda claro a quién acudir.
Cómo comprobar el resultado
- en la pestaña «Historial» se ve la ejecución de la regla sobre la tarea correspondiente;
- la tarea recibió el estado, el responsable, la fecha límite o el comentario esperados;
- la regla no afectó a tareas fuera de las condiciones;
- las ejecuciones bloqueadas son explicables (actuó una verificación de protección o faltan permisos).