---
title: Solicitudes de acceso
description: Guía funcional para gestionar peticiones de acceso agrupadas, decisiones, tareas, provisionamiento y evidencias con trazabilidad por empresa.
audiencia: Usuario | Administrador | Data Owner | Data Steward
roles: Usuario para solicitar según política; Administrador con access.manage; aprobadores definidos por la empresa y el Workflow
modulo: Workflows de gobierno y gestión de accesos
revision: "2026-10-19"
section: "colaborar"
order: 20
sources:
  - CONTEXT.md
  - ARCHITECTURE.md
  - Modelodeobjetosyrelaciones.md
  - Módulosydependencias.md
  - Roles,capacidadesyalcance.md
---

# Solicitudes de acceso

Las **solicitudes de acceso** tratan una necesidad de acceso como una gestión trazable. GovFrame contempla carrito de solicitudes, casos de Workflow, tareas, decisiones, provisionamiento y evidencias. Una gestión puede agrupar elementos y admitir resultados parciales.

La solicitud toma su contexto del objeto pedido —por ejemplo, una tabla, un dashboard, un dataset u otro destino permitido— y se enlaza con un caso de Workflow. El objeto y sus asociaciones determinan el contexto de negocio; la solicitud no elude reglas de empresa, membresía, módulo, capacidad o alcance.

## Antes de empezar

- **Rol:** un Usuario puede participar en las solicitudes autorizadas por la política de su empresa. La gestión administrativa de accesos, membresías, solicitudes y provisionamiento requiere la capacidad `access.manage`, propia del Administrador en el contrato actual. Quien decide una solicitud debe además ser la responsabilidad que la empresa haya configurado para el caso y estar autorizado sobre su contexto.
- **Módulo:** los componentes de Workflow involucrados deben estar operables para la empresa. Los módulos configurables se validan en interfaz y backend; desactivar uno no elimina automáticamente sus registros, pero impide seguir operando con su función.
- **Precondiciones:** el destino debe existir en la empresa y ser identificable como objeto solicitado. Revisa su relación con la taxonomía, los responsables y el alcance antes de tramitarlo. La pertenencia activa del solicitante y de los participantes sigue siendo necesaria.

Las vistas temporales de usuario son de solo lectura, salvo las operaciones de Solicitudes de acceso expresamente permitidas. No amplían permisos de catálogo ni permiten alterar empresa o alcance desde el navegador.

## Recorrido recomendado

1. **Define la necesidad con el objeto correcto.** Localiza el activo, tabla, dashboard, dataset u otro destino admitido por la política de la empresa. Verifica qué se solicita y cuál es su contexto. No infieras una relación técnica solo porque dos objetos compartan nombre o Dominio.
2. **Agrupa los elementos relacionados.** Usa el carrito para reunir las solicitudes que deban tratarse en una misma gestión. Mantén la justificación y el alcance de cada elemento distinguibles, ya que la decisión puede no ser idéntica para todos ellos.
3. **Crea el caso y organiza el trabajo.** La solicitud se vincula con un caso de Workflow, desde el que se siguen tareas, participantes y la decisión. La ruta es orientativa: el estado actual documenta los componentes funcionales, no un formulario fijo, una lista pública de etapas ni nombres de estados.
4. **Decide con evidencia.** Los responsables autorizados revisan la petición, aplican las reglas de acceso de la empresa y registran la decisión y la evidencia disponible. Puede haber aprobación parcial y tratamiento de enmascaramiento cuando el caso lo requiera; la documentación no define una política universal de enmascaramiento ni sus valores.
5. **Da seguimiento al provisionamiento.** Cuando una decisión exige provisionamiento, consérvalo como parte trazable de la gestión y verifica la evidencia asociada. La existencia de esta fase no confirma que el acceso se cree de manera automática en un sistema externo: cualquier integración y su ejecución efectiva dependen de la configuración de la empresa.
6. **Revisa el resultado por elemento.** Comprueba que tareas, decisión, posibles restricciones y evidencias se correspondan con cada destino solicitado. Si el objeto tiene relaciones con contratos, productos, reglas o fuentes técnicas, usa el mapa de relaciones para fundamentar la revisión sin inventar dependencias.

**Ejemplo sintético.** Una analista reúne en una solicitud un dashboard y un dataset asociados al Dominio Comercial. El caso se entrega a las responsabilidades configuradas. Se aprueba el dashboard y se condiciona el dataset a una medida de enmascaramiento documentada en la misma gestión. El ejemplo ilustra una decisión parcial; no describe campos ni pantallas obligatorias.

## Resultado esperado

La empresa dispone de una gestión que conecta el solicitante y los destinos requeridos con el caso, las tareas, la decisión, el provisionamiento cuando aplique y las evidencias. El resultado hace visible qué se resolvió para cada elemento sin confundir una aprobación de negocio con la creación técnica automática de un permiso externo.

La trazabilidad se conserva dentro de la empresa efectiva. El backend deriva la empresa de la sesión y verifica la membresía, el módulo y las autorizaciones; modificar identificadores o parámetros en el cliente no debe habilitar acceso a objetos de otra empresa.

## Límites del comportamiento actual

- No se publican estados de solicitudes, plazos, transiciones, formularios, catálogos cerrados de destinos ni pasos exactos de pantalla porque no están definidos como contrato funcional común.
- El carrito y la aprobación parcial no sustituyen las reglas de alcance. Tener una tarea asignada no autoriza operaciones ajenas al objeto o Dominio correspondiente.
- GovFrame documenta provisionamiento y evidencias en la gestión, pero no permite asumir que un conector o sistema destino ejecute permisos automáticamente.
- Si la decisión se apoya en SQL de una regla de calidad, solo puede generarse SQL cuando hay un campo físico asociado y un dialecto configurado. La solicitud no ejecuta ese SQL automáticamente.

## 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/)