Un Workflow convierte una decisión de gobierno en un caso trazable con tareas, decisiones, evidencias y notificaciones. Parte de un objeto o asunto concreto, sigue las etapas que defina la empresa y no reemplaza la taxonomía ni sus vínculos registrados.
GovFrame permite configurar Workflows por tipo y por cantidad de etapas. Un caso puede mantener contexto de Dominio o Subdominio de forma directa, o derivarlo del objeto afectado. Por ello, la autorización no depende solo de participar en una tarea: se sigue comprobando la empresa, el módulo, la capacidad y el alcance aplicable.
Antes de empezar
- Rol: el Administrador puede gestionar la operación y los parámetros permitidos para la empresa. Un Data Owner atiende decisiones que requieran aprobación dentro de su ámbito; un Data Steward trabaja sobre definiciones y tareas en los Dominios o Subdominios asignados. Un Usuario participa solo en las gestiones que tenga autorizadas.
- Módulo: Workflows de gobierno debe estar habilitado para la empresa. Si se desactiva, deja de ser operable tanto desde la interfaz como por los procedimientos de la aplicación; los datos ya existentes no se eliminan automáticamente.
- Precondiciones: identifica el objeto o asunto que motiva el caso, su contexto taxonómico cuando exista y los responsables que pueden intervenir. Si el flujo necesita un rol de Workflow o una responsabilidad de gobierno, la empresa debe haberlo definido y asignado de manera coherente con el alcance.
Antes de iniciar, distingue dos niveles. La plantilla describe cómo se organizará un tipo de gestión; el caso es la instancia concreta que se sigue sobre un objeto o una solicitud. Esta distinción evita tratar una tarea aislada como si fuera un nuevo proceso de gobierno.
Recorrido recomendado
- Delimita el propósito y el contexto. Explica qué debe resolverse, cuál es el objeto afectado y qué Dominio o Subdominio corresponde. Cuando el contexto provenga del objeto, revísalo antes de asignar trabajo: una relación heredada sirve para navegación y autorización, pero no cambia el nivel original del objeto.
- Define la ruta funcional de la plantilla. Configura el tipo de Workflow y la cantidad de etapas necesaria para el proceso de la empresa. En cada etapa, establece qué responsabilidad debe intervenir y qué decisión o evidencia se espera. Esta es una ruta funcional: la documentación actual no publica un catálogo fijo de tipos, nombres de etapas, estados ni reglas universales de asignación.
- Abre y encauza el caso. Vincula el caso con el objeto de gobierno correspondiente y asigna tareas a personas con capacidad y alcance adecuados. Las notificaciones no sustituyen la revisión de la tarea y su contexto.
- Registra el trabajo verificable. Conserva en el caso la decisión adoptada y la evidencia disponible. Si el asunto depende de una regla de calidad, comprueba primero que la regla tenga un campo físico asociado y un dialecto configurado antes de esperar SQL; el Workflow no genera ni ejecuta SQL por sí mismo.
- Cierra el seguimiento con trazabilidad. Revisa las tareas pendientes, las decisiones y las evidencias ligadas al mismo caso. Para analizar el impacto del objeto antes de decidir, usa el mapa de relaciones y sigue solo vínculos registrados, no dependencias inferidas por nombre o por compartir Dominio.
Ejemplo sintético. El equipo detecta que la definición de un atributo de Clientes requiere revisión. Se crea un caso asociado al atributo; un Steward prepara la propuesta y la evidencia de contexto, y el Owner competente toma la decisión dentro de su ámbito. El resultado queda ligado al caso, sin afirmar que exista una etapa, estado o formulario estándar para todas las empresas.
Resultado esperado
Al finalizar, debe existir una trazabilidad clara entre el asunto tratado, el objeto de gobierno cuando aplique, las tareas asignadas, las intervenciones, la decisión y sus evidencias. El caso conserva el contexto necesario para que la empresa pueda seguir el trabajo y para que el backend aplique las restricciones de tenant, módulo, rol y alcance.
Un Workflow bien operado deja claro quién hizo qué, sobre qué objeto y con qué fundamento, sin crear un catálogo independiente de Riesgos o Controles. En el modelo actual, un control puede estar representado por una regla de calidad, una política o procedimiento, una aprobación, una tarea o una certificación; cada uno conserva su propio objeto y relación.
Límites del comportamiento actual
- Los Workflows son configurables, pero esta guía no presupone estados, transiciones, SLA, formularios ni secuencias de pantalla que no estén documentados para la empresa.
- La posibilidad de ver un objeto no concede automáticamente permiso para editarlo, aprobarlo o asignar trabajo. Las comprobaciones se hacen en el backend.
- Un módulo desactivado bloquea la operación, pero no borra por sí mismo casos, tareas ni evidencias existentes.
- Las tareas programadas de otras áreas, como sincronización de metadata o respaldos, dependen de su configuración. No se debe interpretar un caso de Workflow como prueba de que un job productivo se haya ejecutado.