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.
Cuando se crea un acuerdo, la configuración de nivel de grupo es la que dicta principalmente los activos disponibles (plantillas/flujos de trabajo) y las propiedades infligidas por el sistema del acuerdo (marca, funciones de destinatario, métodos de autenticación, seguridad/retención de 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.
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.
A todos los usuarios bajo las reglas de UMG se les asigna un "grupo principal". El grupo principal es:
Objetos y herencia (objetos principales-secundarios)
"Objeto" es un término utilizado para describir una colección de propiedades que representa una idea. Su Cuenta es un tipo de objeto, al igual que su Usuario.
Dentro de una aplicación como Acrobat Sign, los objetos se pueden utilizar como plantillas para crear otros objetos; cuando se crea un objeto a partir de un objeto "plantilla", se dice que estos dos objetos tienen una relación principal-secundario.
Dado que un objeto secundario es una copia directa del principal, la configuración es idéntica. El objeto secundario hereda los valores de propiedad del principal. Si cambia un valor principal, el objeto secundario también heredará ese cambio.
Un árbol de objetos en Acrobat Sign es el grupo de propiedades de Cuenta > Grupo > Usuario.
Al observar la cadena de objetos Cuenta > Grupo > Usuario, puede ver fácilmente cómo al desplazar un usuario a un nuevo grupo se cambia la funcionalidad "predeterminada" del usuario debido a los nuevos parámetros heredados del grupo.
Se permite cambiar un valor de propiedad de un objeto secundario y este cambio explícito generalmente rompe la herencia de dicho valor de propiedad del objeto principal. Si el objeto principal cambia el valor de dicha propiedad, el elemento secundario no heredará el nuevo valor, ya que el valor establecido explícitamente tiene prioridad.
Esto se puede ver mejor cuando los administradores de nivel de grupo anulan la configuración de nivel de cuenta de su grupo. Y como los usuarios del grupo son objetos secundarios del grupo en el que están, la experiencia de usuario cambia.
Los usuarios que tienen acceso a varios grupos cambian sus propiedades heredadas al cambiar el grupo desde el que actúan. Observará que cuando un usuario cambia su grupo en la página Enviar, la página se actualiza a medida que se cargan las nuevas propiedades de nivel de grupo. Esto se nota más si tiene una marca de logotipo única por grupo.
Objeto ID
Cada objeto tiene un número de identificación único. Este ID exclusivo permite a la aplicación diferenciar los objetos de un tipo similar y relacionarlos entre sí.
Las implicaciones de los ID de usuario y de grupo se hacen más evidentes según las reglas de UMG, particularmente en cuanto a los informes. Cuando un usuario crea un activo en el sistema (acuerdo, plantilla, formulario web), el ID de usuario del creador y el ID de grupo en el que se creó el activo se codifican en el activo.
Cuando un usuario ejecuta un informe para sus acuerdos, la aplicación devuelve los datos relacionados con su ID de usuario. El ID de grupo no es relevante para la búsqueda (a menos que se aplique un filtro).
Sin embargo, cuando un administrador de grupo ejecuta un informe para un grupo, la aplicación devuelve los datos relacionados con el ID de grupo (independientemente del ID de usuario que lo haya creado).
Cuando los usuarios sólo podían existir en un grupo, no se observaba prácticamente ninguna diferencia. Con los usuarios que crean activos en varios grupos, es posible que el contenido de un usuario abarque los grupos de más de un administrador de nivel de grupo.
Los administradores de nivel de grupo solo pueden acceder al contenido generado dentro de los ID de grupo en los que tienen autoridad (excepto el contenido que crean personalmente). Si un administrador de grupo informa sobre el contenido de un ID de usuario, el conjunto de datos devuelto solo incluye el contenido (creado por el ID de usuario) dentro de los grupos donde son administradores.
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.
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:
Un usuario puede ser miembro de hasta 100 grupos.
Los cambios a nivel de usuario son ubícuos. Todos los usuarios que puedan iniciar sesión Acrobat Sign observarán los cambios siguientes:
Novedades:
El perfil del usuario muestra completamente todos los grupos en los que está incluido el usuario y marca específicamente el grupo principal.
Con UMG activado:
Novedades:
Como el usuario tiene acceso a varios grupos, las plantillas y los flujos de trabajo disponibles para el usuario se agrupan por el grupo al que se relaciona la plantilla/flujo de trabajo.
Si se utiliza una plantilla de nivel de grupo, el grupo se inserta en la página Enviar y se suprime la opción de editar el grupo:
Si se utiliza una plantilla de nivel de cuenta, el grupo se puede seleccionar (desde los grupos a los que pertenece el usuario):
Novedades:
La página Enviar presenta un selector desplegable en la parte superior de la página: Enviar desde
Este selector permite al remitente seleccionar el grupo (y todas las propiedades de nivel de grupo relacionadas) que rige las propiedades y las opciones de la transacción.
Puntos que se deben tener en cuenta:
Establezca el selector Enviar desde en primer lugar.
Novedades:
Al igual que en la página Enviar, la página Firma automática incluye un selector desplegable en la parte superior: Seleccionar grupo
Este selector permite al remitente seleccionar el grupo (y todas las propiedades de nivel de grupo relacionadas) que determina las propiedades y opciones de la transacción.
Puntos que se deben tener en cuenta:
Establezca el selector Enviar con en primer lugar.
Novedades:
Se ha añadido una etiqueta de identificación al menú contextual del acuerdo para indicar el grupo desde el que se ha enviado un acuerdo.
Puntos que se deben tener en cuenta:
Algunas funciones están fuertemente vinculadas al grupo (p. ej., los parámetros de informes y las reglas de retención).
Novedades:
Se ha añadido una columna a la tabla de acuerdos que se genera en la página Administrar.
Novedades:
Hay un nuevo filtro disponible para filtrar el conjunto de datos de la página Administrar por Grupo.
Novedades:
Al crear una plantilla de biblioteca, el creador tiene la opción de establecer las propiedades de acceso a la plantilla y compartir el acuerdo con cualquier grupo del que sea miembro.
Puntos que se deben tener en cuenta:
Un usuario con acceso a todos los grupos se puede utilizar como administrador central de documentos.
Un usuario con autoridad para crear formularios web puede asociar su formulario a cualquier grupo del que sea miembro.
Novedades:
Se ha agregado un filtro a la página Informes para permitir que el informe se limite a los acuerdos relacionados con uno o más grupos.
El informe con formato .csv sigue teniendo la misma columna Grupo del remitente, que realiza un seguimiento cuando un remitente cambia entre grupos:
Si se elimina a un usuario de un grupo desde el que ha enviado acuerdos anteriormente, no podrá informar sobre dichas transacciones.
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.
Novedades:
Si el usuario es administrador de más de un grupo, Flujos de trabajo y Bibliotecas compartidas se han trasladado del nivel superior de las opciones de menú del administrador del grupo a submenús para cada grupo individual:
Cuando UMG está activado, en primer lugar debe seleccionar el grupo y, a continuación, abrir la configuración de grupo para acceder a los elementos y ajustes de menú específicos del grupo:
Novedades:
Cuando un administrador de grupo tiene autoridad administrativa sobre más de un grupo, el administrador debe seleccionar primero el grupo que desea configurar:
Novedades:
El administrador de nivel de grupo ya no tiene la opción de forzar una vista de los acuerdos para los usuarios recién creados.
Novedades:
Para agregar un usuario a su cuenta, en primer lugar deberá seleccionar un grupo para obtener acceso a la opción de menú Usuarios en grupo.
Al crear usuarios individuales, el grupo seleccionado define el grupo principal para el usuario.
Los administradores de nivel de grupo no tienen autoridad para editar el grupo principal una vez creado el usuario.
El proceso para crear un usuario es el mismo, excepto la opción para forzar un recurso compartido de vista a los acuerdos del usuario (ver la información indicada anteriormente).
Puntos que se deben tener en cuenta:
La creación individual de usuarios no permite incluir al usuario en varios grupos como parte del proceso de creación.
Después de crear el usuario, el administrador del grupo puede editar el perfil de usuario para incluir al usuario en más grupos y editar su autoridad de envío.
Novedades:
La autoridad para determinar si un ID de usuario puede firmar acuerdos y la posibilidad de instalar una regla de delegación automática para un ID de usuario se han eliminado de la interfaz de administración de nivel de grupo.
Los administradores de nivel de grupo tienen autoridad para permitir o no permitir la pertenencia de un usuario a cada uno de los grupos que administren mediante el perfil del usuario.
Para añadir miembros del grupo:
Los usuarios que se coloquen por primera vez en un grupo adoptarán dos valores de autoridad:
Marque o anule la marcación de los valores por grupo según sea necesario
Los administradores de nivel de grupo no tienen autoridad para editar el grupo principal de un ID de usuario a menos que tengan autoridad administrativa tanto en el grupo principal original como el nuevo grupo.
Para eliminar a un usuario de un abono de grupo:
Si un usuario tiene su abono de grupo revocado para todos los grupos:
Los administradores de nivel de grupo que crean webhooks pueden seleccionar cualquier grupo del que sean administradores al establecer el valor del campo Grupo:
Novedades:
El formato del archivo .csv cargado que se utiliza para crear/actualizar varios usuarios ha cambiado para incluir usuarios con varios grupos y autoridad específica del grupo. Con este fin, se han eliminado tres columnas en UMG:
Se ha añadido una columna: Grupos
Los administradores de nivel de grupo no tienen autoridad para manipular a los usuarios con la columna Grupos.
Cuando un administrador de nivel de grupo crea nuevos usuarios mediante la carga masiva:
El contenido que se muestra a continuación se proporciona para mayor información, ya que la plantilla de carga incluye la columna Grupos.
La columna Grupos contiene una o varias definiciones de grupo. Cada definición de grupo contiene el nombre de un grupo, seguido de uno o varios valores de estado contenidos en llaves cuadradas. P. ej.: Nombre del grupo[Status]
En el ejemplo anterior:
Novedades:
La acción para desactivar un ID de usuario se ha limitado para que los administradores de nivel de grupo se aseguren de no deshabilitar a los usuarios en grupos en los que no tienen autoridad.
Los administradores de grupo solo pueden desactivar un usuario que tenga un abono dentro de los grupos del administrador o del grupo predeterminado.
Solo los administradores de nivel de cuenta tienen acceso a lo siguiente:
Novedades:
Al crear un usuario individual, se ha cambiado el nombre del campo Grupo de usuarios a Grupo principal.
Novedades:
Como se ha indicado en la sección de administración de nivel de grupo, el formato del archivo .csv cargado que se utiliza para crear/actualizar varios usuarios ha cambiado para incluir usuarios con varios grupos y autoridad específica del grupo. Con este fin, se han eliminado tres columnas en UMG:
Se ha añadido una columna: Grupos
La columna Grupos contiene una o varias definiciones de grupo. Cada definición de grupo contiene el nombre de un grupo, seguido de uno o varios valores de estado contenidos en llaves cuadradas. P. ej.: Nombre del grupo[Status]
En el ejemplo anterior:
Novedades:
La autoridad concedida a los administradores de nivel de grupo (por administradores de nivel de cuenta) ha añadido granularidad en UMG.
La capacidad anterior de "añadir nuevos usuarios a grupos" se ha dividido en dos opciones:
Las herramientas de administración de nivel de privacidad no se modifican actualmente mediante la configuración de UMG.
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:
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.
Se activa un código de respuesta de error común "INVALID_GROUP_ID" si:
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.
La adición de un usuario a varios grupos se realiza de dos maneras:
Editar un usuario individual: esto se hace mediante:
Haga clic una vez en el usuario para que se muestre la opción Editar usuario; a continuación, haga clic en Editar usuario.
Se abre la superposición para la administración de grupos y el administrador puede añadir libremente al usuario a cualquier grupo en el que tenga autoridad de administrador con solo clic en el icono de signo más.
Una vez que el abono de grupo se agrega al usuario, el administrador puede habilitar/deshabilitar la autoridad del usuario dentro del grupo marcando/anulando la marcación de las casillas de los encabezados de columna Administrador de grupo y Puede enviar.
Con la función Crear/actualizar usuarios en masa, los administradores de nivel de cuenta pueden actualizar rápidamente todos los ID de usuario de su cuenta.
La creación y edición masiva de usuarios es una opción disponible para los administradores de nivel de grupo para funciones como la edición del nombre, la empresa, el cargo y la información de "Me gusta". El abono de grupo no es un valor que los administradores de nivel de grupo puedan manipular mediante la función csv cargada.
Puede hacer clic en el vínculo descargar archivo CSV de muestra para descargar un archivo CSV de ejemplo con las distintas propiedades incluidas.
El formato del archivo .csv cargado que se utiliza para crear/actualizar varios usuarios ha cambiado para incluir usuarios con varios grupos y autoridad específica del grupo. Con este fin, se han eliminado tres columnas en UMG:
La nueva columna Grupos
La columna Grupos contiene una o varias definiciones de grupo. Cada definición de grupo contiene el nombre de un grupo, seguido de uno o varios valores de estado contenidos en llaves cuadradas. P. ej.: Nombre del grupo[Status]
En el ejemplo anterior:
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.
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.
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.
La creación y administración de flujos de trabajo personalizados no se ha visto afectada por las reglas de UMG hasta ahora:
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.
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.
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.
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:
El cambio de la asociación de grupo no afecta a la afiliación de grupo para los acuerdos que ya se hayan creado.
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.
El grupo asociado no se puede editar una vez que el formulario web se haya creado.
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.
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 para compartir Usuarios).
El uso compartido avanzado de cuentas permite compartir entre usuarios, entre grupos y entre usuarios y grupos:
El uso compartido de usuario a usuario varía según las reglas de UMG:
Cuando un usuario A se comparte en el grupo X:
Cuando el grupo A se comparte con el usuario X:
Cuando el grupo A se está compartiendo con e grupo B.
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.
Todas las cuentas de nivel empresarial pueden habilitar UMG, incluso cuando se hayan configurado una (o varias) integraciones.
Los paquetes de integración actuales de Acrobat Sign no tienen en cuenta a UMG de ningún modo. Como resultado, todos los usuarios que envíen acuerdos a través de una integración se perciben como si estuvieran únicamente en su grupo principal y los parámetros de envío se alinearán con la configuración del grupo principal en consecuencia.
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.
Inicia sesión en tu cuenta