Clave del problema
Última actualización el
2 abr. 2026
Notas de la versión de Adobe Sign: 2021
Adobe Sign: marzo de 2021
Funcionalidad mejorada
Formulario web con varios firmantes
Las cuentas que usan formularios web ahora tienen la capacidad de permitir varios destinatarios externos en el proceso de firma.
El firmante inicial define los destinatarios adicionales:
Usa plantillas de biblioteca para crear formulario web
Los autores ahora pueden usar plantillas de biblioteca existentes para crear nuevos formularios web.El archivo se importa con todos los campos intactos:
"Modo líquido" en Adobe Sign para visualización móvil
Liquid Mode es una función opcional que permite generar una vista adaptable para mejorar la visualización de los documentos en función del tipo de dispositivo del firmante.
El documento firmado se almacena en la versión "PDF" estándar mientras que los destinatarios pueden ver el modo líquido en teléfonos móviles y pueden alternar para ver el documento original.
Ahora puedes cargar tu documento HTML y generar una vista de Liquid Mode para teléfonos móviles.
Encontrarás más detalles sobre la opción modo líquido aquí >
Bloquear el Valor de nombre para Usuarios conocidos al firmar mediante métodos de firma de imagen o dibujada
Hay situaciones en las que no es deseable cambiar el nombre del destinatario durante la ceremonia de firma. Adobe Sign ha flexibilizado la preferencia por el nombre del firmante. En entornos de mayor cumplimiento normativo, esta flexibilidad no es aceptable, por lo que existe un nuevo control para bloquear los nombres de los destinatarios en el acuerdo.
Los administradores ahora tienen la capacidad de evitar que los destinatarios con Valores de nombre conocidos cambien esos valores cuando aplican una firma dibujada o de imagen.
Situaciones en las que se conoce el valor de nombre:
- Al enviar a un destinatario con un Adobe Sign ID
- Al enviar el nombre a través de la API
- Cuando los campos de información del firmante se completan durante el llenado del formulario
- Cuando el nombre se bloquea durante la finalización de una autenticación KBA o de ID gubernamental
Mejoras en la autenticación basada en conocimiento
Se han agregado controles al método KBA de autenticación de identidad que puede requerir que el remitente proporcione un nombre para el destinatario y ese Valor de nombre se bloquea en su lugar durante el proceso de firma.
Opciones para seguridad de correo electrónico mejorada
Hay dos nuevas opciones disponibles para mejorar la seguridad del correo electrónico. Ambos ajustes están activados de manera predeterminada:
- Incluir un enlace en los mensajes de correo electrónco para ver el acuerdo firmado
- Incluir una imagen de la primera página del acuerdo en los mensajes de correo electrónicos
- Habilitado de manera predeterminada
- Cuando está habilitada, una imagen de la primera Página del acuerdo es visible en algunas distribuciones de correo electrónico
Actualizaciones de la API REST v6
CABECERAS ESTÁNDAR EN CADA SOLICITUD DE API REST V6
Ahora, de manera predeterminada, las solicitudes de API de REST v6 tienen los siguientes encabezados estándar:
/AGREEMENTS
Todos los puntos finales /agreements que tienen una agreement id ruta ahora devuelven un código de error 404 AGREEMENT_DESTROYED si el acuerdo ha sido eliminado a través de las herramientas GDPR.
PLANTILLAS DE BIBLIOTECA
PUT /libraryDocuments/{libraryDocumentId} - Expandido para incluir el nuevo campo ownerId
Nota
Solo se ve afectada la API de REST v6.
Cualquier llamada de API REST v6 que no incluya estos encabezados documentará explícitamente dicha ausencia.
- GET /libraryDocuments - Expandido para incluir el nuevo campo ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Expandido para incluir los nuevos campos: ownerId, ownerEmail y ownerName
Nuevos campos en el objeto LibraryDocumentInfo:
Campos con comportamiento actualizado:
FORMULARIOS WEB (/WIDGETS)
- POST /widgets - Usar un libraryDocumentId para crear un formulario web ahora es compatible con un id válido
Código de estado agregado:
- PUT /widgets - Usar un libraryDocumentId para crear un formulario web ahora es compatible con un id válido
Código de estado agregado:
- PUT /widgets/{widgetId} - Expandido para incluir el nuevo campo ownerId
Código de estado agregado:
Cambios de la experiencia
- GET /widgets/{widgetId} - Expandido para incluir los nuevos campos: ownerId, ownerEmail, ownerName, y creatorName
Nuevos campos en el objeto WidgetInfo:
Campos con comportamiento actualizado:
/MEGA SIGN
NOVEDAD:
- GET /megaSigns/{megaSignId}/formFields - Recupera los detalles del campo de formulario de un acuerdo principal de Mega Sign
Parámetros:
Objeto de respuesta:
- PUT /megaSigns/{megaSignId}/formFields - Actualiza los campos de formulario de un acuerdo Mega Sign
Parámetros:
Objeto de respuesta:
ACTUALIZADO:
- POST /megaSigns - Se ha añadido AUTHORING como Valor de estado para admitir la creación de una plantilla Mega Sign
Parámetro cambiado:
- PUT /megaSigns/{megaSignId}/state - Se ha añadido AUTHORING como valor de estado para admitir la creación de una plantilla Mega Sign.Como resultado, megaSignCancellationInfo ya no es un campo obligatorio
Se han habilitado las páginas modernas Inicio y Administrar para todas las cuentas restantes
Todas las cuentas han tenido su configuración de control actualizada para habilitar las páginas modernas de Inicio y Administrar para sus usuarios.
Los controles en el menú de administrador permanecen disponibles para cuentas que deben volver a la experiencia clásica:
Nivel de servicio de Adobe Sign e ID de cuenta expuestos en el menú de administrador
Los administradores ahora pueden encontrar su ID de Cuenta en la Página de Configuración Global:
El ID de grupo se puede encontrar en la página Configuración de grupo:
Configuración HIPAA explícita
Hay una nueva página disponible en la que se muestra claramente cuándo la cuenta está habilitada para administrar acuerdos sujetos a los requisitos de HIPAA.
- Este control solo se muestra en el nivel de cuenta. Los administradores de nivel de grupo no tienen acceso.
- Este control es de solo visualización, para indicar claramente cuándo la cuenta está configurada
- Póngase en contacto con el administrador de éxito o con el servicio de asistencia para habilitar la configuración de HIPAA.
Más información sobre la configuración HIPAA se puede encontrar aquí >
El botón "Call to action" ha cambiado para clientes que usan la aplicación de escritorio de Outlook en sistemas Windows
Los destinatarios que utilicen un cliente de correo electrónico de la aplicación de escritorio de Outlook verán un cambio en el botón "Llamada a la acción" en los mensajes de correo electrónico de Adobe Sign.
La nueva experiencia elimina el botón HTML azul y, en su lugar, proporciona un enlace de texto activo:
Nota
Este cambio solo afecta a aplicaciones de escritorio de Outlook en sistemas Windows.En el caso de otros clientes de correo electrónico y sistemas operativos, se sigue recibiendo la plantilla con el botón azul.
Delegación de contratos con firmas digitales
Se ha mejorado la capacidad de delegar un contrato con firmas digitales adjuntas para permitir la delegación desde la notificación de correo electrónico original al destinatario, a través de delegación automática cuando esté configurada por un usuario, y a través de la acción Reemplazar firmante actual en la página Administrar.
Interfaz actualizada para la integración de pagos
La interfaz de Pagos se ha actualizado para tener los controles de autenticación mejor expuestos, creando un proceso de configuración más fácil.
El valor máximo para la gobernanza de datos se ha incrementado a 5475 días (15 años)
Los clientes que usan reglas de gestión de datos para eliminar automáticamente contratos del sistema de Adobe Sign ahora pueden establecer esa fecha de eliminación hasta un máximo de 15 años (anteriormente diez).
Se ha actualizado la etiqueta de texto a nivel de campo para validar el Número de Seguridad Social de EE. UU.:
Se ha actualizado la etiqueta de texto a nivel de campo para validar el Número de Seguridad Social de EE. UU. para aclarar que el SSN está basado en EE. UU.:
Recordatorio: se ha eliminado la autenticación social
Como se anunció en noviembre, se ha eliminado el método de autenticación que usa identidad social de la lista de métodos de autenticación en el menú de administración.
Recordatorio: se ha eliminado la integración personal de Twitter
Como se anunció en diciembre, se ha eliminado la capacidad de los usuarios para realizar conexiones autenticadas personales con Twitter.
Los usuarios inactivos recibirán una notificación por correo electrónico cuando se incluyan en un acuerdo
Los usuarios que tienen un estado inactivo ahora reciben una notificación por correo electrónico que instruye al destinatario a delegar el acuerdo a otro Usuario.
Problemas resueltos
Adobe Sign: mayo de 2021
Funcionalidad mejorada
Transferencia de la propiedad de las plantillas de biblioteca y los formularios web a un usuario diferente
Cualquier administrador de la cuenta que tenga acceso a un recurso ahora puede cambiar su propietario.
El administrador puede asignar la propiedad del recurso a cualquier usuario bajo su autoridad.
- Los administradores de cuenta tienen acceso a todos los recursos compartidos y a todos los usuarios. Por lo tanto, los administradores del nivel de cuenta pueden reasignar la propiedad de cualquier plantilla de biblioteca o formulario web a cualquier otro usuario de su cuenta
- Si el recurso está configurado para que solo esté disponible para un usuario (el propietario), no se comparte y, por lo tanto, no se puede reasignar a un nuevo propietario
- Los administradores de grupo solo pueden acceder a plantillas de biblioteca y formularios web dentro de los grupos en los que tienen autoridad de administrador
- Los administradores de grupo solo pueden reasignar un recurso a un usuario cuyo grupo principal esté bajo su autoridad administrativa
PUNTOS FINALES DE API ACTUALIZADOS QUE ADMITEN TRANSFERENCIA DE RECURSOS
Los puntos de conexión que se describen a continuación solo están disponibles en la API REST v6.
Extendido para admitir la actualización del propietario del documento de la biblioteca.
LibraryDocumentInfo:
Códigos de estado de error adicionales:
Extendido para admitir la actualización del propietario del widget.
WidgetInfo:
Códigos de estado de error adicionales:
Nuevos campos en el objeto LibraryDocument:
Nuevos campos en el objeto LibraryDocumentInfo:
Campos con comportamiento actualizado:
Nuevos campos en el objeto WidgetInfo:
Campos con comportamiento actualizado:
Cambios de la experiencia
El valor de retorno predeterminado de v6 REST GET /workflows{workflowId} ha cambiado
La llamada API v6 REST GET /workflows{workflowId} se ha actualizado para devolver la versión actual del WorkflowID (frente al ID de versión original, que era el valor devuelto antes de la versión de mayo)
Esta actualización alinea la experiencia predeterminada de la API con la experiencia de Webhook, proporcionando el mismo WorkflowID, lo que debería mejorar el desarrollo y la gestión de aplicaciones.
Si, por cualquier motivo, tu cuenta requiere que la API devuelva el ID original (como lo hacía antes de la versión de mayo), ponte en contacto con el servicio de soporte técnico para solicitar que tu cuenta devuelva los ID de versión base para flujos de trabajo
Problemas resueltos
Adobe Sign: junio de 2021
Usuarios en varios grupos (UMG)
Los administradores de varias cuentas de grupo ahora pueden conceder a los usuarios de su cuenta acceso a varios grupos, lo que abre la opción a utilizar grupos como una forma de plantilla de flujo de trabajo y a aplicar controles específicos de envío y firma para las plantillas de biblioteca disponibles para el grupo.
Las cuentas empresariales y business existentes que deseen actualizar pueden revisar el proceso de actualización aquí >
Puede encontrar un resumen de las diferencias más destacables aquí >
Introducción de Liquid Mode en Sign
Active la vista Liquid Mode para teléfonos móviles para HTML enviado mediante la API Send Page o sendAgreement. La opción para habilitar el Liquid Mode en Sign para HTML ahora está disponible en la lista del menú Administración tanto en el nivel de cuenta como en el de grupo.
Puede encontrar todos los detalles sobre los documentos en Liquid Mode aquí >
Nota
Actualmente, Liquid Mode solo está disponible en los entornos NA1, NA2 y NA4.
Actualizaciones de formularios web perfectas
Los formularios web con estado Borrador se pueden editar para modificar:
- el Nombre del formulario web
- la dirección de correo electrónico del contrafirmante
- el correo electrónico de las partes en copia
- los archivos adjuntos que se van a editar
- los campos del formulario web (disponibles anteriormente)
La actualización de un formulario web activo permite editar los elementos de formulario sin cambiar la dirección URL original, lo que permite disfrutar de un proceso sin fricciones si necesita actualizar el contenido de un formulario web que ya se ha incrustado o enviado a su audiencia. Los elementos que se pueden editar son:
- los archivos (documentos) y los campos aplicados para los destinatarios
- contrafirmantes (desde la página Administrar)
- partes en CC (desde la página Administrar)
Nota
Para utilizar la funcionalidad de formulario web, debe habilitar la opción Permitir participantes adicionales en el menú Configuración global:
Sello de participación: Control de la visualización de títulos y compañías
Se han añadido controles para permitir o suprimir el Título y Compañía del destinatario (derivados del perfil de usuario) en el campo del sello de participante.
Puede encontrar más información en la página Tipos de campos >
Opciones de búsqueda mejoradas: Coincidencias de prefijo y frase
Se han implementado opciones de búsqueda avanzadas para ofrecer patrones de búsqueda más específicos que ayudarán a reducir la lista de acuerdos devuelta.
Puede encontrar más información sobre cómo funciona la búsqueda en Adobe Sign aquí >
OAuth 2.0 es el nuevo valor predeterminado
Se ha añadido una nueva versión (mejorada) del extremo de OAuth para evitar errores de uso. Con esta versión:
- api_access_point / web_access_point devuelve solo en la solicitud de token de acceso (en el cuerpo)
- Adobe Sign no acepta el secreto como parámetro de consulta
- Se admite la rotación del secreto de cliente
El extremo de OAuth v1 seguirá funcionando para las conexiones existentes en los próximos meses para garantizar un acceso continuo.
La obsolescencia de OAuth v1 se anunciará en la página de Notificaciones técnicas una vez programada.
Rotación de secreto de cliente
Los secretos de cliente de la aplicación los puede rotar cualquier administrador que tenga acceso al ID de la aplicación en la IU de Adobe Sign:
Cambios de la experiencia
Los administradores de grupo solo pueden ver las aplicaciones de API que están bajo su autoridad de administración
La visibilidad de las aplicaciones adjuntas a la cuenta ahora está limitada solo para mostrar las aplicaciones que quedan dentro del ámbito administrativo del usuario. Solo los administradores de grupo verán el cambio de comportamiento:
- Los usuarios ven las aplicaciones que poseen
- Los administradores de grupo ven las aplicaciones de los grupos sobre los que tienen autoridad de administración
- Los administradores de cuentas ven todas las aplicaciones de la cuenta
El correo electrónico al remitente cuando se haya completado un acuerdo se ha actualizado
La notificación final por correo electrónico de un acuerdo enviado al remitente se ha actualizado para proporcionar una lista completa de todas las partes notificadas acerca del acuerdo completado.
Solo el remitente original obtendrá esta plantilla de correo electrónico.
Resultado de la API REST v6 actualizado para GET /agreements/{agreementId}/signingUrls
Antes de la versión de junio, al llamar a GET /agreements/{agreementId}/signingUrls, la API devolvía un 404 inmediatamente después de crear el acuerdo.
Durante un breve tiempo después de que se borrara el error 404, la respuesta devolvía una respuesta que no fuera 404, pero solo incluía las direcciones URL de firma del remitente. (Mientras que la participación del firmante aún se estaba definiendo).
Después del lanzamiento de junio de 2021, un código 404: AGREEMENT_NOT_EXPOSED se devolverá hasta que se complete toda la lista de direcciones URL de firma, momento en el que se envía un código 200.
Se recomienda a los clientes que no deseen continuar probando la llamada de API hasta que se devuelva la respuesta 200 que usen Webhooks y respondan al evento AGREEMENT_CREATED.
Problemas resueltos
Adobe Sign: Agosto de 2021
Cambio de experiencia
- Asistencia internacional de Aadhaar: los clientes de todas las instancias de Adobe Sign ahora pueden utilizar el servicio Aadhaar opcional como proveedor de firmas digitales. Anteriormente, solo estaba disponible para las cuentas de la instancia IN1. El complemento Aadhaar se puede comprar con un coste adicional por transacción de firma.
- Actualización de REST v6: POST/users: la llamada de la API REST v6 POST/users se ha actualizado para crear el usuario en el grupo predeterminado de la cuenta si no se ha definido el parámetro opcional primaryGroupId. Este cambio solo afecta a la versión 6 de la API REST.
Problemas resueltos
|
|
Descripción |
|---|---|
|
4299495 |
Se solucionó un problema en el Diseñador de flujos de trabajo que impedía que funcionara una URL definida por el cliente en las instrucciones. |
|
4308294 |
Se corrigió un problema en el archivo CSV del informe donde los campos Para y Nombre del destinatario podían quedar vacíos cuando el mismo correo electrónico del destinatario se usaba más de una vez en el acuerdo. |
|
4310569 |
Las plantillas de Adobe Sign se han filtrado de las opciones de sandbox. |
|
4311098 |
Se corrigió un problema donde los administradores de grupo no podían actualizar usuarios en un grupo mediante carga CSV. |
|
4311723 |
Se solucionó un problema donde la llamada API GET /groups/ID/users fallaría si el usuario estaba en una instancia diferente de Adobe Sign. |
|
4312103 |
Se corrigió un problema donde los usuarios SAML creados mediante carga masiva estarían en estado Creado (en lugar de Activo). |
|
4312309 |
Se corrigió un problema donde los administradores de grupo no podían reasignar la propiedad de los formularios web si otros usuarios de su grupo los habían creado. |
|
4312840 |
Se corrigió un problema con la activación de nuevos usuarios cuando se enviaba un segundo correo electrónico de activación al nuevo usuario y se utilizaba el enlace de ese segundo correo electrónico. |
|
4314751 |
Se corrigió un problema donde la opción de Rechazar el acuerdo no era visible al firmar en nombre de otro usuario. |
|
4315033 |
Se corrigió un problema por el que los administradores de cuenta no podían restablecer contraseñas cuando el modo SAML estaba establecido en Obligatorio. |
|
4315605 |
Se corrigió un problema donde las imágenes de ID gubernamental no se procesarían correctamente. |
|
4316057 |
Se corrigió un problema por el que el ID gubernamental producía un error indicando que no se podían encontrar las cuatro esquinas del documento. |
|
4316474 |
Se corrigió un problema donde Firmar en nombre de era visible en cuentas donde la opción no estaba habilitada. |
|
4316659 |
Se ha corregido un problema por el que la dirección de correo electrónico de “actingUserEmail” en una llamada de GET /agreements/id devolvía un correo electrónico generado por el sistema una vez que el acuerdo se había firmado por completo. |
|
4317095 |
Se corrigió un problema donde el nombre de un destinatario se importaría en la etiqueta Participante 1 cuando se usaba autenticación basada en conocimiento para el primer firmante. |
|
4317221 |
Se corrigió un problema donde los correos electrónicos de notificación automática para webhooks fallidos se enviarían al creador del webhook a pesar de estar configurado para no notificar al creador. |
|
4317347 |
Se corrigió un problema por el que la autenticación de OAuth en Power Automate redirigía al usuario a la página principal. |
|
4317429 |
Se solucionó un problema donde los administradores no podían actualizar la propiedad Puede enviar para usuarios al actualizar mediante carga CSV. |
|
4317548 |
Se solucionó un problema donde algunos clientes que usaban el iPad verían la página web en lugar de la página optimizada para dispositivos móviles. |
|
4317629 |
Se solucionó un problema de visualización con nombres que contienen un apóstrofe mostrando el código HTML para el apóstrofe. |
|
4318175 |
Se ha corregido un problema por el que los usuarios obtenían un error al archivar una cuenta mediante el vínculo del correo electrónico. |
|
4319012 |
Se ha corregido un problema por el que los usuarios creados mediante REST v5 y v6 POST /users no se situaban en el grupo predeterminado. |
|
4320197 |
Se corrigió un problema por el que no se podía descargar el Informe de identidad del firmante desde la página Administrar debido a que el botón estaba inactivo. |
Adobe Sign: septiembre de 2021
Funcionalidad mejorada
- Espacio aislado: los clientes de nivel Enterprise tienen la opción de adquirir acceso a un entorno de espacio aislado para probar plantillas, flujos de trabajo de clientes, aplicaciones de API y mucho más. Estos objetos se pueden mover de la producción al espacio aislado para realizar actualizaciones en un entorno seguro y, a continuación, volver a la producción una vez verificadas las actualizaciones y listas para su implementación.
- Compatibilidad con Firma digital ECDSA - Adobe Sign ahora admite firmas digitales más seguras y eficientes basadas en el formato ECDSA, que utiliza criptografía de curva elíptica según se define en el estándar ANS X9.62-2005.
Ahora se admiten las curvas NIST con funciones hash SHA-2, según se definen en los estándares FIPS, lo que ofrece a nuestros socios de servicios de confianza (TSP) de Cloud Signature Consortium la opción de proporcionar a los firmantes unas credenciales de curva elíptica más rápidas y seguras, incluidas aquellas que cumplan los requisitos recomendados para uso del Gobierno federal de los Estados Unidos y de Singapur.
- Liquid Mode actualizado: la experiencia de firma del Liquid Mode se ha ampliado más allá de los acuerdos para incluir los formularios web. Los formularios de Liquid Mode pueden mejorar significativamente la experiencia del firmante al reducir la necesidad de pellizcar y hacer zoom para ver el contenido del formulario, al tiempo que se mejora el enfoque en los campos que se deben rellenar.
Además, el modo líquido ya no está restringido a fragmentos de Norteamérica. Todas las cuentas de empresa y Empresa ahora tienen acceso independientemente de la ubicación.
- Nuevos proveedores de servicios de confianza: Cleverbase (Países Bajos), PrimeSign (Austria), Sectigo (Global), SPID (Italia) y TrustPro (Irlanda) son los nuevos proveedores de servicios de confianza del Cloud Signature Consortium que proporcionan certificados para aplicar firmas digitales seguras que cumplen los más altos estándares y requisitos de cumplimiento.
- Personalizar los campos Para y CC en las cabeceras de correo electrónico para destinatarios - Los clientes que estén preocupados por la filtración de direcciones de correo electrónico a través de las cabeceras de correo electrónico a los destinatarios pueden optar por ocultar los valores de dirección de correo electrónico en los campos Para y CC.
- Esta opción está disponible para las cuentas de nivel empresarial y de negocios y se puede configurar en los niveles de cuenta y grupo.
- Se puede acceder a los controles de la función navegando a Configuración de la cuenta > Configuración de correo electrónico > Personalizar campos Para y CC.
Cambios de la experiencia
- Aceptación de las Condiciones de uso de Adobe en las páginas de firma electrónica - Para cumplir con los requisitos legales de Adobe, Adobe Sign está actualizando el comportamiento de aceptación de las condiciones de uso (ToU) en la página de firma electrónica. Bajo la nueva experiencia, todos los destinatarios "desconocidos" deben aceptar las Condiciones de uso de Adobe Sign y la Política de privacidad (haciendo clic en el botón Continuar) antes de interactuar con el acuerdo.Esta aceptación es distinta de cualquier ToU personalizada que la cuenta del Cliente pueda haber configurado, que continuará resolviéndose según la configuración de aceptación de TOU/CD de la cuenta.
- Un destinatario "desconocido" es cualquier dirección de correo electrónico que no sea un correo electrónico de usuario registrado y activo en una cuenta de confianza.
- Los usuarios “conocidos” han aceptado las Condiciones de uso de Adobe Sign como parte del proceso de registro al verificar su cuenta de usuario, por lo que no se les pide que las acepten de nuevo.
A continuación se muestra un ejemplo del flujo de consentimiento implícito para un acuerdo con unas Condiciones de uso personalizadas configuradas por el cliente:
- Acepte las Condiciones de uso de Adobe Sign seleccionando el botón Continuar después de abrir el acuerdo.
- Rellene los campos del acuerdo según sea necesario.
- Acepte la Divulgación del Cliente y las ToU personalizadas seleccionando el botón Hacer clic para firmar.
- Bloqueo de los valores de nombre extendidos a las firmas escritas: la versión de marzo introdujo una configuración para habilitar o deshabilitar la capacidad de un destinatario de editar el valor de su nombre al firmar, siempre que el nombre se proporcionara o se conociera (mediante API o perfil de usuario). Las firmas escritas se han excluido de esta función, lo que permite a algunos firmantes cambiar el valor de su nombre durante el proceso de firma. La versión de septiembre actualiza esta función para cumplir con la configuración de bloqueo de nombres para todos los tipos de firmas, incluidas las escritas.
- Los Clientes que hayan habilitado Escribir su nombre e iniciales y deshabilitado Los firmantes pueden cambiar su nombre o iniciales verán un cambio en el comportamiento: el Valor del nombre ya no se puede editar durante el proceso de firma para las firmas escritas.
- Los clientes que deseen permitir la edición del valor del nombre durante el proceso de firma deben habilitar Los firmantes pueden cambiar su nombre o iniciales (en el menú Preferencias de firma).
- Los usuarios inactivos pueden firmar acuerdos: Adobe Sign ahora trata a los usuarios inactivos como si fueran desconocidos para el sistema (con el fin de firmar acuerdos vinculados). Cuando se solicita a un usuario inactivo que firme un acuerdo, se crea expresamente un nuevo ID de usuario de un solo uso para firmar dicho acuerdo. El ID de usuario de un solo uso es independiente del ID de usuario inactivo y de la cuenta que lo gobierna. Esto tiene varias ramificaciones:
- Los acuerdos enviados a un usuario inactivo se pueden firmar, ya que el estado Inactivo no se aplica al ID de usuario de un solo uso generado para el acuerdo.
- Los acuerdos firmados por el ID de usuario de un solo uso no son activos del ID de usuario inactivo y no residen en la cuenta del ID de usuario inactivo.
- Los usos compartidos del ID de usuario inactivo no reflejarán los acuerdos firmados por los ID de usuario de un solo uso.
- Los informes con el ID de usuario inactivo no reflejarán los acuerdos firmados por el ID de usuario de un solo uso.
- Si se vuelve a activar el ID de usuario inactivo, no verán los registros de los acuerdos firmados por los ID de usuario de un solo uso en su página Administrar.
Existen dos excepciones al comportamiento anterior:
- Es posible que los acuerdos enviados al usuario antes de que se marcaran como inactivos no se firmen (el acuerdo ya estaba vinculado al ID de usuario inactivo).
- Los usuarios configurados explícitamente para no tener permitido firmar acuerdos continuarán sin poder realizar acciones de firma.
A los usuarios inactivos se les sigue impidiendo iniciar sesión en el sistema de Adobe Sign y enviar acuerdos bajo su autoridad (por cualquier método).
- Seguridad mejorada para el acceso a formularios web mediante contraseña: los formularios web han incluido un retraso tras varios intentos fallidos de acceder a una URL protegida con contraseña.
- Asistencia internacional de Aadhaar: los clientes de todas las instancias de Adobe Sign ahora pueden utilizar el servicio Aadhaar opcional como proveedor de firmas digitales. Anteriormente, solo estaba disponible para las cuentas de la instancia IN1. El complemento Aadhaar se puede comprar con un coste adicional por transacción de firma.
- Uso compartido limitado de acuerdos - El uso compartido de acuerdos se ha limitado al compartir el acuerdo con una dirección de correo electrónico externa.
- Las cuentas con varias licencias pueden compartir cualquier acuerdo hasta diez veces.
- Las cuentas individuales pueden compartir un acuerdo hasta 5 veces.
- No está restringido el compartir un acuerdo con los usuarios internos.
- Las cuentas con varias licencias pueden compartir cualquier acuerdo hasta diez veces.
- Nombre de empresa personalizado en Autenticación telefónica se ha eliminado del servicio: el valor de nombre de empresa personalizable que se puede insertar en el método de autenticación telefónica se ha eliminado del servicio como se anunció en la Notificación técnica de junio.
- Las cuentas habilitadas para HIPAA ahora pueden acceder a los controles de las imágenes y los vínculos de los correos electrónicos de los destinatarios en la página Global/Configuración de grupos.
- El orden en que se incluyen los archivos adjuntos en el PDF final se ha actualizado para ordenar por número de página primero, y luego por posición del campo en segundo lugar (al leer de izquierda a derecha; de arriba a abajo)
- La función Reemplazar destinatario en la nueva página Administrar ahora permite al remitente incluir un mensaje opcional para el nuevo destinatario.
Consulte la función Reemplazar destinatario para obtener más información >
- Los firmantes externos que acceden a acuerdos completados ahora deben pasar un proceso de autenticación cuando se ha configurado la autenticación de múltiples factores para el acuerdo (en lugar de que se les solicite iniciar sesión en Adobe Sign).
- Los formularios web ahora indican los valores de campo de los formularios web no verificados al acceder a los datos de campo mediante la función Descargar datos de campo de formulario en la página Administrar.
Actualizaciones de API
- Opción Leer acuerdo para formularios web: hay dos nuevas llamadas a la API REST v6 disponibles para proporcionar acceso a la visualización de formularios web:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} ahora devuelve la función del participante en la respuesta.
Problemas resueltos
| 4292343 | Se ha mejorado la claridad de la firma al utilizar la opción ESCRIBIR firma en dispositivos móviles. |
| 4295123 | Se ha corregido un problema que podía impedir que las firmas digitales estuvieran visibles al abrirse en un explorador. |
| 4299289 | Se ha mejorado la experiencia Reemplazar destinatario al permitir que el remitente incluya un mensaje al nuevo destinatario. |
| 4299857 | Se ha corregido un problema que podía hacer que un acuerdo firmado no aplicara el sello de certificado. |
| 4304261 | Se ha corregido un problema que podía hacer que la opción Leer acuerdo no se rellenara en el menú Opciones |
| 4308516 | Se ha corregido un problema por el que se solicitaba continuamente a los usuarios que obtuvieran el consentimiento del administrador al utilizar OneDrive |
| 4310225 | Se ha corregido un problema con los acuerdos que contenían varias firmas que desencadenaba un error del servidor: Mensaje de error: la firma aplicada a este documento no es válida. Borre y vuelva a firmar. |
| 4310416 | Se ha actualizado la API REST de la versión 5 para crear usuarios en estado activo al crearlos con POST/users |
| 4311287 | Se ha corregido un problema por el que el botón de navegación Grupo desaparecía en las cuentas habilitadas para UMG después de que se eliminara a un usuario de un grupo. |
| 4311956 | Se ha corregido un problema por el que el tamaño de fuente designado para un campo no se reflejaba en la experiencia del firmante. |
| 4312302 | Se ha corregido un problema que eliminaba la opción Restablecer contraseña si el modo SAML estaba establecido en Obligatorio. |
| 4312735 | Se ha corregido un problema que provocaba que las notificaciones de eventos compartidos se enviaran cuando las notificaciones compartidas estaban deshabilitadas. |
| 4313025 | Se ha corregido un problema por el que una función de Rellenador de formularios no podía rellenar las funciones sin asignar cuando se habilitaba el enrutamiento híbrido. |
| 4313030 | Se ha corregido un problema por el que las cuentas habilitadas para UMG activaban un error al utilizar un flujo de trabajo personalizado si no se permitía el envío al grupo principal del remitente. |
| 4313264 | Se ha actualizado la configuración habilitada para HIPAA para permitir el acceso a la configuración de vínculo/imagen de correo electrónico en la página Configuración global. |
| 4315839 | Se ha corregido un problema con los flujos de trabajo personalizados que no permitían prellenar los campos cuando el remitente era también el segundo destinatario. |
| 4316058 | Se ha actualizado el comportamiento de los campos de informe para permitir los ceros a la izquierda en los campos de texto. |
| 4317382 | Se ha corregido un problema con los botones de opción que mostraban el código HTML para los apóstrofes en la información de herramientas |
| 4317978 | Se ha actualizado la forma en que los archivos adjuntos se ordenan en el PDF final para agrupar los archivos adjuntos en función del número de página del campo en primer lugar y la posición relativa del campo en segundo lugar (cuando se lee de izquierda a derecha y de arriba abajo). |
| 4318598 | La llamada a la API REST v6 de GET/workflows/{workflowId} ahora devuelve la función del participante en la respuesta. |
| 4318606 | La función Descargar datos de campos de formulario de la página Administrar ahora devuelve valores de campo para formularios web que aún no se han verificado. |
| 4318617 | Se ha corregido un problema por el que las cuentas habilitadas para UMG no permitían que un administrador de grupo reenviara una invitación. |
| 4318679 | Se ha corregido un problema intermitente que podía provocar que los documentos con la firma escrita no se cargaran. |
| 4318926 | Se ha corregido un problema que podía desencadenar un error (La funcionalidad de la cookie está desactivada en el explorador) al generar un acuerdo desde un dispositivo móvil. |
| 4318991 | Se ha corregido un problema que podía hacer que se ignorara la configuración máxima de error de inicio de sesión si SAML se establecía en Permitido. |
| 4319068 | Ahora, los destinatarios externos deben pasar un proceso de autenticación de dos pasos (en lugar de iniciar sesión en Adobe Sign) para obtener acceso a los acuerdos completados cuando se configura la autenticación de múltiples factores. |
| 4319422 | Se ha corregido un problema por el que se podía reemplazar a un destinatario sin confirmar la contraseña (para un acuerdo autenticado con contraseña). |
| 4319455 | Se ha corregido un problema en el uso compartido avanzado por el que la configuración podía no ser persistente después de guardar. |
| 4320123 | Se ha corregido un problema que podía desencadenar un error al intentar ver y aprobar un acuerdo en la página Administrar. |
| 4320205 | Se ha corregido un problema que podía impedir guardar el progreso al prellenar un acuerdo mediante el uso compartido avanzado. |
| 4320542 | Se ha corregido un problema relacionado con las cuentas habilitadas para UMG por el que se podían eliminar todas las afiliaciones de grupo de un usuario si se quitaba un grupo mediante la búsqueda. |
| 4321357 | Se ha corregido un problema que podía activar un error en la página de envío cuando se seleccionaba KBA para la autenticación y se habilitaba Solicitar nombre al enviar. |
| 4322445 | Se ha mejorado la creación para garantizar la coherencia del color de fondo. |
| 4322956 | Se ha corregido un problema con las plantillas de correo electrónico personalizadas por el que los destinatarios no veían la dirección de correo electrónico real del firmante. |
| 4323609 | En desarrollo: se ha corregido un problema por el que los acuerdos completados cargando un documento firmado no activaban la notificación de webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4323968 | Se ha mejorado la función de bloqueo de firma para incluir firmas escritas cuando el valor de nombre se proporciona mediante el perfil o la API. |
Adobe Sign: octubre de 2021
Funcionalidad mejorada
- Vínculos para notificar infracciones: ahora, las cuentas de empresas pequeñas y de personas individuales incluyen un vínculo para que los destinatarios accedan a un método que permite informar de actividades potencialmente abusivas relacionadas con solicitudes de acuerdos entrantes.
- Integración con Notarize: la integración de Adobe Sign con la plataforma Remote Online Notarization (RON) de Notarize, Inc. permite a los clientes añadir un servicio de notarización en línea remoto como parte de sus transacciones de Adobe Sign. Disponible para la habilitación de los clientes estadounidenses en niveles empresariales y comerciales vendidos directamente por Adobe a través del programa de ETLA. Las transacciones de Notarize se pueden comprar como complemento a un coste adicional solo para estos clientes.
- Enviar actualizaciones de página: los clientes con notario habilitado pueden seleccionar la opción Requiere notarización en el registro del destinatario, justo a la derecha del método de autenticación:
- Enviar actualizaciones de página: los clientes con notario habilitado pueden seleccionar la opción Requiere notarización en el registro del destinatario, justo a la derecha del método de autenticación:
Nota
Los clientes que utilicen la página Enviar integrada en sus aplicaciones o integraciones también tendrán acceso a la funcionalidad notarial.
Una vez configurado el acuerdo y después de que el remitente haga clic en Siguiente, se le presentarán opciones de configuración adicionales para el proceso de notarización:
- Actualizaciones de API: hay actualizaciones significativas de las API que añaden compatibilidad con la integración de Notarize:
POST /agreements
Gracias a la actualización de la API POST /agreements, ahora se puede enviar un acuerdo para la notarización.
- Debe utilizarse una nueva función, NOTARY_SIGNER, para indicar un participante en la sesión notarial.
- Se ha añadido un nuevo atributo NotaryInfo a la definición AgreementInfo para que contenga todas las opciones asociadas a la creación de un nuevo acuerdo que requiera notarización.
|
Nombre del parámetro |
Objeto de REST |
Descripción |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Conjunto de objetos ParticipantInfo que contiene datos específicos del participante (correo electrónico, por ejemplo). Todos los participantes de la matriz pertenecen al mismo conjunto. |
||||||||||||||||
|
función |
|
Función asumida por todos los participantes en el conjunto (firmante, aprobador, etc.) |
Extensión FileInfo
La definición de FileInfo debe expandirse para indicar qué documentos deben notarizarse.
|
Nombre del parámetro |
Tipo |
Predeterminado |
Obligatoria |
Descripción |
|---|---|---|---|---|
|
documento |
Document |
|
opcional |
Un documento que está asociado con el acuerdo. |
|
label |
Cadena |
|
opcional |
Valor de etiqueta exclusivo de un elemento de información de archivo. En el caso del flujo de trabajo personalizado, se asignará un archivo al elemento de archivo correspondiente en la definición del flujo de trabajo. |
|
libraryDocumentId |
Cadena |
|
opcional |
ID de un documento de biblioteca existente que se agregará al acuerdo |
|
transientDocumentId |
Cadena |
|
opcional |
ID de un documento transitorio que se agregará al acuerdo |
|
notarize |
true |
falso |
opcional |
Indica que este documento debe estar certificado por notario. |
Extensión ParticipantInfo
La definición de ParticipantInfo se ha ampliado para permitir especificar el método de autenticación notarial.
|
Nombre del parámetro |
Tipo |
Predeterminado |
Obligatoria |
Descripción |
|---|---|---|---|---|
|
correo electrónico |
Cadena |
N/A |
obligatorio |
El correo electrónico del participante. |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
opcional |
MULTI_FACTOR_AUTHENTICATION: la autenticación notarial se realiza mediante un método de autenticación de doble factor |
NotaryInfo
Se ha añadido un nuevo campo opcional notaryInfo a la definición AgreementInfo para que contenga el objeto NotaryInfo que especifica opciones adicionales asociadas con la notarización.
|
Nombre del parámetro |
Tipo |
Predeterminado |
Obligatoria |
Descripción |
|---|---|---|---|---|
|
notaryType |
Enum |
Si solo Servicio Notarize Notary a petición está activado en la cuenta, |
obligatorio |
NOTARIZE_NOTARY: el servicio Notarize proporciona al notario |
|
payment |
Enum |
BY_SENDER |
opcional |
Solo se aplica si type == NOTARIZE_NOTARY |
|
appointmentStart |
Cadena |
"" |
opcional |
Cadena con formato ISO_DATE_TIME. Consulte ISO_ZONED_DATE_TIME |
|
note |
Cadena |
ninguno |
opcional |
Notas para la sesión notarial. |
|
notaryEmail |
Cadena |
"" |
opcional |
correo electrónico del notario propio |
Ejemplo/acuerdo
PUT|GET /agreements/{aid}
La API PUT /agreements/{aid} admite la actualización de un acuerdo con opciones de notarialización. La API GET /agreements/{aid} devolverá cualquier opción establecida para la notarización del acuerdo. Consulte la sección POST /agreements para ver los atributos actualizados.
Códigos de error
Los códigos de error existentes de POST /agreements no se modifican. Hemos definido un nuevo código de error como se indica a continuación:
|
Código de error REST |
Código de estado HTTP |
Mensaje |
Escenario |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
La configuración del usuario o el token de ámbito de OAuth no permiten el envío de acuerdos para la notarización. |
Se producirá este error cuando la función se establezca en NOTARY_SIGNER y el llamador de API (es decir, el remitente potencial) no tenga habilitada la función notarial o si el proveedor de servicios notariales no está establecido. |
Impacto de la documentación
En el objeto AgreementInfo de la solicitud, el elemento estado incluirá el nuevo estado del acuerdo WAITING_FOR_NOTARIZATION.
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
Los clientes (firmantes notarios) pueden utilizar la API para obtener un token de firma que les permita completar la fase de firma electrónica del flujo.
- Se ha añadido una nueva capacidad de firma para capturar la nueva función ACCEPT_BEFORE_NOTARIZATION.
- No se deben obtener tokens de firma para completar la fase de notarización.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
Los clientes (firmantes notarios) pueden utilizar la API para completar la fase de firma electrónica del flujo. Para incorporar la nueva función, se ha introducido un nuevo valor de estado de enum: ACCEPTED_BEFORE_NOTARIZATION.
|
Atributo |
Tipo |
Descripción |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Estado |
Enum<Cadena>
|
|
||||||||||||||
El firmante notario puede seguir la secuencia de llamadas a la API siguiente para completar la fase de firma electrónica:
- GET /agreements/{agreementId}/members: para obtener el ID de participante del firmante notario y el ID de conjunto de participantes
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens: solicitar el token de firma para el firmante notario con la capacidad ACCEPT_BEFORE_NOTARIZATION
- POST /transientDocuments: para cargar el documento revisado
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status: enviar el documento revisado y completar la fase de firma electrónica.
Nuevo evento webhook
Los clientes pueden suscribirse al nuevo evento webhook, AGREEMENT_READY_FOR_NOTARIZATION, para recibir una notificación cuando el acuerdo esté listo para la notarización. El evento no es visible en la IU de webhooks y se puede suscribir a través de la llamada a la API POST /webhooks.
Impacto de la documentación
Las siguientes API no se modifican, pero su documentación se ha actualizado para incluir el nuevo estado del acuerdo WAITING_FOR_NOTARIZATION o la nueva función NOTARY_SIGNER.
GET /agreements
En el objeto UserAgreements/UserAgreement de respuesta, el elemento “status” ahora incluye el estado correspondiente “WAITING_FOR_NOTARIZATION”.
GET /agreements/{agreementId}
En el objeto AgreementInfo de respuesta, el elemento “status” ahora incluye el estado correspondiente WAITING_FOR_NOTARIZATION.
GET /agreements/{agreementId}/events
La API se actualiza para admitir nuevos eventos READY_TO_NOTARIZE y NOTARIZED.
Objeto de evento de respuesta
- El elemento participantRole ahora incluye la nueva función NOTARY_SIGNER.
- type incluye los nuevos eventos READY_TO_NOTARIZE y NOTARIZED. El elemento descripción será Documento enviado para notarización y Documento notariado, respectivamente
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
En el objeto DetailedParticipantSetInfo de respuesta, el elemento estado ahora incluye el estado correspondiente WAITING_FOR_NOTARIZATION.
PUT /agreements/{agreementId}
El objeto AgreementInfo de solicitud ahora incluye el estado WAITING_FOR_NOTARIZATION.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
El estado WAITING_FOR_NOTARIZATION es uno de los valores del elemento estado en el objeto DetailedParticipantSetInfo.
POST /agreements/{agreementId}/view
El estado WAITING_FOR_NOTARIZATION se ha añadido como una de las vistas permitidas.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Si el participante especificado en la ruta de solicitud tiene una función de firmante notario, la API devolverá la configuración de firma ACCEPT_BEFORE_NOTARIZATION, en línea con todas las demás configuraciones de firma para este acuerdo/participante.
Problemas resueltos
| Problema | Descripción |
| 4308901 | Se ha corregido un problema por el que delegar un acuerdo con la autenticación telefónica generaba un error si el número de teléfono delegado tenía el mismo código de país. |
| 4314113 | Se ha corregido un problema por el que los usuarios no podían editar las fechas de caducidad predeterminadas al enviar un nuevo acuerdo. |
| 4318558 | Se ha corregido un problema por el que reemplazar un destinatario por autenticación telefónica provocaba el error “El ID de conjunto de participantes especificado no es válido”. |
| 4319038 | Se ha corregido un problema por el que el remitente no obtenía la opción Verificación de la identidad de los destinatarios externos al enviar mediante el flujo de trabajo Enviar por lotes. |
| 4319798 | Se ha corregido un problema que podía hacer que la selección de un botón de opción desplazara el enfoque del cursor a un campo diferente. |
| 4320154 | Se ha corregido un problema que podía impedir que una plantilla de biblioteca se guardara en una nueva relación de grupo. |
| 4323013 | Se ha corregido un problema por el que al abrir un formulario web en la página de administración se generaba un error: “El documento aún no está disponible o no tendrá páginas que ver”. |
| 4323554 | Se ha corregido un problema por el que las marcas de fecha y hora del evento para actualizar los derechos de administrador podían producir dos registros con los mismos valores de tiempo. |
| 4323609 | Se ha corregido un problema por el que, al cargar un acuerdo firmado en la página de administración, no se activaba el webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4325142 | Se ha corregido un problema por el que las plantillas de correo electrónico personalizadas no reflejaban el valor de nombre correcto para un participante si cancelaban el acuerdo. |
| 4326747 | Se ha corregido un problema que podía provocar que la página Enviar por lotes no completara el proceso de carga y omitiera las acciones Cargar y Enviar. |
| 4326855 | Se ha corregido un problema que podía impedir que los destinatarios rechazaran la aprobación de un acuerdo. |
| 4327000 | Se ha corregido un problema que podía provocar errores en las credenciales de Smart-Id, con un error que indicaba que no se encontraron algoritmos. |
