Cómo configurar un flujo de aprobación de documentos con roles de equipo en Chaindoc

Un flujo de aprobación de documentos es el camino que sigue un contrato desde el borrador hasta la firma: quién puede abrirlo, quién tiene que aprobarlo, en qué orden y qué registro queda. En Chaindoc ese camino se apoya en dos ajustes. Los roles deciden quién ve y edita un documento dentro de tu equipo. En el plan Business, una ruta de aprobación fija el orden en que se aprueba y se firma. Todo lo demás, desde la primera invitación hasta el registro de auditoría, cuelga de esos dos ajustes. Esta guía explica cómo configurarlos con la gestión de equipos de Chaindoc, qué incluye cada plan y dónde herramientas más grandes, como SharePoint, llegan más lejos.

La mayoría de los problemas de un flujo de aprobación de documentos empiezan antes de la aprobación. Un borrador acaba en la unidad compartida, el enlace circula y, cuando el área jurídica lo abre, cinco personas lo han leído y dos lo han editado.

En muchas herramientas ese es el ajuste por defecto. En Google Drive, quien tenga el rol de editor puede compartir el archivo y cambiar sus permisos mientras el propietario no lo desactive, y el acceso que das a una carpeta se hereda en todos los archivos que contiene (Ayuda de Google Drive). Cómodo para una presentación. Menos para un contrato con un proveedor donde aparecen tus márgenes.

El control de acceso a documentos en Chaindoc funciona en dos niveles, y hay un tercero para desarrolladores:

• Espacio de trabajo. Cada usuario tiene uno personal y los planes de equipo añaden uno compartido. No se solapan: un borrador guardado en tu espacio personal no lo ve el equipo. Los contratos del equipo van en el espacio compartido.
• Rol. Dentro del espacio compartido, lo que alguien puede hacer con un documento (verlo, editarlo, aprobarlo, firmarlo) depende del rol que tenga, no de un enlace que alguien reenvió.
• A través de la API de Chaindoc, que requiere el plan Business, cada documento lleva un tipo de acceso: privado (private), público (public) o restringido (restricted). En un documento restringido, las personas que pueden abrirlo constan por correo electrónico, cada una con un nivel como read.

Nuestra regla práctica: da el borrador a quienes tienen que leerlo antes de la aprobación, no a todos los que sientan curiosidad. Puedes ampliar el acceso después de la firma. Recuperarlo cuando alguien ya descargó el archivo no funciona. Si el contrato incluye datos personales, esto es más que cortesía: más abajo verás los artículos 25 y 32 del RGPD.

Un límite honesto: los archivos viajan por TLS, pero no hay cifrado de extremo a extremo, así que los servidores de Chaindoc pueden leer lo que procesan. Dentro de tu empresa, los roles hacen que un contrato esté ante los ojos adecuados.

El control de acceso basado en roles (RBAC) asigna permisos a un rol y después da el rol a las personas. El glosario del NIST lo describe como control de acceso basado en los roles de los usuarios, siendo un rol un conjunto de autorizaciones de acceso. En el día a día es la gestión de permisos: quién puede hacer qué con cada documento. Si alguien cambia de puesto, cambias un rol y su acceso lo sigue.

La gestión de equipos de Chaindoc trae cuatro roles integrados, la mitad de acceso de cualquier flujo de aprobación de documentos:

• Owner: todos los derechos sobre los documentos más los controles de administración del equipo. Suele ser quien fundó la empresa o quien lleva el presupuesto.
• Admin: gestiona usuarios y vigila los flujos. Normalmente, la persona de operaciones o de administración.
• Member: lee y edita dentro de los permisos que el rol permite. Aquí está la mayor parte del equipo.
• Accounter: ve la parte financiera y analítica de los documentos. Piensa en quien lleva la contabilidad o en la asesoría externa.

Cada rol integrado se puede ajustar, y puedes crear tantos roles propios como necesites, con cualquier combinación de permisos. Vemos mucho dos: un rol de revisión jurídica, que ve y aprueba contratos pero no los envía, y un rol comercial, que redacta y envía pero nunca aprueba. Los cambios que hagas en la pestaña Roles se aplican al instante a todos los flujos activos.

¿Bastan cuatro roles? Para un equipo de cinco a cincuenta personas, normalmente sí. Las suites para grandes empresas ofrecen listas más largas. En nuestra experiencia, los equipos pequeños rara vez las necesitan, y cada rol de más es uno más que alguien tendrá que revisar cada trimestre.

El principio de los cuatro ojos dice que dos personas deben intervenir antes de que algo importante cuente: un pago, un cambio en un registro, un contrato. En auditoría se habla de forma más amplia de segregación de funciones (separation of duties, en inglés). La definición del NIST es tajante: ningún usuario debería recibir privilegios suficientes para abusar del sistema por sí solo (glosario del NIST). La misma entrada distingue dos casos. La separación estática impide dar roles incompatibles a una misma persona. La dinámica actúa en el momento de la acción, y la regla de las dos personas es el ejemplo clásico.

En España y en México la idea forma parte del control interno. El Esquema Nacional de Seguridad (Real Decreto 311/2022) la recoge en la medida op.acc.3, "Segregación de funciones y tareas": las tareas críticas deben exigir la concurrencia de dos o más personas. Se aplica al sector público y a las entidades privadas que le prestan servicios. En las entidades de interés público, la comisión de auditoría supervisa la eficacia del control interno (artículo 529 quaterdecies de la Ley de Sociedades de Capital, al que remite la Ley 22/2015, de Auditoría de Cuentas). En una pyme, el equivalente de cada día son los poderes mancomunados: dos apoderados firman juntos, o el apoderado legal solo firma cuando el área jurídica ha aprobado. Un flujo de aprobación de documentos lleva esa regla al propio documento, en lugar de dejarla en la cabeza de la dirección.

En un equipo que maneja contratos, eso se traduce en tres hábitos:

1. 1.
   Quien redacta un contrato no es quien lo aprueba.
2. 2.
   Los contratos grandes llevan más de un nombre entre el borrador y la firma.
3. 3.
   Finanzas ve cuánto vale un contrato sin poder reescribirlo.

Nada de esto requiere un programa especial. Requiere que alguien decida y una herramienta que recuerde la decisión.

Mínimo privilegio, en lenguaje llano

El NIST (SP 800-12) define el mínimo privilegio como limitar el acceso de cada usuario a lo necesario para sus tareas. En Chaindoc eso significa que Member es lo normal, Admin la excepción y Owner, cosa de una o dos personas. La verdad es que la mayoría de los equipos pequeños lo hacen al revés: las cinco primeras personas acaban de Admin porque era más rápido, y nadie lo revisa más.

Dónde encaja la ruta de aprobación en un flujo de aprobación de documentos

Los roles cubren la mitad estática; la ruta, la dinámica. Una solicitud de firma normal en Chaindoc invita a todos los destinatarios a la vez, y quien la abre primero firma primero. En el plan Business, una ruta de aprobación fija la secuencia: la siguiente persona recibe el documento solo cuando la anterior ha actuado. Primero jurídico, después la dirección financiera, después la gerencia. Si tu política dice que los contratos por encima de cierto importe necesitan al director financiero, deja la regla por escrito y que quien envía el contrato elija la ruta que corresponde. Una ruta fija el orden, no umbrales de importe.

Los roles y el espacio compartido, la parte de acceso de un flujo de aprobación de documentos, empiezan en el plan Team. El orden fijo exige Business, igual que el acceso a la API. Las cifras de abajo salen de los planes de Chaindoc tal como estaban publicados el 20 de septiembre de 2026; la página de precios tiene las vigentes. Si comparas software de flujo de aprobación por precio, cuenta también los puestos: cada miembro adicional cuesta 19 € al mes como extra en los dos planes de equipo.

Falta una cifra a propósito. El número de firmas mensuales del plan Team muestra un valor en la ficha del plan y otro en su configuración. Preferimos remitirte a la página de precios que imprimir el equivocado.

Un flujo de aprobación de documentos solo sirve si después puedes demostrar quién aprobó qué. Chaindoc guarda la prueba en dos sitios, y cada uno tiene su función.

El registro de auditoría es el registro de eventos propio de la aplicación para el documento. Sus entradas están encadenadas con hashes, de modo que una entrada que falte o se haya alterado rompe la cadena. Puedes exportarlo en PDF, y hay un informe de verificación en PDF aparte para el archivo firmado. Si usaste una verificación de identidad, su resultado también queda en el registro.

La blockchain guarda dos momentos: el hash de la versión al publicar y la prueba de cada firmante cuando termina la firma. Contra ese hash comprueba el archivo una verificación posterior.

En la práctica, la mayoría de los desacuerdos nunca llegan a la cadena. Se resuelven con un registro legible de quién hizo qué, y por eso la exportación en PDF pesa más en el día a día. Qué suelen pedir un auditor o un tribunal lo cuenta cómo resiste una auditoría el registro de una firma electrónica.

Antes de comprar software de aprobación de documentos, mira lo que ya tienes. Muchos equipos ya llevan un flujo de aprobación en una herramienta que poseen, o creen que lo llevan. Esto es lo que cubren las tres más habituales.

SharePoint y Power Automate

Un flujo de aprobación de SharePoint suele ser un flujo de Power Automate. El tutorial de Microsoft lo construye alrededor de la acción "Aprobaciones - Iniciar y esperar a una aprobación", y los aprobadores responden desde su bandeja de entrada, el centro de aprobaciones o la aplicación móvil (Microsoft Learn). Las aprobaciones secuenciales y las paralelas tienen cada una su guía, y los invitados de fuera de la empresa pueden aprobar mediante Microsoft Entra. La pega: el flujo lo construyes y lo mantienes tú, y el tutorial dice sin rodeos que la seguridad queda fuera de su alcance.

DocuSign

Quien busca los roles y permisos de DocuSign suele dar con sus tres perfiles de permisos predeterminados: DS Admin, DS Sender y DS Viewer. DocuSign también documenta en su centro de soporte un flujo de aprobación interno. Un flujo de aprobación de DocuSign es, por tanto, una tarea de configuración en una cuenta que quizá ya pagas.

Google Drive

Los permisos de Google Drive para compartir son tres roles: lector, comentador y editor. Deciden quién puede abrir, comentar y modificar un archivo. Quién lo aprueba y quién lo firma es otra pregunta, que se responde en otro sitio.

Dónde van por delante: Power Automate puede condicionar una aprobación a casi cualquier criterio y ejecutarla entre SharePoint, Dynamics 365 o Salesforce, y los aprobadores de Microsoft 365 usan las cuentas de empresa con las que ya inician sesión. Chaindoc no tiene inicio de sesión único ni aprovisionamiento SCIM. Se entra con contraseña o con una cuenta de Google, GitHub o Apple, y a quienes se van los das de baja a mano. Lo que Chaindoc reúne en un solo sitio son el acceso, el orden, la firma y el registro del mismo contrato.

No. El artículo 25, apartado 1, del reglamento eIDAS impide negar a una firma electrónica efectos jurídicos y admisibilidad como prueba en un procedimiento judicial por el solo hecho de ser electrónica; en España lo completa la Ley 6/2020, reguladora de determinados aspectos de los servicios electrónicos de confianza. En México, el Código de Comercio dispone que no se niegan efectos jurídicos, validez ni fuerza obligatoria a la información por estar en un mensaje de datos (art. 89 bis) y que, si la ley exige la firma de las partes, se cumple cuando el mensaje de datos es atribuible a ellas (art. 93). Tu flujo de aprobación de documentos es gobierno interno, no parte de cómo se forma el contrato. Lo que cambia es tu posición si alguien alega después que el contrato se firmó sin poder suficiente.

El acceso aparece dos veces en la ley. El mismo artículo 93 pide que la información se mantenga íntegra y sea accesible para su ulterior consulta, y la NOM-151-SCFI-2016 regula la conservación de mensajes de datos. Así que el control de acceso funciona en los dos sentidos: aparta a quien no debe ver un contrato, pero no dejes sin acceso a quien debe poder consultarlo. Para los plazos, mira cuánto tiempo conservar los contratos firmados.

Si tus contratos contienen datos personales, el artículo 25.2 del RGPD pide que, por defecto, no se hagan accesibles a un número indeterminado de personas, y el 32.4, que quien tenga acceso solo los trate siguiendo las instrucciones del responsable. En México, la LFPDPPP vigente desde 2025 exige medidas de seguridad frente al acceso no autorizado (art. 18) y controles para que quienes intervengan en el tratamiento guarden confidencialidad (art. 20). Un enlace que cualquiera puede abrir encaja mal con todo eso. Esto es información general, no asesoramiento jurídico para tu empresa.

Los mismos cinco fallos aparecen una y otra vez:

• Todos son Admin. Pasó durante la puesta en marcha y se quedó así. Reduce el grupo a una o dos personas.
• El flujo de aprobación de contratos vive en la cabeza de alguien. Cuando esa persona no está, los contratos se paran o salen sin aprobar. Pon las rutas por escrito y nómbralas por tipo de contrato.
• Las aprobaciones se hacen por correo. Un "me parece bien" en un hilo no queda en el registro de auditoría, y seis meses después nadie lo encuentra.
• Quien se va conserva el acceso. Sin aprovisionamiento automático, la baja de una persona necesita una línea en la lista de tareas: quitarla de Chaindoc.
• La versión aprobada no es la firmada. Si se edita después de aprobar, hace falta una nueva versión publicada y otra pasada por la ruta. El hash de la versión anterior ya está en la blockchain, que es justo lo que quieres cuando alguien pregunta qué cambió.

Arregla esos cinco y un flujo de aprobación de documentos en Chaindoc casi se cuida solo. Los roles mantienen privados los borradores, la ruta mantiene el orden y el registro responde a las preguntas después.