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.

Versione Adobe Acrobat Sign v17.0.1

Implementazione in produzione: 17 marzo 2026

Implementazione GovCloud: 19 marzo 2026

Funzionalità migliorate

Crea una copia – Punti di accesso ampliati, riutilizzo più rapido degli accordi.
La funzione Crea una copia è ora disponibile direttamente dai filtri In corso e In attesa del tuo intervento 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 vita dell’invio, riducendo la necessità di ricominciare da capo.
Nota: con questa versione, i controlli amministrativi per disabilitare questa funzione verranno rimossi dal menu di amministrazione per rendere Crea una copia una funzionalità standard disponibile per tutti gli utenti idonei.

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

Consulta la documentazione aggiornata sulle azioni utente >

Modifiche a livello di esperienza

Visibilità scadenza chiave di integrazione: le date di scadenza sono ora mostrate nella scheda Token di accesso
La scheda Token di accesso, nel menu Preferenze personali e viene indicata per ciascuna chiave di integrazione. Questo offre utenti e amministratori una visibilità più chiara sulla durata delle chiavi e sulle tempistiche di sostituzione, rendendo più semplice il monitoraggio quelle già esistenti ed evitando interruzioni impreviste quando una chiave raggiunge la fine del suo periodo di validità di 10 anni.

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

Aggiornamenti API REST/Webhook

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

Visualizzazione e-mail personalizzata OEM 2.0: identità di mittente e destinatario più chiara nelle esperienze integrate e consegna corretta delle email.
Per i partner OEM 2.0 che utilizzano flussi di lavoro integrati, Acrobat Sign può ora visualizzare l’indirizzo e-mail personalizzato di un utente invece dell’e-mail registrata dal partner nelle superfici dell’interfaccia e nelle notifiche principali. Gli accordi, le code come “In attesa di te” e le e-mail “Rivedi e firma” riflettono costantemente l’identità personalizzata, al contempo preservando internamente l’e-mail registrata per autenticazione e autorizzazioni. Questo consente una migliore chiarezza per mittenti e firmatari e impedisce l’invio di e-mail a indirizzi registrati non recapitabili.

Ambienti disponibili: Sandbox, Commercial | Livelli di servizio disponibili: Acrobat Sign Solutions | Ambito di configurazione: API - partner OEM 2.0; solo su richiesta

Notifica webhook per errori di consegna SMS – Visibilità in tempo reale degli invii SMS non riusciti, correzione automatica e parità con i mancati recapiti 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 validi, rifiuto del gestore o linee bloccate. Questo consente alla clientela di rilevare gli errori di consegna SMS quasi in tempo reale e di attivare automaticamente azioni di follow-up come correggere i numeri di telefono, riprovare la consegna o aprire 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;
            }
          ]
        }

Valori status (invariati): ACTIVE, REPLACED.
Valori extendedStatus: 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 webhook di mancato recapito e-mail può 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 può attribuire erroneamente l’evento di mancato recapito “Firmato per conto di...” al firmatario valido anziché al partecipante la cui e-mail effettivamente non viene recapitata.
4543515	Correzione: la logica di attribuzione dell’evento è stata corretta in modo che gli eventi di mancato recapito e-mail siano associati solo al partecipante la cui e-mail effettivamente non viene recapitata. Un evento di mancato recapito 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 utente web possono scadere dopo 10 anni, anche se la pagina di creazione indica che la chiave fornisce un “accesso permanente”. Quando una chiave raggiunge la durata di 10 anni, le chiamate API iniziano a restituire un errore di token scaduto, che può interrompere inaspettatamente le integrazioni esistenti.
4544548	Correzione: la messaggistica dell’interfaccia utente è 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 alla revoca manuale, fornendo trasparenza sulla durata predefinita di 10 anni.
4546301	Riepilogo: La consegna degli eventi webhook potrebbe subire ritardi fino a diverse ore per accordi con documenti molto grandi, anche quando la creazione dell’accordo viene completata e i passaggi di elaborazione iniziali sembrano terminare in pochi 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 non smette di riprovare o i documenti non diventano disponibili.
4546301	Correzione: La gestione della disponibilità dei documenti è stata corretta in modo che gli accordi di grandi dimensioni 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 i ritardi di più ore, causati dai nuovi tentativi di recupero dei documenti non disponibili.
4547823	Riepilogo: il messaggio privato di un destinatario potrebbe non essere visualizzato per alcuni firmatari quando un accordo viene creato in stato di Authoring tramite l’API e poi modificato tramite l’esperienza Gestisci. In questo scenario, l’interfaccia utente potrebbe mostrare il valore del messaggio privato come “Nessuno” o vuoto anche se i dati dell’accordo includono il valore corretto del messaggio privato. Questo comportamento si verifica in scenari di account condivisi dove un utente passa all’account di un altro utente per modificare la bozza e può interessare solo destinatari specifici, mentre altri vengono visualizzati correttamente.
4547823	Correzione: è stato aggiunto un controllo per recuperare il contesto di condivisione attivo 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 visualizzare campi appena aggiunti o aggiornati sul modello, ma la data di modifica rimane invariata nell’interfaccia Gestisci e nelle viste 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 modello e le operazioni API correlate. Il percorso di 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 risultare invisibili nel PDF firmato quando vengono posizionati sopra annotazioni con timbro preesistenti nel documento di origine. Nei modelli interessati, le annotazioni con timbro si sovrappongono oppure oscurano i campi interattivi durante l’elaborazione, nascondendo le firme completate ed altri campi nel documento firmato finale.
4548564	Correzione: la gestione delle annotazioni con timbro è stata aggiornata per elaborare e appiattire quelle preesistenti in modo sicuro, così da non oscurare più i campi del modulo o le firme. I campi posizionati su aree con timbro ora rimangono visibili durante la firma e nel PDF completamente eseguito.
4549103	Riepilogo: Un evento di mancato recapito 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, l’audit trail potrebbe mostrare un secondo evento di mancato recapito per la vecchia e-mail, e lo stato dell’accordo potrebbe riflettere “e-mail non recapitata” anche se il nuovo destinatario riceve, visualizza o firma correttamente 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 e-mail di notifica aggiuntive a un destinatario sostituito la cui e-mail ha già avuto un mancato recapito. Il sistema ora controlla la cronologia dei mancati recapiti precedenti prima di inviare notifiche relative alla sostituzione, assicurando che non vengano generati nuovi eventi di mancato recapito 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 immesso l’indirizzo e-mail e aver fatto clic nel campo password, la pagina potrebbe ricaricarsi e cancellare il campo e-mail invece di reindirizzare l’utente alla partizione corretta 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 della partizione di accesso è stata corretta per gestire e decodificare correttamente gli indirizzi e-mail contenenti caratteri speciali prima di costruire l’URL di reindirizzamento tra partizioni. Gli utenti con formati e-mail interessati vengono ora reindirizzati correttamente alla partizione designata e alla pagina di accesso SSO senza che il campo 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 di pagina non valide (ad esempio, valori CropBox o MediaBox non corretti). In questo scenario, i campi che si basano sulle coordinate della pagina potrebbero essere visualizzati al di fuori dell’area della pagina visibile, facendo apparire le firme completate come mancanti anche se la firma viene eseguita correttamente.
4549331	Correzione: La gestione della casella di 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 della firma e del campo del modulo ora si allinea all’area della pagina visibile e i PDF firmati visualizzano le firme come previsto.
4550367	Riepilogo: la creazione di un modulo web potrebbe non riuscire presentando un “Errore del server” generico dopo aver selezionato Anteprima e Aggiungi campi quando l’autenticazione del firmatario predefinita del gruppo del mittente è impostata su Telefono e l’account non dispone di quota disponibile di autenticazione telefonica, anche se l’autenticazione del firmatario del modulo web è impostata su un metodo diverso da quello telefonico (ad esempio, Adobe Sign). Di conseguenza, a tutti gli utenti dell’account interessato potrebbe essere impedito di creare moduli web in 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 evita falsi errori di esaurimento della quota e consente la normale creazione dei moduli web.
4551011	Riepilogo: Quando un mittente carica determinati PDF scansionati, aggiunge campi firma e invia l’accordo, il PDF firmato potrebbe non visualizzare firme visibili dopo il completamento della firma. Questo comportamento può verificarsi quando il PDF caricato contiene metadati dei confini di pagina non validi (le coordinate MediaBox e CropBox appaiono invertite), il che può causare la visualizzazione dei livelli di aspetto della firma e di altri campi al di fuori dell’area della pagina visibile.
4551011	Correzione: la gestione dei margini delle pagine PDF è stata aggiornata per elaborare correttamente quelle che presentano valori di coordinate MediaBox e CropBox non validi o invertiti, in modo che il contenuto relativo all’aspetto della firma e del campo del modulo sia visualizzabile all’interno dell’area della pagina visibile e che rimanga tale anche nel PDF firmato finale.
4551427	Riepilogo: alcuni destinatari che dispongono già di account attivi e correttamente configurati ricevono gli accordi come destinatari “pseudo utente”, di conseguenza l’accordo non viene visualizzato nella 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’e-mail all’utente esistente e causa la creazione di un record pseudo-utente.
4551427	Correzione: l’analisi delle e-mail e la ricerca degli utenti sono state aggiornate per normalizzare gli indirizzi e-mail dei destinatari (rimuovendo gli spazi iniziali e finali) prima che vengano associati 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’e-mail è stata immessa 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 e-mail, l’annullamento dell’accordo tramite l’API non invia una notifica di annullamento SMS al destinatario SMS. L’accordo viene annullato con successo e le notifiche 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 di campo tra documenti combinati, nel PDF firmato finale rimane selezionata una sola istanza dell’opzione scelta. 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 in 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 legacy per aggiornare i token di accesso potevano non riuscire presentando errori HTTP 401. Il servizio ha rifiutato le richieste di aggiornamento token con un errore che indica che l’app non è autorizzata a utilizzare gli endpoint OAuth tradizionali e deve utilizzare invece gli endpoint OAuth v2. Questo ha impedito ai clienti di autenticare Acrobat Sign tramite le app partner, anche per integrazioni che funzionavano in precedenza.
4554593	Correzione: Il servizio di autenticazione è stato corretto in modo che le app 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 l’autenticazione del firmatario ed è configurato per richiedere l’accettazione delle condizioni d’uso prima della firma, facendo clic su Fai clic per firmare si 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 a firmare di fatto 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 evita gli errori di autenticazione nell’ultima fase di firma ed elimina il fallback forzato dall’esperienza di firma moderna a quella classica.
4555656	Riepilogo: In condizioni di tempistica specifiche, una transizione di stato dell’accordo può sembrare riuscire ma non cambia 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 è in uno stato valido per la transizione richiesta. Di conseguenza, i flussi di lavoro di automazione possono considerare la transizione come completata, mentre l’accordo rimane nello stato originale.
4555656	Correzione: la logica di transizione di stato dell’accordo è stata aggiornata per eseguire una convalida rigorosa prima di applicare una transizione. Se l’accordo non è in uno stato valido, ora l’API restituisce una risposta di errore chiara, anziché restituirne la riuscita senza alcun avviso. 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à.