--- title: Workflows de gobierno description: Guía funcional para configurar y operar casos de gobierno con etapas, tareas, decisiones y evidencias dentro del alcance autorizado. audiencia: Administrador | Data Owner | Data Steward | Usuario roles: Administrador para parámetros del tenant; Data Owner, Data Steward y Usuario según capacidad, asignación y alcance modulo: Workflows de gobierno revision: "2026-10-19" section: "colaborar" order: 10 sources: - CONTEXT.md - ARCHITECTURE.md - Modelodeobjetosyrelaciones.md - Módulosydependencias.md - Roles,capacidadesyalcance.md --- # Workflows de gobierno 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 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. ## Referencias relacionadas - [Modelo de objetos y relaciones](/es/explicaciones/modelo-de-objetos-y-relaciones/) - [Cómo leer el mapa de relaciones](/es/guias/como-leer-mapa-de-relaciones/) - [Roles, capacidades y alcance](/es/referencia/roles-capacidades-y-alcance/) - [Módulos y dependencias](/es/referencia/modulos-y-dependencias/)