Adobe Acrobat Sign tiene previsto lanzar al menos tres versiones al año, clasificadas como versiones principales o secundarias. Pueden introducirse actualizaciones secundarias adicionales según sea necesario para resolver problemas del sistema o de clientes.

Las versiones principales traen actualizaciones significativas, nuevas funciones y varias mejoras.
Las versiones secundarias se centran en mejoras y ajustes en la experiencia del usuario más pequeños. Estos se producen entre actualizaciones principales, normalmente una o dos veces por ciclo.

Para evitar interrupciones, las nuevas funciones están deshabilitadas de forma predeterminada y deben habilitarse manualmente por parte de un administrador de cuenta o de grupo.

Para los clientes de Enfermedades y ciencias de la vida que necesiten validación de cumplimiento, Acrobat Sign se asocia con un proveedor de terceros para proporcionar un paquete de validación para cada versión principal que contenga funciones para minimizar el factor de riesgo.

Nota:

Esta página de Notas de la versión preliminar se actualiza con regularidad a medida que se dispone de nueva información, por lo que su contenido es muy dinámico.

Si bien la página está localizada, el proceso lleva tiempo, lo que puede dar como resultado que las versiones localizadas varíen ligeramente de la versión autorizada en inglés de los EE. UU.

Para obtener información más precisa y actualizada, recomendamos consultar solo la página de inglés de los EE. UU..

La programación de versiones preliminares y las notas se enumeran a continuación.

Adobe Acrobat Sign sigue una programación estructurada para publicar notas de la versión y actualizaciones de la documentación:

8 semanas antes de la versión de producción

La página de la versión preliminar publica un resumen de las funciones y actualizaciones esperadas, normalmente cuatro semanas antes del lanzamiento de la zona protegida.
Los cambios de funcionalidad después de este punto se indican en la sección Errata.
Los Problemas resueltos no se incluyen en esta fase.

4 semanas antes de la versión de producción (lanzamiento de la zona protegida)

La página de versión preliminar se actualiza con documentación detallada sobre las funciones nuevas y actualizadas.
Se añadirán los vínculos a la documentación de asistencia previa a la versión (solo disponible en inglés de EE. UU.), según sea necesario.
Se publica la sección inicial Problemas resueltos, con actualizaciones en curso en las cuatro semanas siguientes.

Día de lanzamiento

Las notas de la versión se actualizan con detalles finales de la funcionalidad y vínculos a la documentación de asistencia de producción.
La página de versión preliminar se actualiza para resaltar el siguiente ciclo de lanzamiento.
La documentación se publica después de la verificación del lanzamiento en el sistema en directo, normalmente después de las 7 p. m PT, aunque las actualizaciones complejas pueden tardar más en completarse.
La lista final de Problemas resueltos se añade a las notas de la versión en inglés de EE. UU., con versiones traducidas que se actualizan más adelante.

Versión en la nube gubernamental

El entorno de Nube gubernamental se actualiza normalmente entre dos días y varias semanas después de la versión de producción, ya que algunas funciones pueden requerir una evaluación adicional antes de la implementación.

Nota:

La documentación de zona protegida está diseñada para el entorno de producción. Se han encontrado vínculos en las direcciones URL de producción de segmentación de contenido de la versión preliminar, lo que significa que esos vínculos pueden llevar a documentación existente anterior o a resultados 404 si la página de destino es nueva y aún no se ha publicado (por ejemplo, cuando el vínculo apunta hacia una nueva función en la misma versión).

Cuando se publique la versión, se publicarán las nuevas páginas, y los vínculos se resolverán correctamente en sus direcciones URL de producción.

Disponibilidad de zona protegida

Los clientes que tengan acceso al entorno de la Zona protegida de Acrobat Sign pueden acceder normalmente a la nueva funcionalidad de la versión cuatro semanas antes del lanzamiento.

El entorno de zona protegida debe superar todos los procedimientos de garantía de calidad de la producción con el mismo nivel de calidad que el entorno de producción normal.
Adobe se esfuerza por tener una disponibilidad del 99,9 % en el entorno de zona protegida, pero los clientes deben tener en cuenta que el SLA unificado de Adobe no cubre formalmente la zona protegida.
El entorno de zona protegida utiliza la misma página de estado y los mismos procedimientos de interrupción que el entorno de producción habitual.

Versiones

Alerta:

Este artículo contiene información de la versión preliminar. Las fechas de lanzamiento, las funciones y otra información están sujetas a cambios sin previo aviso.

17 de marzo de 2026 (versión menor) v17.0.1

Lanzamiento de Adobe Acrobat Sign v17.0.1

Implementación de Sandbox: 17 de febrero de 2026
\n

Implementación de producción: 17 de marzo de 2026

Implementación de GovCloud: 19 de marzo de 2026

Funcionalidad mejorada

Crear una copia – Puntos de acceso ampliados, reutilización más rápida de acuerdos.
Crear una copia ya está disponible directamente desde los filtros En curso y Esperando por usted en la Página de administración, así como desde la página de confirmación posterior al envío. Estos puntos de entrada adicionales facilitan la reutilización de acuerdos en más puntos del ciclo de vida de envío, reduciendo la necesidad de reiniciar desde cero.
Esta función estará disponible en el entorno Sandbox el 20 de febrero de 2026.

Nota: Con esta versión, los controles administrativos para desactivar esta función se eliminarán del menú de administración, estableciendo crear una copia como una capacidad estándar disponible para todos los usuarios elegibles.
Entornos disponibles: Sandbox, Commercial, Government | Niveles de servicio disponibles: acrobat sign Solutions | Ámbito de configuración: Cuenta y Grupo; Habilitado por defecto.

Revise la documentación actualizada de acciones de Usuario >

Actualizaciones de Webhook o de la API de REST

Las siguientes actualizaciones se presentan en las notas de la versión preliminar con fines de divulgación. Puede encontrar documentación completa de las actualizaciones de las API y Webhook en la Documentación para desarrolladores de Acrobat Sign cuando la versión actualizada se envíe a los servidores de producción.

Visualización de correo electrónico personalizado OEM 2.0 – Identidad más clara del remitente y destinatario en experiencias integradas, y entrega correcta de correo electrónico.
\n Para partner OEM 2.0 que utilizan flujos de trabajo integrados, acrobat sign ahora muestra el correo electrónico personalizado de un Usuario en lugar del correo electrónico registrado del partner en las superficies clave de la interfaz de uso y notificaciones. Los acuerdos, colas como "Esperando por usted" y correos electrónicos de "Revisar y firmar" reflejan consistentemente la identidad personalizada mientras preservan internamente el correo electrónico registrado para autenticación y derechos. Esto mejora la claridad para remitentes y firmantes y evita que los correos electrónicos se envíen a direcciones registradas no entregables.

Entornos disponibles: Sandbox, Commercial | Niveles de servicio disponibles: acrobat sign Solutions | Ámbito de configuración: API - Solo partner OEM 2.0

Notificación webhook para fallos de entrega SMS – Visibilidad en tiempo real de envíos SMS fallidos, remediación automatizada y paridad con rebotes de correo electrónico.
\n Acrobat Sign ahora emite un nuevo evento webhook, AGREEMENT_PHONE_BOUNCED, cuando un acuerdo enviado vía SMS no puede entregarse debido a problemas como números de teléfono no válidos, rechazo del operador o líneas bloqueadas. Esto permite a los clientes detectar fallos de entrega de SMS en tiempo real y activar automáticamente acciones de seguimiento como corregir números de teléfono, reintentar la entrega o abrir casos de soporte, eliminando puntos ciegos y reduciendo retrasos en flujos de trabajo de firma móviles.

Entornos disponibles: Sandbox, Commercial, Government | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: API

Cargas útiles de webhook – Se añadió el campo condicional extendedStatus del participante para actualizaciones dinámicas de participación, mejorando la Visibilidad del estado del participante.
Las notificaciones de webhook ahora incluyen un campo extendedStatus en cada objeto participante (memberInfos[]) cuando el remitente modifica un acuerdo en curso usando participación dinámica. Este campo proporciona detalles adicionales del ciclo de vida del participante mientras deja el campo de estado existente sin cambios para compatibilidad con versiones anteriores.

        {
          &quot;participantSets&quot;: [
            {
              &quot;id&quot;: &quot;&quot;,
              &quot;memberInfos&quot;: [
                {
                  &quot;company&quot;: &quot;TestCo&quot;,
                  &quot;email&quot;: &quot;signer2@someDomain.dom&quot;,
                  &quot;id&quot;: &quot;CBJCHBCAABAAJiZV9cH&quot;,
                  &quot;name&quot;: &quot;Signer Two&quot;,
                  &quot;status&quot;: &quot;ACTIVE&quot;,
                  &quot;extendedStatus&quot;: &quot;REMOVED&quot;
                }
              ],
              &quot;order&quot;: ,
              &quot;role&quot;: &quot;&quot;,
              &quot;status&quot;: &quot;&quot;
            }
          ]
        }

Valores de estado (sin cambios): ACTIVE, REPLACED.
Valores de extendedStatus: ACTIVE, REPLACED, REMOVED, COMPLETED.

Entornos disponibles: Sandbox, Commercial, Government | Niveles de servicio disponibles: Acrobat Sign Solutions | Ámbito de configuración: API

Errores de versión

No hay elementos que se hayan escapado de esta versión en este momento.

Problemas resueltos

Problema	Descripción
4543515	Resumen: Un evento de rebote de correo electrónico webhook puede generarse incorrectamente para un firmante válido después de que el firmante firme exitosamente y el acuerdo avance al siguiente paso. Esto puede ocurrir cuando un delegado en el mismo grupo de firma tiene un correo electrónico no válido y el remitente reemplaza al delegador original. En estos casos, el sistema puede atribuir incorrectamente el evento de rebote "firmado en nombre de..." al firmante válido en lugar del participante cuyo correo electrónico realmente rebota.
4543515	Corrección: La lógica de atribución del evento se corrigió para que los eventos de rebote de correo electrónico se asocien solo con el participante cuyo correo electrónico realmente rebota. Ya no se genera un evento de rebote para un firmante válido que ya completó la firma, y las notificaciones webhook ahora reflejan el participante y correo electrónico correctos.
4544548	Resumen: Las Claves de Integración creadas a través de la interfaz de uso web pueden expirar después de 10 años, aunque la Página de creación indique que la clave proporciona "acceso permanente." Cuando una clave alcanza su acumulado de 10 años, las llamadas API comienzan a devolver un error de token expirado, lo que puede interrumpir las integraciones existentes inesperadamente.
4544548	Corrección: La mensajería de la interfaz de uso se actualizó para eliminar la redacción de "acceso permanente" y mostrar claramente la fecha de expiración para las Claves de Integración. El texto actualizado ahora indica que la clave mantiene el acceso hasta la fecha de expiración o hasta que se revoque manualmente, proporcionando transparencia sobre el acumulado predeterminado de 10 años.
4546301	Resumen: La entrega de eventos webhook puede retrasarse hasta múltiples horas para acuerdos con documentos muy grandes, incluso cuando la creación del acuerdo se completa y los pasos de procesamiento tempranos parecen finalizar en minutos. Durante la ventana de retraso, el servicio de entrega webhook puede recibir repetidamente respuestas DOCUMENT_NOT_AVAILABLE al intentar recuperar documentos del acuerdo, y el evento webhook puede no entregarse hasta que el servicio deje de reintentar o los documentos estén disponibles.
4546301	Corrección: El manejo de disponibilidad de documentos se corrigió para que los acuerdos grandes transicionen de manera confiable a un estado donde los documentos sean recuperables sin respuestas DOCUMENT_NOT_AVAILABLE extendidas. Como resultado, los eventos webhook se entregan sin retrasos de múltiples horas causados por reintentos de recuperación de documentos contra documentos no disponibles.
4547823	Resumen: El mensaje privado de un destinatario puede no mostrarse para algunos firmantes cuando un acuerdo se crea en el estado de creación a través de la API y luego se edita desde la experiencia administrar. En este escenario, la interfaz de uso puede mostrar el Valor del Mensaje Privado como "Ninguno" o en blanco aunque los datos del acuerdo incluyan el Valor correcto del mensaje privado. Este comportamiento aparece en escenarios de Cuenta compartida donde un Usuario cambia a la Cuenta de otro Usuario para editar el borrador, y puede afectar solo a destinatarios específicos mientras otros se muestran correctamente.
4547823	Corrección: Se añadió una verificación para recuperar el contexto de Compartir principal y devolver el mensaje privado para usuarios compartidos autorizados. Como resultado, el Valor del Mensaje Privado ahora se muestra correctamente al ver o enviar un borrador creado por API desde el flujo de creación.
4548274	Resumen: La Fecha de Modificación para plantilla de biblioteca puede no actualizarse después de que una plantilla se edite y guarde en la nueva experiencia de plantilla. Los usuarios pueden ver campos recién añadidos o actualizados en la plantilla, pero la Fecha de Modificación permanece sin cambios en la interfaz de uso administrar y en vistas administrativas, lo que hace que parezca que la plantilla no fue modificada recientemente. Esto ocurre porque la nueva experiencia actualiza los campos del formulario a través de una ruta que no actualiza también la marca de tiempo modificada de la plantilla.
4548274	Corrección: El comportamiento de actualización de fecha modificada se alineó en la nueva experiencia de plantilla y las operaciones de API relacionadas. La ruta de código que guarda los cambios de campo de plantilla ahora también actualiza la Fecha de modificación de la plantilla para que refleje la hora real del cambio más reciente.
4548564	Resumen: Las firmas y los campos de formulario pueden aparecer invisibles en el pdf firmado cuando se colocan sobre anotaciones de Sello preexistentes en el documento fuente. En las plantillas afectadas, las anotaciones de Sello se superponen u ocultan los campos interactivo durante el procesamiento, causando que las firmas completadas y otros campos queden oculta en el documento firmado final.
4548564	Corrección: El manejo de anotaciones de Sello se actualizó para procesar y aplanar de forma segura las anotaciones de Sello preexistentes para que ya no oculten los campos de formulario o las firmas. Los campos colocados sobre áreas selladas ahora permanecen visibles durante la firma y en el pdf completamente ejecutado.
4549103	Resumen: Un evento de rebote de correo electrónico puede registrarse nuevamente para un destinatario previamente incorrecto después de que el remitente reemplace a ese destinatario con un correo electrónico válido. En algunos casos, la pista de auditoría puede mostrar un segundo evento de rebote para el correo electrónico anterior, y el estado del acuerdo puede reflejar "correo electrónico rebotado" aunque el nuevo destinatario reciba, vea o firme exitosamente el acuerdo. Este comportamiento puede hacer que parezca que el acuerdo aún está dirigido tanto al correo electrónico anterior como al nuevo.
4549103	Corrección: El flujo de trabajo de reemplazar firmante se actualizó para evitar enviar correos electrónicos de notificación adicionales a un destinatario reemplazado cuyo correo electrónico ya ha rebotado. El sistema ahora verifica el Historial de rebotes previo antes de enviar notificaciones relacionadas con el reemplazo, asegurando que no se generen nuevos eventos de rebote para el correo electrónico anterior después del reemplazo.
4549306	Resumen: Los Usuario cuyas direcciones de correo electrónico contienen ciertos caracteres especiales (por ejemplo, un apóstrofe) pueden no poder Iniciar sesión desde las páginas genéricas de inicio de sesión público adobesign.com o echosign.com. Después de introducir el correo electrónico y hacer clic en el campo de contraseña, la Página puede recargar y limpiar el campo de correo electrónico en lugar de redirigir al Usuario al fragmento correcto o Página de inicio de sesión SSO. Esto impide que los Usuario afectados completen la autenticación y bloquea las integraciones que dependen del punto final de inicio de sesión público.
4549306	Corrección: La lógica de resolución de fragmento de inicio de sesión se corrigió para manejar y decodificar adecuadamente las direcciones de correo electrónico que contienen caracteres especiales antes de construir la URL de redirigir entre fragmentos. Los Usuario con formatos de correo electrónico afectados ahora son correctamente redirigidos a su fragmento designado y Página de inicio de sesión SSO sin que el campo de correo electrónico se limpie.
4549331	Resumen: Las firmas y otros campos de formulario pueden aparecer faltantes o invisibles en el pdf firmado cuando ciertas características de procesamiento de documento están habilitadas y el pdf fuente contiene coordenadas de cuadro de Página no válido (por ejemplo, valores incorrectos de CropBox o MediaBox). En este escenario, los campos que dependen de coordenadas de Página pueden procesamiento fuera del área de Página visible, haciendo que las firmas completadas parezcan faltantes aunque la firma se complete exitosamente.
4549331	Corrección: El manejo de cuadro de Página pdf se corrigió para normalizar de forma segura los valores no válido de CropBox y MediaBox durante el procesamiento del documento. Como resultado, la ubicación de firma y campo de formulario ahora se alinea al área de Página visible, y los pdf firmados muestran las firmas como se esperaba.
4550367	Resumen: Crear un formulario web puede fallar con un "error de Servidor" genérico después de seleccionar vista previa y Agregar campos cuando la autenticación de firmante predeterminada del grupo del remitente está configurada en Teléfono y la Cuenta no tiene cuota de autenticación telefónica disponible, incluso si la autenticación del firmante del formulario web está configurada en un método que no sea teléfono (por ejemplo, Adobe Sign). Como resultado, todos los Usuario en la Cuenta afectada pueden estar bloqueados para crear formulario web en todos los documentos.
4550367	Corrección: La creación de formulario web ahora evalúa la cuota solo para el método de autenticación realmente configurado para el firmante del formulario web, y ya no aplica verificaciones de cuota de autenticación telefónica basadas únicamente en la configuración de autenticación predeterminada del grupo. Esto previene errores falsos de agotamiento de cuota y permite que los formulario web se creen normalmente.
4551011	Resumen: Cuando un remitente carga ciertos pdf escaneados, añade campos de firma y envía el acuerdo, el pdf firmado puede no mostrar firmas visibles después de completar la firma. Este comportamiento puede ocurrir cuando el pdf cargado contiene metadatos de límites de Página no válidos (las coordenadas MediaBox y CropBox aparecen invertidas), lo que puede hacer que las capas de apariencia de firma y otros campos se procesen fuera del área visible de la Página.
4551011	Solución: El manejo de límites de Página del pdf se actualizó para procesar correctamente los pdf con valores de coordenadas MediaBox y CropBox no válidos o invertidos, de modo que el contenido de apariencia de firma y campos de formulario se procese dentro del área visible de la Página y permanezca visible en el pdf firmado final.
4551427	Resumen: Algunos destinatarios que ya tienen cuentas principales correctamente aprovisionadas reciben acuerdos como destinatarios "pseudo Usuario" en su lugar, por lo que el acuerdo no aparece en su vista normal de administrar. Esto sucede cuando las direcciones de correo electrónico del destinatario incluyen espacios al principio o al final, lo que impide que el sistema haga coincidir el correo electrónico con el Usuario existente y causa que se cree un registro de pseudo-Usuario.
4551427	Solución: El análisis de correo electrónico y la búsqueda de Usuario se actualizaron para normalizar las direcciones de correo electrónico del destinatario (eliminar espacios en blanco al principio y al final) antes de hacerlas coincidir con usuarios existentes. Como resultado, los acuerdos dirigidos a usuarios existentes se resuelven a la Cuenta registrada en lugar de crear un destinatario pseudo-Usuario, incluso si el correo electrónico se ingresó con espacios (en cargas útiles de API y listas de destinatarios de flujo de trabajo).
4553198	Resumen: Cuando un acuerdo incluye al menos un destinatario configurado para entrega SMS y al menos un destinatario configurado para entrega solo por correo electrónico, cancelar el acuerdo a través de la API no envía una notificación de cancelación por SMS al destinatario SMS. El acuerdo se cancela exitosamente y se entregan las notificaciones por correo electrónico, pero los destinatarios SMS no reciben un mensaje de cancelación.
4553198	Solución: El flujo de trabajo de cancelación se corrigió para asegurar que las notificaciones de cancelación por SMS se envíen a todos los destinatarios configurados para entrega SMS cuando se cancela un acuerdo, independientemente de los métodos de entrega de otros destinatarios.
4554463	Resumen: Cuando los acuerdos incluyen botones de opción clonados que comparten el mismo nombre de campo en documentos combinados, solo una instancia de la opción seleccionada permanece seleccionada en el pdf firmado final. Aunque los campos aparecen visualmente como casillas de verificación, se implementan como botones de opción. Después de firmar, el Valor seleccionado no se propaga consistentemente a todas las instancias clonadas, causando asignación incorrecta o incompleta de la selección esperada.
4554463	Solución: La lógica de manejo de campos de formulario se corrigió para que los botones de opción clonados almacenen y propaguen el Valor de exportación seleccionado en lugar de un Valor de Índice interno. Esto asegura que todas las instancias clonadas del mismo campo de botón de opción reflejen la selección correcta en el pdf firmado.
4554593	Resumen: Algunas integraciones de partner que usan los endpoints OAuth heredados para actualizar tokens de acceso comenzaron a fallar con errores HTTP 401. El servicio rechazó las solicitudes de actualización de token con un error indicando que la aplicación no está permitida para usar los endpoints OAuth heredados y debe usar los endpoints OAuth v2 en su lugar. Esto bloqueó a los clientes de autenticar acrobat sign a través de aplicaciones partner, incluso para integraciones que funcionaban previamente.
4554593	Solución: El servicio de autenticación se corrigió para que las aplicaciones partner que están configuradas para usar el flujo OAuth heredado puedan actualizar tokens exitosamente de nuevo, en lugar de ser forzadas incorrectamente a los endpoints OAuth v2.
4554614	Resumen: Cuando un firmante usa la experiencia de firma electrónica moderna en un acuerdo que requiere autenticación del firmante y está configurado para requerir aceptación de Condiciones de uso antes de firmar, hacer clic en Hacer clic para firmar activa un redirigir de 5 segundos a la experiencia de firma clásica. El mensaje de redirigir advierte que las firmas y rúbricas ingresadas en la firma moderna se borrarán, forzando al firmante a reingresarlas y efectivamente firmar dos veces.
4554614	Solución: El flujo de actualización de token de firma se corrigió para que cuando el firmante acepta las Condiciones de uso antes de firmar, el token de firma reemitido retenga los detalles de autenticación del firmante. Esto previene que el paso final de firma falle la autenticación y elimina el respaldo forzado de la firma moderna a la experiencia clásica.
4555656	Resumen: Bajo condiciones específicas de tiempo, una transición de estado de acuerdo puede parecer exitosa pero no cambia realmente el estado del acuerdo. Cuando se recibe una notificación webhook antes de que se complete el procesamiento del backend, las llamadas API subsecuentes pueden usar datos de estado de acuerdo obsoletos. En esta ventana, ciertos métodos de transición de estado devuelven HTTP 200 OK aunque el acuerdo no esté en un estado válido para la transición solicitada.Como resultado, los flujos de trabajo de automatización pueden asumir que la transición fue exitosa mientras el acuerdo permanece en el estado original.
4555656	Solución: La lógica de transición de estado del acuerdo se actualizó para aplicar una validación estricta antes de aplicar una transición.Si el acuerdo no está en un estado válido, la API ahora devuelve una respuesta de error clara en lugar de devolver silenciosamente el éxito.Esto garantiza que las transiciones no válidas se rechacen explícitamente, permite que los sistemas de llamada reintenten apropiadamente y evita que los acuerdos permanezcan en un estado no deseado sin Visibilidad.