Questo documento evidenzia le nuove funzioni, le modifiche apportate all’esperienza e i problemi risolti nella versione più recente dell’applicazione rivolta al cliente.

Gli aggiornamenti delle API e dei webhook incentrati sugli sviluppatori sono documentati nella Guida di Acrobat Sign per sviluppatori.

Alla data di rilascio, è possibile che non tutte le funzioni o modifiche siano abilitate. Fai sempre riferimento alla versione in inglese americano della pagina come versione più aggiornata e accurata.

Rilascio di Adobe Acrobat Sign v17.0.1

Distribuzione produzione: 17 marzo 2026

Distribuzione GovCloud: 19 marzo 2026

Funzionalità migliorate

Crea una copia – Punti di accesso ampliati, riutilizzo più veloce degli accordi.
Crea una copia è ora disponibile direttamente dai filtri In corso e In attesa di te nella pagina Gestisci, oltre che dalla pagina di conferma post-invio. Questi punti di accesso aggiuntivi semplificano il riutilizzo degli accordi in più fasi del ciclo di invio, riducendo la necessità di riavviare da zero.
Nota: Con questo rilascio, i controlli amministrativi per disabilitare questa funzionalità verranno rimossi dal menu amministratore, stabilendo Crea una copia come funzionalità normale disponibile per tutti gli utenti idonei.

Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: account e Gruppo; Abilitato per impostazione predefinita.

Rivedi la documentazione aggiornata delle azioni Utente >

Aggiornamenti API REST/Webhook

Gli aggiornamenti delle API e del webhook per questa versione sono disponibili nella Documentazione delle API di Acrobat Sign.

Visualizzazione indirizzo e-mail personalizzato OEM 2.0 – Identità mittente e destinatario più chiara nelle esperienze integrate e consegna corretta dell'indirizzo e-mail.
Per i flussi di lavoro integrati OEM 2.0, Acrobat Sign ora visualizza l'indirizzo e-mail personalizzato di un Utente invece dell'indirizzo e-mail registrato dal partner nelle principali superfici dell'interfaccia e nelle notifica. Gli accordi, le code come "In attesa di te" e le e-mail "Rivedere e firmare" riflettono costantemente l'identità personalizzata mantenendo internamente l'indirizzo e-mail registrato per autenticazione e autorizzazioni. Questo migliora la chiarezza per mittenti e firmatari e impedisce l'invio di e-mail a indirizzi registrati non consegnabili.

Ambienti disponibili: Sandbox, Commercial | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: API

Notifica webhook per errori di consegna SMS – Visibilità in tempo reale sui mancati invii SMS, correzione automatica e parità con i rimbalzi e-mail.
Acrobat Sign ora emette un nuovo evento webhook, AGREEMENT_PHONE_BOUNCED, quando un accordo inviato tramite SMS non può essere consegnato a causa di problemi come numeri di telefono non valido, rifiuto del gestore o linee bloccate. Questo consente ai clienti di rilevare i problemi di consegna SMS quasi in tempo reale e di attivare automaticamente azioni di follow-up come la correzione dei numeri di telefono, il nuovo tentativo di consegna o l'apertura di casi di supporto, eliminando i punti ciechi e riducendo i ritardi nei flussi di lavoro di firma mobile-first.

Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | ambito di configurazione: API

Payload webhook – Aggiunto campo condizionale extendedStatus del partecipante per aggiornamenti dinamici della partecipazione, migliorando la Visibilità dello stato del partecipante.
Le notifiche webhook ora includono un campo extendedStatus in ogni oggetto partecipante (memberInfos[]) quando il mittente modifica un accordo in corso utilizzando la partecipazione dinamica. Questo campo fornisce dettagli aggiuntivi del ciclo di vita del partecipante lasciando invariato il campo stato esistente per la compatibilità con le versioni precedenti.

        {
          &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;
            }
          ]
        }

status valori (invariati): ACTIVE, REPLACED.
extendedStatus valori: ACTIVE, REPLACED, REMOVED, COMPLETED.

Ambienti disponibili: Sandbox, Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: API

Problemi risolti

Problema	Descrizione
4543515	Riepilogo: Un evento di rimbalzo e-mail webhook potrebbe essere generato erroneamente per un firmatario valido dopo che il firmatario ha firmato con successo e l'accordo avanza al passaggio successivo. Questo può verificarsi quando un delegato nello stesso gruppo di firma ha un indirizzo e-mail non valido e il mittente sostituisce il delegante originale. In questi casi, il sistema potrebbe attribuire erroneamente l'evento di rimbalzo "firmato per conto di..." al firmatario valido invece del partecipante il cui indirizzo e-mail rimbalza effettivamente.
4543515	Correzione: La logica di attribuzione degli eventi è stata corretta in modo che gli eventi di rimbalzo e-mail siano associati solo al partecipante il cui indirizzo e-mail rimbalza effettivamente. Un evento di rimbalzo non viene più generato per un firmatario valido che ha già completato la firma, e le notifiche webhook ora riflettono il partecipante e l'indirizzo e-mail corretti.
4544548	Riepilogo: Le chiavi di integrazione create tramite l'interfaccia web potrebbero scadere dopo 10 anni, anche se la pagina di creazione indica che la chiave fornisce "accesso permanente." Quando una chiave raggiunge la sua durata a vita di 10 anni, le chiamate API iniziano a restituire un errore di token scaduto, che potrebbe interrompere le integrazioni esistenti inaspettatamente.
4544548	Correzione: La messaggistica dell'interfaccia è stata aggiornata per rimuovere la dicitura "accesso permanente" e visualizzare chiaramente la data di scadenza per le chiavi di integrazione. Il testo aggiornato ora indica che la chiave mantiene l'accesso fino alla data di scadenza o fino a quando non viene revocata manualmente, fornendo trasparenza sulla durata a vita predefinita di 10 anni.
4546301	Riepilogo: La consegna degli eventi webhook potrebbe essere ritardata fino a diverse ore per accordi con documenti molto grandi, anche quando la creazione dell'accordo si completa e i passaggi di in elaborazione iniziali sembrano finire entro minuti. Durante la finestra di ritardo, il servizio di consegna webhook potrebbe ricevere ripetutamente risposte DOCUMENT_NOT_AVAILABLE quando tenta di recuperare i documenti dell'accordo, e l'evento webhook potrebbe non essere consegnato fino a quando il servizio smette di riprovare o i documenti diventano disponibili.
4546301	Correzione: La gestione della disponibilità dei documenti è stata corretta in modo che gli accordi grandi passino in modo affidabile a uno stato in cui i documenti sono recuperabili senza risposte DOCUMENT_NOT_AVAILABLE prolungate. Di conseguenza, gli eventi webhook vengono consegnati senza ritardi di più ore causati dai tentativi di recupero documenti contro documenti non disponibili.
4547823	Riepilogo: Il messaggio privato di un destinatario potrebbe non essere visualizzato per alcuni firmatari quando un accordo viene creato nello stato authoring tramite l'API e poi modificato dall'esperienza Gestire. In questo scenario, l'interfaccia potrebbe mostrare il Valore del messaggio privato come "Nessuno" o vuoto anche se i dati dell'accordo includono il Valore del messaggio privato corretto. Questo comportamento appare negli scenari di account condiviso dove un Utente passa nell'account di un altro Utente per modificare la bozza, e potrebbe interessare solo destinatari specifici mentre altri vengono visualizzati correttamente.
4547823	Correzione: È stato aggiunto un controllo per recuperare il contesto di condivisione primario e restituire il messaggio privato per gli utenti condivisi autorizzati. Di conseguenza, il Valore del messaggio privato ora viene visualizzato correttamente quando si visualizza o si invia una bozza creata tramite API dal flusso authoring.
4548274	Riepilogo: La data di modifica per i modelli di libreria potrebbe non aggiornarsi dopo che un Modello viene modificato e salvato nella nuova esperienza Modello. Gli utenti potrebbero vedere campi appena aggiunti o aggiornati nel modello, ma la data di modifica rimane invariata nell'interfaccia di gestione e nelle visualizzazioni amministrative, facendo sembrare che il modello non sia stato modificato di recente. Questo accade perché la nuova esperienza aggiorna i campi del modulo attraverso un percorso che non aggiorna anche la marca temporale di modifica del modello.
4548274	Correzione: Il comportamento di aggiornamento della data di modifica è stato allineato tra la nuova esperienza del modello e le relative operazioni API. Il percorso del codice che salva le modifiche ai campi del modello ora aggiorna anche la data di modifica del modello in modo che rifletta l'ora effettiva della modifica più recente.
4548564	Riepilogo: Le firme e i campi del modulo potrebbero apparire invisibili nel pdf firmato quando vengono posizionati sopra annotazioni timbro preesistenti nel documento di origine. Nei modelli interessati, le annotazioni timbro si sovrappongono o oscurano i campi interattivi durante l'elaborazione, causando la scomparsa delle firme completate e di altri campi nel documento firmato finale.
4548564	Correzione: La gestione delle annotazioni timbro è stata aggiornata per elaborare e appiattire in modo sicuro le annotazioni timbro preesistenti in modo che non oscurino più i campi del modulo o le firme. I campi posizionati sopra le aree timbrate ora rimangono visibili durante la firma e nel pdf completamente eseguito.
4549103	Riepilogo: Un evento di rimbalzo dell'indirizzo e-mail potrebbe essere registrato nuovamente per un destinatario precedentemente errato dopo che il mittente sostituisce quel destinatario con un indirizzo e-mail valido. In alcuni casi, la traccia di controllo potrebbe mostrare un secondo evento di rimbalzo per il vecchio indirizzo e-mail, e lo stato dell'accordo potrebbe riflettere "indirizzo e-mail rimbalzato" anche se il nuovo destinatario riceve, visualizza o firma con successo l'accordo. Questo comportamento può far sembrare che l'accordo stia ancora puntando sia al vecchio che al nuovo indirizzo e-mail.
4549103	Correzione: Il flusso di lavoro di sostituzione del firmatario è stato aggiornato per impedire l'invio di indirizzo e-mail di notifica aggiuntivi a un destinatario sostituito il cui indirizzo e-mail è già rimbalzato. Il sistema ora controlla la cronologia di rimbalzi precedenti prima di inviare notifiche relative alla sostituzione, assicurando che non vengano generati nuovi eventi di rimbalzo per il vecchio indirizzo e-mail dopo la sostituzione.
4549306	Riepilogo: Gli utenti i cui indirizzi e-mail contengono determinati caratteri speciali (ad esempio, un apostrofo) potrebbero non riuscire ad accedere dalle pagine di accesso pubbliche generiche adobesign.com o echosign.com. Dopo aver inserito l'indirizzo e-mail e aver fatto clic nel campo password, la pagina potrebbe ricaricarsi e cancellare il campo indirizzo e-mail invece di reindirizzare l'utente al frammento corretto o alla pagina di accesso SSO. Questo impedisce agli utenti interessati di completare l'autenticazione e blocca le integrazioni che si basano sull'endpoint di accesso pubblico.
4549306	Correzione: La logica di risoluzione del frammento di accesso è stata corretta per gestire e decodificare correttamente gli indirizzi e-mail contenenti caratteri speciali prima di costruire l'URL di reindirizzamento tra frammenti. Gli utenti con formati di indirizzo e-mail interessati ora vengono correttamente reindirizzati al loro frammento designato e alla pagina di accesso SSO senza che il campo indirizzo e-mail venga cancellato.
4549331	Riepilogo: Le firme e altri campi del modulo potrebbero apparire mancanti o invisibili nel pdf firmato quando determinate funzionalità di elaborazione del documento sono abilitate e il pdf di origine contiene coordinate della casella della pagina non valide (ad esempio, valori CropBox o MediaBox errati). In questo scenario, i campi che si basano sulle coordinate della pagina potrebbero essere visualizzati al di fuori dell'area visibile della pagina, facendo apparire le firme completate come mancanti anche se la firma viene completata con successo.
4549331	Correzione: La gestione della casella della pagina pdf è stata corretta per normalizzare in modo sicuro i valori CropBox e MediaBox non validi durante l'elaborazione del documento. Di conseguenza, il posizionamento delle firme e dei campi del modulo ora si allinea all'area visibile della pagina e i pdf firmati visualizzano le firme come previsto.
4550367	Riepilogo: La creazione di un modulo web potrebbe non riuscire con un generico "Errore del server" dopo aver selezionato Anteprima e Aggiungi campi quando l'autenticazione predefinita del firmatario del gruppo del mittente è impostata su Telefono e l'account non ha quota di autenticazione telefonica disponibile, anche se l'autenticazione del firmatario del modulo web è impostata su un metodo non telefonico (ad esempio, Adobe Sign). Di conseguenza, tutti gli utenti nell'account interessato potrebbero essere bloccati dalla creazione di moduli web su tutti i documenti.
4550367	Correzione: La creazione del modulo web ora valuta la quota solo per il metodo di autenticazione effettivamente configurato per il firmatario del modulo web e non applica più i controlli della quota di autenticazione telefonica basati esclusivamente sull'impostazione di autenticazione predefinita del gruppo. Questo impedisce errori di esaurimento quota falsi e consente di creare normalmente i moduli web.
4551011	Riepilogo: Quando un mittente carica determinati pdf scansionati, aggiunge campi firma e invia l'accordo, il pdf firmato potrebbe non mostrare firme visibili dopo il completamento della firma. Questo comportamento può verificarsi quando il pdf caricato contiene metadati non validi dei limiti della pagina (le coordinate MediaBox e CropBox appaiono invertite), il che può causare il rendering della firma e di altri livelli di aspetto dei campi al di fuori dell'area visibile della pagina.
4551011	Correzione: La gestione dei limiti della pagina pdf è stata aggiornata per elaborare correttamente i pdf con valori di coordinate MediaBox e CropBox non validi o invertiti, in modo che il contenuto dell'aspetto della firma e dei campi modulo venga visualizzato nell'area visibile della pagina e rimanga visibile nel pdf firmato finale.
4551427	Riepilogo: Alcuni destinatari che hanno già account primari correttamente configurati ricevono accordi come destinatari "pseudo Utente" invece, quindi l'accordo non appare nella loro normale vista Gestisci. Questo accade quando gli indirizzi e-mail dei destinatari includono spazi iniziali o finali, il che impedisce al sistema di abbinare l'indirizzo e-mail all'Utente esistente e causa la creazione di un record pseudo-Utente.
4551427	Correzione: L'analisi dell'indirizzo e-mail e la ricerca dell'Utente sono state aggiornate per normalizzare gli indirizzi e-mail dei destinatari (rimuovere gli spazi iniziali e finali) prima di abbinarli agli utenti esistenti. Di conseguenza, gli accordi indirizzati agli utenti esistenti si risolvono nell'account registrato invece di creare un destinatario pseudo-Utente, anche se l'indirizzo e-mail è stato inserito con spazi (nei payload API e negli elenchi dei destinatari del flusso di lavoro).
4553198	Riepilogo: Quando un accordo include almeno un destinatario configurato per la consegna SMS e almeno un destinatario configurato per la consegna solo tramite indirizzo e-mail, l'annullamento dell'accordo tramite API non invia una notifica di annullamento SMS al destinatario SMS. L'accordo viene annullato con successo e le notifiche tramite indirizzo e-mail vengono consegnate, ma i destinatari SMS non ricevono un messaggio di annullamento.
4553198	Correzione: Il flusso di lavoro di annullamento è stato corretto per garantire che le notifiche di annullamento SMS vengano inviate a tutti i destinatari configurati per la consegna SMS quando un accordo viene annullato, indipendentemente dai metodi di consegna degli altri destinatari.
4554463	Riepilogo: Quando gli accordi includono pulsanti di scelta clonati che condividono lo stesso nome campo tra documenti combinati, solo un'Istanza dell'opzione selezionata rimane selezionata nel pdf firmato finale. Sebbene i campi appaiano visivamente come caselle di controllo, sono implementati come pulsanti di scelta. Dopo la firma, il Valore selezionato non si propaga in modo coerente tra tutte le istanze clonate, causando una mappatura errata o incompleta della selezione prevista.
4554463	Correzione: La logica di gestione dei campi modulo è stata corretta in modo che i pulsanti di scelta clonati memorizzino e propaghino il Valore di esportazione selezionato anziché un Valore di Indice interno. Questo garantisce che tutte le istanze clonate dello stesso campo pulsante di scelta riflettano la selezione corretta nel pdf firmato.
4554593	Riepilogo: Alcune integrazioni partner che utilizzano gli endpoint OAuth tradizionali per aggiornare i token di accesso hanno iniziato a fallire con errori HTTP 401. Il servizio ha rifiutato le richieste di aggiornamento token con un errore che indica che l'applicazione non è autorizzata a utilizzare gli endpoint OAuth tradizionali e deve utilizzare invece gli endpoint OAuth v2. Questo ha bloccato i clienti dall'autenticazione di acrobat sign tramite applicazioni partner, anche per integrazioni che funzionavano in precedenza.
4554593	Correzione: Il servizio di autenticazione è stato corretto in modo che le applicazioni partner configurate per utilizzare il flusso OAuth tradizionale possano aggiornare nuovamente i token con successo, invece di essere forzate erroneamente sugli endpoint OAuth v2.
4554614	Riepilogo: Quando un firmatario utilizza l'esperienza di firma elettronica moderna su un accordo che richiede autenticazione del firmatario ed è configurato per richiedere l'accettazione delle Condizioni d'uso prima della firma, fare clic su Fai clic per firmare attiva un reindirizzamento di 5 secondi all'esperienza di firma classica. Il messaggio di reindirizzamento avverte che le firme e le iniziali inserite nella firma moderna verranno cancellate, costringendo il firmatario a reinserirle e di fatto a firmare due volte.
4554614	Correzione: Il flusso di aggiornamento del token di firma è stato corretto in modo che quando il firmatario accetta le Condizioni d'uso prima della firma, il token di firma riemesso mantenga i dettagli di autenticazione del firmatario. Questo impedisce al passaggio finale di firma di fallire l'autenticazione ed elimina il fallback forzato dalla firma moderna all'esperienza classica.
4555656	Riepilogo: In condizioni di tempistica specifiche, una transizione di stato dell'accordo può sembrare riuscire ma non cambiare effettivamente lo stato dell'accordo. Quando una notifica webhook viene ricevuta prima del completamento dell'elaborazione backend, le chiamate API successive possono utilizzare dati di stato dell'accordo obsoleti. In questa finestra, alcuni metodi di transizione di stato restituiscono HTTP 200 OK anche se l'accordo non si trova in uno stato valido per la transizione richiesta. Di conseguenza, i flussi di lavoro di automazione potrebbero presumere che la transizione sia riuscita mentre l'accordo rimane nello stato originale.
4555656	Correzione: La logica di transizione dello stato dell'accordo è stata aggiornata per applicare una convalida rigorosa prima di applicare una transizione. Se l'accordo non si trova in uno stato valido, l'API ora restituisce una risposta di errore chiara invece di restituire silenziosamente un successo. Questo garantisce che le transizioni non valide vengano esplicitamente rifiutate, consente ai sistemi chiamanti di riprovare in modo appropriato e impedisce agli accordi di rimanere in uno stato non intenzionale senza visibilità.