Tareas para personas
Pasos asignados a usuarios de la app — decisiones, plazos y pantalla a abrir — las formas de arrancar un proceso y cómo acompañar las ejecuciones.
Un workflow que solo escribe campos y manda correos podría ser un script. Lo que lo convierte en un proceso de negocio es la Tarea: un paso que se queda esperando a una persona, con botones propios, plazo y una pantalla para que decida.
Esta página trata de las tareas, de quién manda arrancar el proceso y de cómo se acompaña lo que está corriendo.
El paso Tarea
Arrastra Tarea de la paleta al lienzo y selecciónala. El panel de la derecha muestra todo lo que una tarea necesita:
| Campo | Qué hace |
|---|---|
| Nombre del paso | Lo que la persona lee en la lista de tareas y lo que queda en el historial. |
| Usuarios | Cuentas de la app elegidas a mano. |
| Roles | Todos los usuarios con ese role. |
| Pantalla a abrir | La pantalla que la persona abre para decidir. Recibe la clave del registro como parámetro. Ninguna = se decide solo con los botones. |
| Plazo (días) | Días a contar desde el momento en que la tarea nace. 0 = sin plazo. |
| Decisiones | Los botones que la persona ve. Ver abajo. |
Sobre los destinatarios: «quién se queda con la tarea se resuelve cuando
ella nace — cambiar de role después no le quita la tarea a quien ya la
tenía». Una tarea asignada el lunes a quien tenía el role direcao sigue
con esas personas aunque el role cambie el miércoles.
Atención
Una tarea sin usuarios ni roles es un error de diseño: «esta tarea no dice a quién debe asignarse — la ejecución va a fallar aquí». Y falla lejos de donde se cometió el error, lo que es peor — por eso el diseño avisa pronto.
Decisiones — los botones y los caminos
Una decisión es, al mismo tiempo, un botón en la pantalla y una salida en el diseño. Se declara una vez.
- Abre Decisiones en el botón ….
- Cada fila tiene una Etiqueta (lo que la persona lee: «Aprobar») y un
Identificador (lo que el código usa:
aprovar). - Haz clic en Añadir decisión para las que falten.
- Cierra y conecta, en el lienzo, cada salida al paso que le corresponde.
En el ejemplo, la tarea Aprovação da direcção tiene tres: Aprobar, Rechazar y Pedir más datos. Cada una lleva el proceso por un camino distinto — la primera cierra el negocio, la segunda lo marca como perdido, la tercera devuelve el caso al comercial y espera su señal.
Consejo
Cambia la Etiqueta a placer — es texto para personas. El Identificador es lo que las conexiones del diseño y el código usan: cambiarlo rompe la flecha que sale de esa decisión, y la barra de avisos pasa a decir «Conexión desde una salida que ya no existe».
Lo que la persona ve en la app
Del lado de quien usa la aplicación, una tarea aparece por dos widgets del constructor de pantallas:
| Widget | Qué muestra |
|---|---|
| Mis tareas | El buzón de quien tiene sesión: sus tareas abiertas, con los botones de decisión de cada una. |
| Estado del proceso | Dónde está el proceso de un registro — «Ahora en», los últimos saltos, y (opcionalmente) los botones de decisión. |
Propiedades que vale la pena conocer:
- Mostrar botones de decisión — «solo aparecen cuando la tarea abierta está asignada a quien está viendo». Nadie decide por otra persona.
- Abrir la pantalla de la tarea — al hacer clic en una tarea, abre la pantalla que ella indica, ya con la clave del registro.
- Saltos a mostrar (en el Estado del proceso) — cuántos pasos del historial se ven.
- Entidad y Clave del registro — qué registro está siguiendo el widget.
Cuando la persona pulsa un botón, la tarea se cierra y el proceso sigue por la salida correspondiente — de inmediato, sin que nadie tenga que ir a «ejecutar» nada.
En código, lo mismo se hace con el SDK de las pantallas (TypeScript):
const minhas = await keplin.workflow.tasks();
await keplin.workflow.complete(minhas[0].id, "aprovar", { nota: "ok" });
Formas de arranque
Un workflow no sabe quién lo arranca — y es a propósito. Quien decide es la pantalla, el código o el proceso padre. Son cuatro las formas:
| Forma | Cómo se hace |
|---|---|
| Botón o evento de una pantalla | En un evento TypeScript: await keplin.workflow.start("wf_4ef9ed11", id). |
| Script Python | workflow.start("Aprovação de oportunidade", 42) — acepta el nombre o el identificador. |
| Sub-workflow | Un paso Sub-workflow en otro proceso, sobre el mismo registro. |
| Señal | Un proceso ya corriendo, parado en un Esperar evento, se retoma con signal(...). |
En cualquiera de ellas, la clave del registro es obligatoria: toda ejecución trata de un registro. El arranque responde «en cuanto el motor encuentra la primera espera — nunca se queda esperando a que el proceso acabe», y devuelve el identificador de la ejecución creada.
El identificador del proceso (wf_…) se copia en la cabecera del diseño,
con un clic — es lo que se pega en el código.
Nota
Un proceso Desactivado no arranca por ninguna de estas vías. Es el interruptor a usar cuando se quiere parar las entradas sin borrar nada.
Acompañar las ejecuciones
En la pestaña Ejecuciones del proceso se ve todo lo que ya corrió:
Arriba, un filtro por estado (Todos los estados), el recuento de ejecuciones y el botón Borrar las terminadas. Un proceso que aún no corrió muestra «Este proceso aún no corrió ninguna vez.».
Los estados de una ejecución:
| Estado | Significa |
|---|---|
| Corriendo | Está ejecutando pasos en este momento. |
| En espera | Parada — en una tarea, en un Esperar o en un Esperar evento. |
| Completada | Llegó a un Fin. |
| Falló | Un paso dio error (un script que reventó, una escritura rechazada). |
| Cancelada | Fue terminada antes del final. |
Cada fila muestra el registro, el estado, cuándo empezó y cuántos pasos dio. Abriendo la fila se ve el historial — una entrada por acontecimiento, con el nombre del paso tal como está en el diseño:
| Acontecimiento | Cuándo aparece |
|---|---|
| arrancó | Al inicio de la ejecución. |
| paso | Cada paso ejecutado. |
| decisión | Una condición que eligió un camino, o una tarea decidida. |
| esperó / retomó | Entró en una espera / fue despertada. |
| acabó / falló / cancelada | El desenlace. |
El botón Ver el camino en el diseño es el más útil de todos: enciende, en el lienzo, los pasos por donde esa ejecución pasó, numerados por el orden en que ocurrieron. Se vuelve a lo normal en borrar el camino, junto a las pestañas.
Limpiar el historial
Borrar las terminadas «borra las ejecuciones completadas, fallidas y canceladas de este proceso, con su historial. Las que están corriendo o en espera se quedan. No hay vuelta atrás.»
Para una política automática, usa la Rotación de registros en los ajustes de la app: las fichas de workflow terminadas se borran al cabo del plazo que definas, «las que aún corren o esperan por alguien nunca se borran», y «las que fallaron se quedan el doble de tiempo».
Preguntas frecuentes
La persona no ve su tarea. Por orden de probabilidad: la pantalla donde está el widget Mis tareas no es accesible para ella; la tarea fue asignada a un role que ella no tiene; o la cuenta de la app no es la misma persona que crees — las cuentas de la app son independientes de las cuentas de la plataforma (ver Usuarios de la app).
¿Puedo reasignar una tarea a otra persona? La asignación queda fijada en el momento en que la tarea nace. Para casos de sustitución, diseña el proceso con Roles en vez de usuarios: basta dar el role a quien sustituye.
¿El plazo hace algo por sí solo? El plazo marca la tarea y se muestra a quien la tiene. Para actuar sobre un retraso — avisar al jefe, escalar — diseña ese camino: un Paralelo con una rama que sigue hacia un Esperar de N días y de ahí a un Notificar.
Una ejecución falló. ¿Puedo retomarla? Una ejecución fallida queda registrada con el paso y el error. El camino normal es corregir la causa (el script, el permiso) y arrancar el proceso otra vez sobre el mismo registro — si la concurrencia está en Solo una a la vez, confirma antes que la ejecución fallida ya no cuenta como viva.