Guía del usuario Cancelar

Asignar usuarios a varios grupos

 

Guía de Adobe Acrobat Sign

Novedades

Introducción

Administrar

Enviar, firmar y administrar acuerdos

Capacidades y flujos de trabajo de acuerdos avanzados

Integrar con otros productos

Acrobat Sign Desarrolladores

Soporte y solución de problemas

Al permitir que los usuarios envíen acuerdos desde más de un grupo, los administradores pueden vincular fuertemente las plantillas de biblioteca, la autenticación de los destinatarios y los requisitos de firma a un grupo, lo que permite que el flujo de trabajo defina la naturaleza del grupo en lugar de los usuarios que contiene.

Información general

Cuando se crea un acuerdo, la configuración de nivel de grupo es la que dicta principalmente los recursos disponibles (plantillas/flujos de trabajo) y las propiedades del acuerdo que afectan al sistema (personalización de marca, funciones de destinatario, métodos de autenticación, seguridad/conservación del PDF, etc.).

Estar bloqueado en un grupo significa que cualquier ID de usuario individual está bloqueado en un conjunto de valores predeterminados, un conjunto de plantillas y flujos de trabajo, y un concepto de cumplimiento de firma.

Permitir que los usuarios accedan a varios grupos abre la puerta para que los administradores piensen en los grupos como algo más que una colección de usuarios. Los grupos se pueden ver como un entorno para los requisitos específicos de firma de documentos a los que se concede acceso a los usuarios.

Por ejemplo, un grupo se puede diseñar alrededor de un conjunto de reglas muy estrictas de firma y distribución relacionadas con el cumplimiento, y otro se puede configurar para flujos de trabajo y plantillas de autenticación internos y de baja calidad. Un usuario asignado a ambos grupos puede acceder a todos los recursos de cada grupo.

Los administradores de nivel de grupo también tienen la capacidad de administrar más de un grupo, lo que mejora el uso práctico de la función de administrador de nivel de grupo.

Nota:

Este documento está diseñado para resaltar los cambios que UMG aporta a la interfaz/funcionalidad de los usuarios, e identificar las consideraciones que la migración a UMG provoca para los administradores.

Requisitos previos

  • Únicamente las cuentas de nivel empresarial pueden habilitar a los usuarios de varios grupos.
  • Asegúrese de que la seguridad de la red permite explícitamente el acceso a permitir los terminales de Acrobat Sign.
  • La versión más reciente de la interfaz de Flujos de trabajo personalizados, Inicio y Administrar debe estar habilitada para la cuenta.
    • Al cambiar la cuenta para permitir que los usuarios estén en varios grupos activa automáticamente las nuevas versiones de página (si aún no están activadas) y desactiva las opciones para volver a la interfaz heredada.  Esto incluye los vínculos de “Cambiar”
      • Las páginas heredadas de Flujo de trabajo/Inicio/Administrar son incompatibles con los usuarios de varios grupos.
      • Desvincularse de UMG no restablece sus páginas de Inicio/Administrar.
  • Para garantizar la funcionalidad, revise las integraciones compatibles con Acrobat Sign, el desarrollo de API personalizadas y las integraciones de terceros en una cuenta de desarrollador.

El grupo principal

A todos los usuarios bajo las reglas de UMG se les asigna un “grupo principal”.  El grupo principal es:

  • El grupo predeterminado que el usuario carga al entrar la página Enviar.
  • El grupo que define la autoridad/los parámetros de firma de los ID de usuario si se envía un acuerdo a su dirección de correo electrónico.
  • El grupo al que se hace referencia si se necesita una configuración de nivel de grupo y el origen solicitante no tiene conocimiento de UMG.
    • Por ejemplo: las integraciones de Acrobat Sign pueden abarcar varias versiones. Las versiones anteriores que no son compatibles con UMG necesitan un valor predeterminado al que hacer referencia, que sería el grupo principal.

Asociación grupal de activos

Los acuerdos, los formularios web y los eventos de Envío en bloque creados antes de habilitar UMG solo están relacionados con la creación de userID.

Los acuerdos, formularios webs y eventos de Envío en bloque creados después de habilitar UMG están relacionados con el groupID creado, además del userID que los creó.

En la práctica, esto significa que los activos creados antes de habilitar UMG se moverán con el usuario si se cambia el grupo principal del usuario. Los usuarios que vean el grupo (mediante el uso compartido de la cuenta) perderán la visibilidad de estos activos cuando el usuario se mueva fuera del grupo compartido.

Los activos creados después de activar UMG seguirán estando relacionados con el grupo. Los usuarios que vean el grupo seguirán viendo los activos creados en el grupo después de que el usuario que los crea se mueva a un nuevo grupo principal.

Cómo habilitar la opción de tener usuarios en varios grupos

Solo un administrador del nivel de cuenta puede activar o desactivar UMG. Consulte este artículo para obtener instrucciones para actualizar su cuenta.

Se puede revertir desde UMG, con los siguientes efectos considerables:

  • Se borran todos los indicadores de administrador de nivel de grupo.
    • Los indicadores de administrador de nivel de cuenta no se ven afectados.
    • Los administradores de nivel de grupo pueden recuperar su derecho con respecto a sus grupos exclusivos.
  • Todos los usuarios existen únicamente dentro de su grupo principal.
Nota:

Un usuario puede ser miembro de hasta 100 grupos.

Diferencias a nivel de usuario

Los cambios a nivel de usuario son amplios. Todos los usuarios que puedan iniciar sesión Acrobat Sign observarán los cambios siguientes:

Diferencias de administración de nivel de grupo

Estos cambios en la interfaz solo los pueden observar los administradores de la cuenta (tal y como permiten los controles de administración de nivel de cuenta):

La función del administrador de nivel de grupo se ha mejorado significativamente, ya que un usuario puede ser el administrador de varios grupos y no es necesario que sea el administrador de todos los grupos a los que pertenezca.

Los administradores de nivel de grupo de varios grupos pueden administrar mejor los documentos y flujos de trabajo para equipos más amplios, e informar sobre el contenido de varios grupos sin tener acceso al conjunto de datos completo de la cuenta.

Diferencias de administración a nivel de grupo

Solo los administradores de nivel de cuenta tienen acceso a lo siguiente:

Diferencias de administración de nivel de privacidad

Las herramientas de administración de nivel de privacidad no se modifican actualmente mediante la configuración de UMG.

Diferencias de API

Nota:

Solo se actualizará la versión 6 de la API REST para adaptarse a UMG.

La API SOAP heredada no se actualizará para adaptarse a UMG.

El uso de las API SOAP o la versión 5 de la API REST (y versiones anteriores) funcionará sin el conocimiento de UMG y el grupo principal del usuario estará en vigor.

Los extremos de la versión 6 de la API REST que se ejecutan en el contexto de un grupo específico se han ampliado para incluir un identificador opcional groupId, que se puede transferir a una solicitud como parámetro de consulta, como encabezado o como parte del cuerpo de la solicitud.  

Este parámetro es opcional y, si se omite, el código establece de forma predeterminada el grupo principal del usuario. 

Las acciones específicas del grupo se dividen en dos categorías:

  • Administración de usuarios
  • Operaciones de CRUD en recursos

El cambio en la administración de usuarios se incluye en la capacidad de administrar varias membresías de grupo en una llamada de la API y en la expansión del modelo de seguridad, que afecta a las capacidades de administración de grupo; es decir, se asegura de que el administrador de grupo no produzca ningún cambio en un grupo fuera de su alcance.

El cambio en las operaciones de recursos es el parámetro adicional de ID de grupo para los modelos de solicitud/respuesta, que proporciona un contexto de grupo para los acuerdos, formularios web y eventos de Envío en bloque

El parámetro ID de grupo solo se agrega a la versión 6 de la API REST. Las versiones siguientes a la versión 6 de REST utilizan el grupo principal para la compatibilidad con versiones anteriores.


INVALID_GROUP_ID

Se activa un código de respuesta de error común “INVALID_GROUP_ID” si:

  • No se ha encontrado el grupo identificado.
  • El usuario identificado no es miembro del grupo identificado.
  • La función está deshabilitada y el ID de grupo no coincide con el grupo principal del usuario. 

Si UMG no está habilitado, todos los terminales existentes se comportan como antes. El grupo principal del usuario se utiliza como único abono de grupo válido y, si se transfiere otro identificador de grupo a un extremo, se vuelve a mostrar el error INVALID_GROUP_ID

Añadir usuarios a varios grupos

La adición de un usuario a varios grupos se realiza de dos maneras:

Creación de acuerdos

Las reglas de UMG son observables al comienzo del proceso para crear un nuevo acuerdo.

Si un usuario inicia el proceso seleccionando una plantilla o flujo de trabajo de la página Inicio > Inicio desde la biblioteca, el usuario debe expandir el grupo desde el que envía primero y, a continuación, seleccionar la plantilla o flujo de trabajo de las opciones disponibles en el grupo.  

Al seleccionar la plantilla/el flujo de trabajo y hacer clic en Inicio se abre la página Enviar lista para que el usuario complete la configuración.

Nota:

Al iniciar el acuerdo desde una plantilla o flujo de trabajo de nivel de grupo, el valor de grupo se inserta en la página Enviar y se suprime la opción de editar el grupo.

Si se selecciona un flujo de trabajo/plantilla de nivel de cuenta, el remitente tiene la opción de seleccionar el valor del grupo.

Iniciar un acuerdo desde la plantilla o el flujo de trabajo

 

Si el usuario inicia el proceso desde la página Enviar, el campo desplegable Enviar desde define el grupo con el que está relacionado el acuerdo.

Al seleccionar el grupo, el acuerdo se limita a las plantillas de biblioteca disponibles para el grupo seleccionado.

Al cambiar el grupo, se cambian las propiedades aplicadas al acuerdo.  Esto obliga a que la página se actualice y se pierde cualquier contenido de nivel de campo que se haya introducido.

Inicio de un acuerdo desde Enviar

Diseñador de flujo de trabajo personalizado

La creación y administración de flujos de trabajo personalizados no se ha visto afectada por las reglas de UMG hasta ahora:

  • Los flujos de trabajo asignados a un grupo solo los puede editar un administrador (de nivel de grupo o de cuenta) que tenga su grupo principal establecido como el mismo grupo al que está dedicado el flujo de trabajo.
  • Los flujos de trabajo asignados al nivel de cuenta solo los puede editar un administrador de nivel de cuenta (independientemente del grupo principal).

En futuras actualizaciones, a los administradores se les ofrecerán las opciones de interfaz para asociar los flujos de trabajo que creen con grupos individuales en los que tengan autoridad de administración, independientemente de su grupo principal.

Creación y administración de plantillas de biblioteca

La creación de una plantilla de biblioteca reutilizable sujeta a las reglas de UMG tiene un paso adicional cuando se otorga permiso de acceso a la plantilla a nivel de grupo:

Defina el grupo al que está asociada la plantilla de biblioteca. 

  • Esto se hace en un submenú cuando se selecciona el permiso Usuarios que pueden usar esta plantilla:
Nota:

El ID de usuario original que crea una plantilla se entiende como el “propietario” de esa plantilla. 

El propietario de la plantilla siempre tiene acceso a la plantilla para Enviar o Editar. No importa el nivel de autoridad que tenga el ID de usuario propietario, o si el propietario está asociado al grupo al que está expuesta la plantilla.

Crear una plantilla de biblioteca

Administración de plantillas de biblioteca existentes

Las plantillas de biblioteca existentes pueden editar sus propiedades a través de la página Administrar.

Abra la plantilla para editarla y, si la plantilla se comparte con Cualquier usuario de mi grupo, el editor puede cambiar la asociación de grupo:

Edición de las propiedades de una plantilla

Nota:

El cambio de la asociación de grupo no afecta a la afiliación de grupo para los acuerdos que ya se hayan creado.

Creación y administración de formularios web

La creación de un formulario web sujeto a las reglas de UMG tiene un paso adicional:

Defina el grupo al que está asociado el formulario web.  Esto se hace en la parte superior de la página.

  • Establezca el valor del grupo en primer lugar, ya que al cambiar el grupo se restablece la página y se borra el contenido de cualquier nivel de campo.
Creación de un formulario web

Precaución:

El grupo asociado no se puede editar una vez que el formulario web se haya creado.

Administración de formularios web existentes

Las reglas de UMG no afectan al modo en que se administran los formularios web existentes (ya que el grupo asociado no se puede editar).

La creación de informes en el formulario web requiere que el creador ejecute el informe o que un administrador tenga autoridad para los datos del informe en el grupo.

Uso compartido de contenido

Compartir un acuerdo individual o una plantilla no se ve afectado por las reglas de UMG.

Las reglas de UMG no afectan a las cuentas que utilizan uso compartido de cuentas estándar (solo Usuario o uso compartido de Usuario).

El uso compartido avanzado de cuentas permite compartir entre usuarios, entre grupos y entre usuarios y grupos:

 

Retención de documentos/RGPD

No se esperan cambios en el conjunto de herramientas del Reglamento General de Protección de Datos (RGPD) con respecto a los cambios del UMG.

Integraciones

Todas las cuentas de nivel empresarial pueden habilitar UMG, incluso cuando se hayan configurado una (o varias) integraciones.

Actualmente, las siguientes integraciones admiten parámetros UMG:

  • Salesforce
  • Power Automate
  • Microsoft 365 (Teams, Outlook, Word/PowerPoint)

Los usuarios que envían acuerdos a través de una integración que no tiene en cuenta UMG se consideran que están en su grupo principal solamente, y los parámetros de envío se alinearán con la configuración del grupo principal en consecuencia.

 

API - REST v6

Muchos de los extremos de la versión 6 de API REST han añadido al método un parámetro opcional para el ID de grupo.

La expectativa actual es que cualquier llamada a la versión 6 de API REST existente seguirá funcionando, independientemente de si UMG está activado o no.

Las versiones anteriores de la API (SOAP y REST) seguirán funcionando según lo previsto, entendiendo al usuario únicamente como miembro de su grupo principal.

Obtén ayuda de forma más rápida y sencilla

¿Nuevo usuario?