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 pestaña «Reglas» de la página de automatización de tareas. Es el puesto de trabajo del administrador del proceso de tareas.
Cuándo se necesitan reglas de tareas
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
Abra 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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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 un objeto de CRM relacionado (oportunidad comercial o solicitud de servicio).
- añadir etiquetas;
- cambiar un campo personalizado de la tarea;
- iniciar un flujo de trabajo;
- estimar el esfuerzo preliminar.
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
Flujo conceptual de ámbito y consecuencias; no es una captura de la vista previa.
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.
Comprobar nombres e historial
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
En el editor y el historial, comprueba el título legible de la tarea, el evento, la acción, el estado y el resultado de la ejecución. Si un dato está incompleto o solo es técnico, aclara el contexto con el responsable de la regla antes de compartirlo en un comentario público.
Activación y propiedad
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
- 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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
- 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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
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
Flujo conceptual; no es una captura de UI ni evidencia del estado del portal.
- 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).
Escenarios relacionados
Guía conceptual, no es una captura de UI ni una evidencia de estado.