Un colaborador necesita consultar la documentación de un proyecto durante dos semanas. La solicitud recibe el visto bueno del responsable. Aun así, quedan dos cuestiones por resolver: qué permiso ha concedido realmente el equipo de TI y quién comprobará su retirada al terminar el trabajo.
Un formulario de acceso temporal resulta útil cuando reúne esos cuatro elementos: motivo de negocio, alcance autorizado, evidencia de la intervención de TI y fecha de finalización. Folderit puede conservar el registro, tramitar la aprobación, solicitar que se completen determinados campos y enviar recordatorios. La creación de la cuenta o el cambio de permisos se realiza en el sistema que controla el acceso.
El ejemplo siguiente es una configuración orientativa basada en funciones documentadas; no describe un proceso completo probado en una cuenta real. Los eForms y el diseñador de flujos están disponibles en Tailor. Ajusta las responsabilidades y las revisiones a la política de tu organización.
Define una solicitud que pueda aprobarse sin interpretaciones
Conviene dedicar un registro a una persona, un recurso y un periodo de acceso. Si alguien necesita una carpeta de proyecto, una aplicación financiera y un rol de administración, es posible que intervengan propietarios distintos y que las condiciones de retirada también sean diferentes. Separar las solicitudes permite identificar qué se ha autorizado y qué sigue pendiente.
Describe el recurso con precisión. «Proyecto Orión / Planos publicados / Solo lectura» ofrece una instrucción más clara que «los mismos permisos que el equipo». Copiar el acceso de otra persona obligaría a TI a decidir qué privilegios forman parte de la petición.
En Herramientas de administración → Plantillas de formulario, crea la plantilla Solicitud de acceso temporal. La guía de eForms explica los tipos de campo y cómo crear el registro desde el menú de carga de una carpeta. Puedes partir de estos campos:
| Campo y tipo | Información que debe recoger |
|---|---|
| Referencia de solicitud — Texto | Una referencia acordada, por ejemplo SAT-026. Introdúcela manualmente si no has configurado la numeración por separado. |
| Persona e identificador de cuenta — Texto | Quién necesita el acceso y qué cuenta se utilizará. La persona que presenta la solicitud puede actuar en su nombre. |
| Recurso — Texto | Sistema, proyecto, carpeta u otro recurso, con su ubicación o identificador. |
| Permiso solicitado — Texto | Rol o acciones concretas permitidas y las exclusiones relevantes. |
| Justificación — Área de texto | Qué tarea requiere el acceso y por qué ese alcance es necesario. |
| Inicio solicitado y Fecha de finalización — Dos campos Fecha | Periodo propuesto. El revisor comprueba que las fechas son coherentes. |
| Detalles de horario — Texto | Hora límite y zona horaria cuando una fecha por sí sola no sea suficiente. |
| Responsable de negocio y Responsable de TI — Dos campos Usuario | Quién justifica la necesidad y quién se ocupa de la concesión y la retirada. |
Marca como obligatorios los datos necesarios para decidir. El campo Usuario selecciona a un usuario de Folderit: para un colaborador externo, identifica a un responsable interno sin dar por supuesto que el colaborador tiene cuenta en Folderit. No solicites contraseñas, claves de recuperación ni claves de API.
Añade una sección de ejecución con Estado de ejecución (Selección), Permiso concedido (Texto), Fecha de concesión (Fecha), Evidencia de ejecución (Área de texto), Fecha de retirada (Fecha) y Evidencia de retirada (Área de texto). Los estados pueden ser Pendiente, Activo, No concedido, Retirado e Incidencia en la retirada. El coordinador selecciona inicialmente Pendiente.
Deja los campos posteriores a la solicitud como opcionales al crear el registro: nadie puede aportar honestamente una fecha futura de retirada ya realizada. El estado de ejecución se mantiene de forma manual. La decisión de aprobar pertenece al flujo; evita añadir una casilla «Aprobado» que compita con ella.
Aprueba el alcance antes de encargar la intervención
Si tu política lo exige, separa la validación del responsable de negocio y la del propietario del recurso. Uno confirma la necesidad; el otro evalúa si ese permiso es adecuado. Selecciona los destinatarios reales al configurar el flujo de aprobación. Los nombres de los campos del formulario no se convierten por sí solos en destinatarios.
La resolución puede decir: «Se autoriza el acceso de la persona indicada al recurso especificado, con el permiso, las fechas y las restricciones horarias de la solicitud». Muestra esos datos al revisor. Si el alcance es excesivo o ambiguo, solicita aclaraciones y corrige el registro antes de tomar la decisión. No apruebes un permiso en un comentario mientras el formulario mantiene otro diferente.
Para un proceso sencillo, abre el menú Flujo de trabajo del registro y prepara un flujo personalizado en orden Secuencial: primero las aprobaciones necesarias y después una tarea de Completar campos para TI. Configura los criterios de finalización y rechazo según tu política. Antes de utilizarlo, comprueba expresamente que una aprobación fallida no libere la tarea de ejecución.
El indicador de aprobación documenta una decisión. No demuestra que una cuenta exista, que se haya asignado un rol ni que el acceso haya terminado. Esa diferencia debe resultar clara para quien cubra la cola de trabajo durante una ausencia.
Pide a TI que registre lo que ha hecho realmente
Los ajustes de Completar campos permiten mostrar el contexto y limitar los campos que el destinatario puede modificar en su tarea:
- En el filtro de campos visibles, elige incluir solo los seleccionados. Muestra la persona, el recurso, el permiso solicitado, las fechas, el horario y los campos de ejecución.
- En los campos editables, selecciona Estado de ejecución, Permiso concedido, Fecha de concesión y Evidencia de ejecución. Inclúyelos también entre los visibles.
- Deja el alcance aprobado visible como referencia, pero fuera de la selección editable de esa tarea.
- Explica en la nota que TI debe realizar y verificar el cambio en el sistema de destino, y después registrar el rol concedido y una referencia adecuada a la evidencia o al ticket.
Al enviar la tarea con Completar campos, se actualiza el registro existente. La fecha límite de la tarea es informativa: no cambia permisos ni equivale a un tiempo de espera automático. Asigna expresamente los destinatarios y los plazos.
Si el rol técnico disponible permite más de lo autorizado, registra la discrepancia y solicita una nueva decisión. No concedas el rol más amplio solo para cerrar el formulario. Si no se ha concedido acceso, utiliza No concedido y explica el motivo, sin inventar una fecha de ejecución.
Protege el propio registro mediante los permisos de carpetas y elementos. Los ajustes de campo regulan la experiencia de esa tarea; no sustituyen a los permisos generales de la cuenta. Un campo Responsable de TI tampoco concede acceso al registro. Restringe la edición ordinaria del alcance aprobado y somete sus cambios a una nueva aprobación.
Prepara la retirada y exige su confirmación
Define una actuación de retirada en el sistema de destino, con un responsable y una persona de respaldo. Si ese sistema admite caducidad automática, configúrala y compruébala allí. Un campo Fecha de Folderit no crea una regla de caducidad en otra aplicación.
Para anticipar el trabajo, abre el menú de acciones de la plantilla, entra en Gestionar recordatorios y añade una regla basada en Fecha de finalización. Un ejemplo razonable es dos días antes, con las condiciones Estado de ejecución igual a Activo y Fecha de retirada vacía, combinadas con Todas las condiciones (Y). Selecciona a un usuario o grupo de TI y redacta el mensaje con los marcadores que ofrece el editor.
La guía de recordatorios de formularios explica estos controles. Las condiciones se revisan al iniciar el recordatorio y cuando llega su vencimiento. El correo pide una actuación; no acredita que se haya retirado el permiso. Comprueba aparte cualquier hora exacta y zona horaria.
Tras verificar la retirada, el coordinador puede iniciar otra tarea de Completar campos para que TI indique la fecha, la evidencia y el estado Retirado. Si falla, selecciona Incidencia en la retirada y anota el siguiente responsable y la actuación pendiente. Sigue entonces el procedimiento de escalado de tu organización.
No cambies silenciosamente la fecha final para eliminar una entrada vencida. Tramita la ampliación mediante una nueva solicitud o el procedimiento de cambio aprobado, conservando la decisión anterior y el motivo.
Haz visible la diferencia entre autorizado, activo y retirado
Configura las columnas de la carpeta con persona, recurso, fecha final, responsable de TI, estado y fecha de retirada. Con los filtros de metadatos, revisa los registros cuyo plazo ha pasado y que siguen Activos o tienen una incidencia. El filtro general Fecha no es necesariamente la Fecha de finalización de tu formulario.
Contrasta el registro con el sistema de destino. Una fecha de retirada vacía puede significar que el acceso sigue activo o que alguien olvidó documentar una retirada ya realizada. Ambas situaciones requieren comprobación. El historial de flujos conserva participantes, decisiones, comentarios y fechas, y su resumen ayuda a revisar la secuencia de autorización.
Ejemplo ficticio: SAT-026 solicita lectura de los planos publicados del proyecto Orión del 2 al 13 de noviembre. El propietario autoriza ese alcance. TI registra el grupo utilizado, la fecha y el ticket CAM-481, y selecciona Activo. Una vez confirmada la retirada en el sistema de destino, registra la evidencia y cambia el estado a Retirado. Si el grupo disponible también permite editar, la autorización inicial de solo lectura no basta.
La separación encaja con la distinción del Marco de Ciberseguridad 2.0 de NIST, PR.AA-05 entre definir, gestionar, aplicar y revisar permisos. El formulario contribuye a documentar las decisiones y revisiones; el control efectivo corresponde al sistema que da acceso. Este ejemplo no constituye una garantía de conformidad.
Antes de extender la configuración, prueba una aprobación, un rechazo, una solicitud incompleta, un rol técnico más amplio y una retirada fallida. Verifica qué campos puede editar TI, a quién llegan los recordatorios y si el registro permite localizar el trabajo pendiente con los permisos de un usuario ordinario.
