todos los artículos
automatización · 5 min de lectura

Reglas de automatización en Asana: una guía práctica de flujos

Planificá reglas de Asana para asignar tareas, mandar recordatorios y actualizar estados, con resguardos contra duplicados, permisos y dueños de cada flujo.

Las reglas de Asana sirven para los movimientos chicos y aburridos que se escapan cuando el equipo está con mucho trabajo: asignar pedidos nuevos, avisarle a alguien antes de una fecha de vencimiento y mantener al día un campo de estado. No sirven para decisiones que requieren criterio. Esta guía muestra cómo planificar unas pocas reglas para asignar pedidos, mandar recordatorios y actualizar estados, y cómo evitar que se disparen dos veces, que se rompan cuando alguien se va o que aprueben trabajo que nadie miró.

Qué es hoy una regla en Asana

Una regla combina un disparador con una o más acciones. El disparador es un evento dentro de un proyecto, por ejemplo que se agregue una tarea, que se acerque una fecha de vencimiento, que cambie un campo o que alguien envíe un formulario. Las acciones son lo que hace Asana después: asignar la tarea, moverla a una sección, completar un campo personalizado, agregar un comentario, crear subtareas o mandar un mensaje a una herramienta conectada, como Slack. El editor de reglas de Asana también te deja sumar condiciones, para que una regla actúe solo cuando, por ejemplo, el campo de prioridad está en "High".

Las reglas se arman desde el menú "Customize" (personalizar) de cada proyecto, ya sea a partir de la biblioteca de reglas predefinidas de Asana o desde cero.

Sobre los planes: la página de funciones de reglas de Asana muestra las reglas en los planes Starter, Advanced, Enterprise y Enterprise+, y la página de precios actual incluye las aprobaciones y la revisión de archivos en la descripción del plan Advanced. Asana reorganizó sus planes más de una vez, así que antes de diseñar nada, abrí la página de precios y tu propia consola de administración y confirmá qué tiene tu espacio de trabajo. No te guíes por cantidades de reglas ni por límites mensuales de acciones citados en artículos viejos, incluida la versión anterior de esta misma página.

Tres flujos para automatizar primero

Empezá con un solo proyecto y no más de tres reglas. Escribí cada una como una especificación corta antes de armarla.

1. Asignar los pedidos nuevos

Disparador: se agrega una tarea al proyecto a través de un formulario.
Condición: el campo de tipo de pedido es igual a "Design".
Acción: asignar al responsable de diseño, poner el campo de estado en "New" y mover la tarea a la sección "Intake".
Dueño: el responsable de diseño.

Las reglas de asignación son el lugar más seguro para empezar, porque una asignación equivocada se ve y se corrige fácil.

2. Recordatorios antes de una fecha límite

Disparador: se acerca la fecha de vencimiento.
Acción: agregar un comentario que mencione a la persona asignada, o mover la tarea a una sección "Due this week" (vence esta semana).
Dueño: el líder del proyecto.

Hay un detalle que señala el centro de ayuda de Asana: los disparadores "due date is approaching" (se acerca la fecha de vencimiento) y "task is overdue" (tarea vencida) no están disponibles para subtareas. Si tu equipo sigue las fechas límite en subtareas, hacé que la regla corra sobre tareas o reorganizá el proyecto.

3. Estados que reflejan lo que pasa de verdad

Disparador: la tarea se mueve a la sección "In review".
Acción: poner el estado en "In review" y sumar a quien revisa como colaborador.
Dueño: el líder del proyecto.

El objetivo es que la sección y el campo de estado nunca digan cosas distintas, para que los informes armados sobre cualquiera de los dos sean correctos.

Las aprobaciones quedan en manos de una persona

Las tareas de aprobación de Asana le permiten a quien revisa elegir "Approve" (aprobar), "Request changes" (pedir cambios) o "Reject" (rechazar). Las reglas pueden ayudar alrededor de esa decisión: cuando alguien pide cambios, una regla puede reasignar la tarea a la persona que tiene que hacer las correcciones. Lo que una regla nunca debería hacer es definir por su cuenta el resultado de una aprobación, marcar una tarea como aprobada porque pasó una fecha o tomar la falta de respuesta como un sí.

Dos precauciones prácticas:

Una aprobación vale lo que vale que quien revisa vea el trabajo real. Adjuntá el archivo o el enlace a la tarea de aprobación, no a una tarea principal que quizá no abra.
Según el centro de ayuda de Asana, cada resultado de aprobación muestra un estado distinto, pero probá cómo trata tu propio proyecto una aprobación con "Request changes" antes de encadenarle tareas dependientes. Si una tarea posterior arranca apenas se cierra la tarea de aprobación, un rechazo igual podría destrabar trabajo. Usá una regla que revise el resultado, o un campo personalizado, en lugar de una dependencia sola.

Resguardos contra duplicados y bucles

La mayoría de los problemas con reglas vienen de cómo interactúan entre sí.

Si dos reglas reaccionan a "task moved to Done" (tarea movida a terminada), podés terminar con dos comentarios o dos mensajes de Slack. Llevá una lista de reglas por proyecto y revisá si hay disparadores superpuestos antes de sumar una nueva.
Ojo con los bucles. La regla A mueve una tarea a una sección, eso dispara la regla B, que cambia un campo que dispara la regla A. Dibujá la cadena en papel antes de armarla.
Si una tarea está compartida entre varios proyectos, fijate si las reglas de cada proyecto reaccionan a ella y después decidí qué proyecto es dueño de la automatización.
Las reglas que publican en Slack o mandan correos son las que la gente nota cuando fallan. Activalas al final, después de que las acciones internas hayan funcionado bien durante una semana.

Permisos y dueños

El artículo de Asana sobre permisos de reglas explica que cualquier persona con acceso para editar el flujo de trabajo de un proyecto puede editar, activar o desactivar sus reglas, incluso las que creó otra persona. Las reglas con disparadores o acciones externas, como Slack u Outlook, solo las puede editar su dueño. Los administradores de Enterprise y Enterprise+ pueden limitar la edición del flujo a los administradores del proyecto.

Eso tiene dos consecuencias para un equipo chico:

Cuando se va el dueño de una regla de Slack o de correo, alguien tiene que hacerse cargo de ella. Asana permite que los usuarios con acceso para editar el flujo reclamen una regla desde su configuración; hacelo antes de desactivar la cuenta de esa persona y después probala.
Definí quién puede cambiar las reglas en cada proyecto. En la práctica, el líder del proyecto y un reemplazo.

Un plan de implementación para copiar

Paso	Qué hacer	Listo cuando
1	Escribir las tres reglas como especificaciones, cada una con un dueño	Las especificaciones están en la descripción del proyecto
2	Armarlas en una copia del proyecto	Cada regla se dispara una sola vez en tareas de prueba
3	Correrlas en el proyecto real con los mensajes externos apagados	Pasa una semana sin asignaciones equivocadas
4	Activar las acciones de Slack o correo	Quienes los reciben confirman que los mensajes sirven
5	Revisar una vez por mes	El dueño confirma que cada regla sigue haciendo falta

Borrá las reglas que nadie sabe explicar. La regla que no tiene dueño es la que te va a sorprender.

Dónde entra automotif

Cuando el trabajo pasa por varias herramientas, por ejemplo un formulario en un sistema, una tarea en Asana, una factura en otro y un mensaje de Slack, las reglas de Asana solas suelen quedarse cortas. Eso es desarrollo de automatizaciones: conectamos las herramientas con n8n, Make o Zapier en tus propias cuentas y dejamos a una persona aprobando en cada punto donde hay una decisión. Si querés repasar cómo lo tenés armado hoy, reservá una llamada gratis de 30 a 60 minutos.