Workflows
Los Workflows convierten una columna Status en un motor de procesos estructurado. En lugar de permitir que cualquiera cambie libremente el status de una fila en cualquier momento, defines exactamente qué transiciones se permiten, quién puede desencadenarlas, qué condiciones deben cumplirse y qué sucede automáticamente después de que se completa una transición. Esto hace que los Boards de Copera sean comparables a herramientas de procesos dedicadas como Jira o ServiceNow, integradas directamente en tu espacio de trabajo.
Habilitar un Workflow
Los Workflows se configuran individualmente por cada columna Status. Para habilitar uno:
- Abre tu Board y ve a la tabla que contiene la columna Status que quieres controlar.
- Haz clic en el encabezado de la columna para abrir la configuración de la columna.
- Activa el interruptor Workflow.
- Aparece el editor visual de workflow: un lienzo que muestra cada status como un nodo y cada transición permitida como una flecha dirigida entre nodos.
- Establece un Initial Status: el status con el que comienzan las nuevas filas cuando se crean.
Cuando habilitas por primera vez el modo workflow, Copera ofrece plantillas predefinidas para procesos comunes como Software Development (Backlog → In Progress → Code Review → QA → Done), IT Service Desk, HR Onboarding y Content Approval. Aplicar una plantilla rellena los status y las transiciones por ti, dándote un punto de partida sólido para personalizar.
Transiciones de status
Una transición define una ruta permitida entre dos status. Sin una transición definida, el cambio de status queda bloqueado.
Transiciones con nombre
Cada transición puede tener un nombre visible que aparece en la interfaz cuando los usuarios eligen qué hacer a continuación, por ejemplo, "Start Review", "Approve" o "Send Back for Revisions". Los nombres claros ayudan a los miembros del equipo a entender qué significa cada acción en el contexto de tu proceso.
Transiciones específicas
Una transición específica conecta un status concreto con otro. Las dibujas en el editor visual arrastrando de un nodo de status a otro. Por ejemplo, conectar "To Do" directamente con "In Review" crea una transición que solo permite esa ruta.
Transiciones globales
Una transición global se origina desde cualquier status y va hacia un destino específico. Son útiles para acciones que siempre pueden ocurrir independientemente de dónde se encuentre una fila en el proceso, por ejemplo, una transición "Cancel" que mueve la fila a "Cancelled" desde donde esté en ese momento, o una transición "Escalate" que funciona en cualquier etapa.
El interruptor "From Any Status"
Puedes convertir cualquier transición específica en una transición global directamente desde el editor visual. Cuando haces clic en una arista de transición y abres el panel lateral, marca la casilla "From any status". Esto establece el origen en "Any Status" y la arista se vuelve discontinua, indicando visualmente que la transición es alcanzable desde todos los status. Desmarca la casilla para restaurar el status de origen específico original.
Esto es especialmente útil cuando, durante el diseño del workflow, te das cuenta de que una transición como "Cancel" o "Close" debería estar disponible desde cada etapa: no necesitas dibujar manualmente aristas individuales desde cada status.
Los usuarios siempre pueden borrar un valor de status (dejarlo vacío) independientemente de las reglas del workflow. Esto es intencional: borrar un status no cuenta como una transición y nunca se bloquea.
Si la fila aún no tiene un status actual (primera asignación tras la creación), puede establecerse libremente cualquier status permitido. La validación del workflow solo se aplica al cambiar de un status definido a otro.
Conditions — Quién puede ejecutar una transición
Las condiciones controlan qué usuarios tienen permiso para desencadenar una transición determinada. Todas las condiciones de una misma transición usan lógica AND: el usuario debe satisfacer todas las condiciones listadas.
| Tipo de condición | Descripción |
|---|---|
| Role | El usuario debe tener uno de los roles de Board especificados. |
| User | El usuario debe estar en una lista específica de personas nombradas. |
| Team | El usuario debe pertenecer a uno de los equipos especificados del espacio de trabajo. |
| Row Owner | Solo el usuario que creó la fila puede desencadenar esta transición. |
| Assignee | Solo los usuarios actualmente asignados a la fila (en una columna Users) pueden desencadenarla. |
Los admins del Board omiten las comprobaciones de condiciones: pueden desencadenar cualquier transición independientemente de las condiciones. Sin embargo, los admins no están exentos de los validadores. Los requisitos de datos se aplican a todos.
Validators — Qué debe ser cierto
Los validadores comprueban si los datos de la fila cumplen los requisitos antes de permitir que la transición continúe. A diferencia de las condiciones, los validadores se aplican a todos los usuarios, incluidos los admins.
| Tipo de validador | Descripción |
|---|---|
| Field Required / Field Not Empty | Una columna especificada debe tener un valor. Si está vacía, la transición se bloquea. |
| Field Matches | El valor de la columna debe coincidir con un patrón que tú definas. Útil para imponer formatos como números de referencia o códigos. |
Cada validador puede mostrar un mensaje de error personalizado para que los usuarios sepan exactamente qué deben rellenar antes de que la transición pueda continuar.
Required Fields
Más allá de los validadores (que comprueban los datos existentes), una transición también puede pedir al usuario que rellene campos en el momento de la transición. Cuando se configuran campos requeridos, aparece un diálogo en cuanto el usuario desencadena la transición, solicitando esos valores antes de que se complete el cambio de status.
Esto es útil cuando quieres capturar contexto en una etapa específica, por ejemplo, requerir un campo "Rejection Reason" al pasar a un status "Rejected".
Qué sucede en Kanban
Cuando arrastras una tarjeta a una nueva columna en la Kanban view y esa transición tiene campos requeridos, la tarjeta se mueve visualmente a la nueva columna y el diálogo de transición se abre de inmediato para recopilar los valores faltantes. El cambio de status se finaliza una vez que rellenas el diálogo y confirmas.
Esto es intencional: obtienes una experiencia fluida de arrastrar y soltar en lugar de quedar bloqueado a mitad del arrastre, y el aviso garantiza que la información se capture antes de que se confirme el movimiento. Si cierras el diálogo sin completarlo, la tarjeta vuelve a su columna original. (Si una transición no está permitida en absoluto, arrastrar la tarjeta simplemente no se acepta y vuelve a su sitio.)
El aviso de campos requeridos es parte de la interfaz de Copera: aparece siempre que realizas la transición a través de la app, guiándote para rellenar los detalles correctos en el momento adecuado.
Si necesitas una garantía estricta de que un campo nunca pueda quedar vacío para una transición (independientemente de cómo se realice el cambio), añade un Validator de tipo Field Required o Field Not Empty a esa transición, o marca el campo como Required en el comportamiento de campo por status. Los validadores y las reglas de campo requerido por status se aplican a todos, incluidos los admins del Board, por lo que son la herramienta adecuada cuando el requisito es una regla estricta de integridad de datos y no un aviso de ayuda.
Puntos de aprobación
Las transiciones pueden requerir la aprobación de personas designadas antes de que el cambio de status surta efecto. Cuando un usuario desencadena una transición que tiene la aprobación habilitada, la fila pasa a un status Pending Approval mientras se procesa la solicitud de aprobación. Una vez que la solicitud se resuelve (aprobada o rechazada), la fila pasa al status de destino o vuelve a su status original.
Tipos de aprobador
Puedes designar aprobadores de cuatro maneras:
- Specific Users — Personas concretas que deben revisar la solicitud.
- Board Role — Cualquiera que tenga un rol especificado en el Board (como "Manager") se convierte en aprobador.
- Row Owner — La persona que creó la fila es el aprobador.
- Column Based — Los aprobadores se determinan dinámicamente según el valor de una columna en la fila (consulta más abajo).
Aprobadores condicionales basados en columna
La aprobación basada en columna te permite enrutar las solicitudes de aprobación a distintas personas según un valor de la fila, sin crear transiciones o workflows separados para cada caso.
Cuando seleccionas Column Based como tipo de aprobador, aparecen tres opciones de configuración:
- Condition column — Elige una columna Dropdown (SELECT) de la tabla. El valor actual de esta columna en la fila determina quiénes serán los aprobadores.
- Mapping table — Para cada opción de la columna seleccionada, asigna uno o más aprobadores. Por ejemplo, si tu columna "Department" tiene las opciones "RH", "Systems" y "Finance", puedes asignar cada departamento a su respectivo gerente.
- Fallback approvers — Usuarios opcionales que reciben la solicitud de aprobación cuando el valor de la columna de la fila no coincide con ninguna asignación (o la columna está vacía).
Ejemplo — Aprobación departamental de varios niveles:
Supongamos que tienes una columna "Department" con las opciones RH, Systems y Finance. Puedes configurar dos transiciones:
- Open → In Review: Aprobación basada en columna en "Department" — asigna RH a Manager A, Systems a Manager B
- In Review → Done: Aprobación basada en columna en "Department" — asigna RH a Director X, Systems a Director Y
Cada transición resuelve de forma independiente el aprobador correcto para el departamento de la fila. Esto crea un flujo de aprobación de varios niveles donde los gerentes de departamento aprueban primero y, luego, los directores de departamento aprueban a continuación.
El solicitante (la persona que desencadenó la transición) queda automáticamente excluido de la lista de aprobadores, incluso si coincide con la asignación. Una persona no puede aprobar su propia solicitud.
Políticas de aprobación
| Política | Comportamiento |
|---|---|
| ANY_ONE | El primer aprobador que actúe (aprobar o rechazar) resuelve la solicitud para todos. |
| ALL | Todos los aprobadores designados deben aprobar. Un solo rechazo rechaza toda la solicitud. |
Status Pending Approval
Cuando la aprobación está habilitada en una transición, el sistema crea automáticamente una opción de status Pending Approval en la columna. Este es un status real, no un estado interno oculto, lo que significa que funciona sin problemas con todas las funciones de Copera:
- Filtros: Filtra tu tabla para ver solo las filas en espera de aprobación.
- Kanban view: Aparece automáticamente una columna "Pending Approval" que agrupa todas las filas en espera de decisiones.
- Temporizadores de SLA: Configura condiciones de SLA para que empiecen a contar el tiempo cuando una fila entra en el status pendiente y se pausen cuando sale.
- Automations: Crea automatizaciones que se desencadenen cuando el status de una fila cambia a "Pending Approval" (por ejemplo, asignar automáticamente un revisor o enviar una notificación personalizada).
- Reglas de visibilidad y campos por status: Configura anulaciones de visibilidad y comportamiento de campo específicamente para el estado pendiente.
El status pendiente aparece en el editor visual como un nodo distintivo con un borde ámbar y un icono de reloj de arena, lo que facilita identificarlo en tu grafo de workflow.
Los status de aprobación pendiente los gestiona el sistema. No pueden renombrarse ni eliminarse manualmente: se crean cuando habilitas la aprobación en una transición y se limpian automáticamente cuando la deshabilitas.
Cómo funciona el flujo:
- Un usuario desencadena una transición que requiere aprobación (por ejemplo, Open → In Review).
- La fila pasa de inmediato al status Pending Approval.
- Los aprobadores designados reciben una notificación.
- Si se aprueba: la fila pasa al status de destino (In Review).
- Si se rechaza: la fila pasa al status de rechazo configurado, o vuelve al status original (Open) si no se ha establecido ninguno.
Si tienes varias transiciones con la aprobación habilitada, cada una obtiene su propio status pendiente (por ejemplo, "Pending: Manager Approval" y "Pending: Director Approval"), de modo que puedes distinguir entre las distintas etapas de aprobación.
Gestión de rechazos
Cuando se rechaza una transición, puedes configurar qué le sucede a la fila:
- Moverla a un status específico (por ejemplo, un status "Rejected" o "Needs Revision").
- Si no se configura ningún status de rechazo, la fila vuelve al status en el que estaba antes de desencadenar la aprobación.
Notificaciones
Tanto el solicitante como los aprobadores designados reciben notificaciones dentro de la app y por correo. Se notifica a los aprobadores cuando una nueva solicitud de aprobación los está esperando; se notifica al solicitante cuando su solicitud es aprobada o rechazada.
Comentarios en las decisiones de aprobación
Los aprobadores pueden añadir un comentario junto a su decisión. Puedes configurar una transición para requerir un comentario al rechazar, garantizando que el feedback quede siempre documentado.
Solo puede haber una solicitud de aprobación pendiente por fila y por columna Status a la vez. Si ya hay una solicitud pendiente, no se puede desencadenar ninguna nueva transición hasta que se resuelva o se cancele.
Funciones post-transición
Las funciones post-transición son acciones que se ejecutan automáticamente después de que una transición se completa con éxito (incluido después de que se concede una aprobación, si corresponde). Se ejecutan sin ninguna interacción del usuario.
| Función | Descripción |
|---|---|
| Set Field | Establece una columna en un valor estático específico. |
| Copy Field | Copia el valor de una columna en otra columna de la misma fila. |
| Set Current Date | Escribe la fecha y hora actuales en una columna de fecha, útil para registrar cuándo ocurrió una transición. |
| Assign Current User | Añade el usuario que desencadenó la transición a una columna Users. |
| Assign User | Añade una o más personas específicas a una columna Users. |
| Clear Field | Elimina por completo el valor de una columna. |
| Send Notification | Envía una notificación dentro de la app a usuarios específicos con un mensaje personalizado. |
| Webhook | Envía una solicitud HTTP (POST, PUT o PATCH) a una URL externa, permitiendo la integración con sistemas de terceros. |
Puedes añadir varias post-funciones a una sola transición, y se ejecutan en el orden en que están listadas.
Visibilidad por status
Puedes controlar qué usuarios tienen permiso para ver las filas según el status actual de la fila. Esto se configura haciendo clic en un nodo de status en el editor visual y abriendo su panel de ajustes.
| Ajuste de visibilidad | Descripción |
|---|---|
| Role-based | Solo los usuarios con roles de Board específicos pueden ver las filas en este status. |
| User-based | Solo usuarios concretos nombrados pueden ver las filas en este status. |
| Owner Can View | El creador de la fila siempre ve sus propias filas, incluso si las reglas de visibilidad lo excluyeran de otro modo. Habilitado de forma predeterminada. |
| Assignee Can View | Los usuarios asignados a la fila siempre la ven. Habilitado de forma predeterminada. |
Los admins del Board siempre ven todas las filas independientemente de las reglas de visibilidad. Los ajustes de visibilidad solo se aplican a los miembros regulares y a los invitados.
Comportamiento de campo por status
Cuando una fila está en un status determinado, puedes anular cómo se comportan los campos individuales. Esto también se configura desde el panel de ajustes del nodo de status.
| Comportamiento | Descripción |
|---|---|
| Editable | Comportamiento normal: el campo se puede leer y modificar. Es el predeterminado. |
| Read-only | El campo es visible pero no se puede editar. Los admins aún pueden editar los campos de solo lectura. |
| Required | El campo debe tener un valor. Esto se aplica a todos los usuarios, incluidos los admins: es una regla de integridad de datos, no una restricción de permisos. |
| Hidden | El campo no es visible para los no admins y se excluye de las respuestas de la API. Los admins aún pueden ver y editar los campos ocultos. |
Temporizadores de SLA
Las transiciones de status del workflow pueden iniciar, pausar y detener automáticamente las columnas de temporizador de SLA. Cuando una fila entra o sale de status específicos, el temporizador responde en consecuencia, permitiendo un seguimiento automático de cuánto tiempo pasa el trabajo en cada etapa. Consulta la página Seguimiento de SLA para todos los detalles de configuración.
Consejos
- Empieza de forma simple. Habilita el workflow con unas pocas transiciones básicas primero, y luego incorpora condiciones, validadores y puntos de aprobación a medida que tu proceso madura.
- Usa el editor visual para mapear tu proceso. Dibuja el flujo en el lienzo antes de añadir reglas: es mucho más fácil detectar huecos y bucles de forma visual.
- Las transiciones globales son ideales para las excepciones. Las acciones "Cancel", "Escalate" o "Emergency Close" que deberían estar siempre disponibles desde cualquier status funcionan perfectamente como transiciones globales (desde ANY).
- Combina los puntos de aprobación con la visibilidad por status. Mueve una fila a un status "Pending Review" que solo los revisores puedan ver, y requiere su aprobación antes de que avance. Esto crea un proceso de revisión seguro y auditable.
- Usa las post-funciones para las actualizaciones repetitivas. Registra automáticamente la marca de tiempo de las finalizaciones, asigna a la persona que cerró un ticket y borra los campos temporales, sin que nadie tenga que acordarse de hacerlo manualmente.
- Prueba con una fila de muestra. Antes de desplegar un workflow a todo tu equipo, recorre el proceso con una fila de prueba para verificar que cada transición, condición y aprobación se comporta como se espera.
Próximos pasos
- Explora las Automations para reglas basadas en eventos de "cuando ocurra esto, haz aquello" que complementan las transiciones del workflow.
- Revisa los Permisos de Board para entender cómo interactúan los roles de Board con las condiciones del workflow.
- Conoce los Field Types para entender qué tipos de columna funcionan con validadores y post-funciones.