Prima segnalazione: agosto 2024
Ultimo aggiornamento il
3 giu 2026
Le notifiche tecniche di adobe sign sono ordinate di seguito con l'aggiornamento più vecchio in alto e procedendo in avanti nel tempo scorrendo verso il basso la pagina.
|
|
Rimosso dall’elenco attuale: gennaio 2025 |
|---|
La precedente intestazione Accept-Charset verrà rimossa da tutte le notifiche webhook e callback con la versione di novembre 2024.
Tutti i clienti che usano a questa intestazione per qualsiasi motivo devono ridefinire il codice per tenere in conto la sua mancanza.
|
Prima segnalazione: settembre 2024 |
Rimosso dall’elenco attuale: gennaio 2025 |
|---|
|
Prima segnalazione: novembre 2024 |
Rimosso dall’elenco attuale: gennaio 2025 |
|---|
Con la versione di novembre 2024, le etichette modificabili nella Progettazione flussi di lavoro personalizzati sono state limitate a 100 caratteri. Questo limite viene valutato quando viene creato o aggiornato il flusso di lavoro.
I flussi di lavoro preesistenti con etichette superiori a 100 caratteri possono comunque essere inviati correttamente, ma se il flusso di lavoro viene aggiornato, prima di poterlo salvare, è necessario ridurre l’etichetta a 100 caratteri o meno. Le etichette dannose sono contrassegnate in rosso per facilitarne l’individuazione.
Nei nuovi flussi di lavoro, il limite di etichette verrà segnalato prima che vengano salvati.
Azione necessaria
Si consiglia agli amministratori con controllo sui flussi di lavoro personalizzati di aprire e di rivedere ogni flusso di lavoro per garantire che nel modello non vengano generati errori.
|
Prima segnalazione: novembre 2024 |
Rimosso dall’elenco Attuale: febbraio 2025 |
|---|
La nuova esperienza del destinatario contiene miglioramenti della firma sia per browser web desktop che per dispositivi mobili. Questa nuova esperienza verrà implementata nei primi mesi del 2025, ma sarà disponibile nell’ambiente sandbox nella prima settimana di dicembre 2024.
|
Prima segnalazione: dicembre 2024 |
Rimosso dall’elenco Attuale: febbraio 2025 |
|---|
Adobe Acrobat Sign sostituirà il certificato SSL di Adobe Acrobat Sign il 22 gennaio 2025.
Inoltre, viene distribuito un nuovo certificato SSL per supportare le modifiche alla rete WAF apportate a gennaio 2025. Questo nuovo certificato influisce direttamente sull’accesso al servizio Acrobat Sign e deve essere installato prima che il WAF sia messo online.
Azione necessaria
- Ogni account cliente che garantisce esplicitamente l’attività della rete deve includere il nuovo certificato SSL WAF nel suo elenco di certificati archiviati.
- Se sono state implementate integrazioni personalizzate con Acrobat Sign utilizzando le API SOAP o REST e se alcune di tali integrazioni richiedono il “pinning” della chiave pubblica esistente, non è necessario alcun intervento.
- Se stai utilizzando i Certificati SSL di acrobat sign per SSO o se stai agganciando il certificato stesso (o utilizzando altri metodi), puoi trovare i nuovi Certificati SSL di acrobat sign nei requisiti di sistema di adobe acrobat sign.
- Se la configurazione SSO supporta più certificati/catene di certificati pubbliche, si possono aggiungere subito i nuovi certificati e rimuovere dalla configurazione quelli precedenti dopo la sostituzione in gennaio.
- Se SSO non supporta più certificati/catene di certificati pubbliche, sarà necessario sincronizzare il passaggio al nuovo SSL con Acrobat Sign il 22 gennaio 2025.
I nuovi certificati SSL saranno attivi dal 22 gennaio 2025.
|
Prima segnalazione: settembre 2024 - Aggiornamento: febbraio 2025 |
Rimosso dall'elenco corrente: marzo 2025 |
|---|
Per migliorare la sicurezza e l’affidabilità del servizio Adobe Acrobat Sign, inizieremo a introdurre le modifiche apportate alla rete per includere un firewall per applicazioni web (WAF, Web Application Firewall) a febbraio 2025. Queste modifiche indirizzeranno il traffico ai server dell’applicazione Acrobat Sign tramite il servizio WAF. Questo indirizzamento sarà invisibile per la maggior parte della clientela. L’utilizzo non interferirà con l’accesso ad Acrobat Sign da parte di qualsiasi client o integrazione Adobe.
Azione necessaria
Nessuna.
Questa modifica non avrà alcun impatto sulle integrazioni della clientela, poiché i nomi del dominio API e le API di Acrobat Sign non cambieranno. Questa soluzione è retrocompatibile con gli intervalli di IP pubblicati.
I clienti che hanno aggiornato i loro dispositivi di sicurezza non devono ripristinare o apportare altre modifiche.
La pianificazione corrente dell’aggiornamento è la seguente:
- La sandbox di produzione viene aggiornata il 24 febbraio 2025.
- Le partizioni di produzione IN1, JP1, AU1 e SG1 verranno aggiornate il 3 marzo 2025.
- Le partizioni di produzione NA2, NA3 e EU2 verranno aggiornate il 6 marzo 2025.
- Le partizioni di produzione NA1, NA4 e EU1 verranno aggiornate l’11 marzo 2025.
Accesso in ingresso e in uscita da Acrobat Sign
L’elenco degli indirizzi IP in entrata del server non saranno più rimossi da Acrobat Sign come annunciato in precedenza.
Gli indirizzi IP in entrata e in uscita del server, come documentato alla pagina Requisiti di sistema per Acrobat Sign, resteranno validi.
Perché Acrobat Sign sta apportando queste modifiche?
L’utilizzo di un WAF migliora la protezione di Acrobat Sign dal traffico dannoso e aiuta a soddisfare meglio i requisiti di sicurezza, solidità e conformità.
Dispongo di un’integrazione personalizzata con Acrobat Sign. La mia applicazione sarà interessata?
No, non ci aspettiamo alcun impatto negativo sulle integrazioni.
Sono disponibili nuovi elenchi di indirizzi IP da sostituire?
No.
Le informazioni nella pagina requisiti di sistema per acrobat sign rimangono accurate.
La mia organizzazione ha implementato il filtro della rete utilizzando l’elenco dei domini pubblicato di Acrobat Sign per il traffico dalla nostra rete aziendale. Queste modifiche avranno un impatto per noi?
No.
Le modifiche di rete descritte qui non influiscono sull'elenco dei domini di acrobat sign, come documentato nella pagina requisiti di sistema per acrobat sign. Il filtro a livello di dominio rimane inalterato.
La mia organizzazione utilizza la convalida dell’indirizzo IP per l’invio delle e-mail dai server di Acrobat Sign. Queste modifiche avranno un impatto per noi?
No.
Gli intervalli IP per i relay di posta in uscita, come elencati nella pagina requisiti di sistema per acrobat sign, non cambiano.
La mia organizzazione ha configurato l’account Acrobat Sign per limitare l’accesso ai nostri stessi indirizzi IP. Queste modifiche avranno un impatto per noi?
No.
acrobat sign può essere configurato per convalidare il traffico in entrata rispetto agli indirizzi IP scelti dal cliente, come descritto nella pagina Limita l'accesso al tuo account utilizzando intervalli di indirizzi IP. Tale utilizzo non sarà interessato da questa modifica.
La mia organizzazione ha implementato il filtro della rete utilizzando l’elenco pubblicato di indirizzi IP di ingresso di Acrobat Sign. Queste modifiche avranno un impatto per noi?
No.
La nuova configurazione WAF è retrocompatibile con l’architettura di rete esistente, quindi non dovrebbe essere necessario regolare i dispositivi di sicurezza.
Nota
Tieni presente che questo si riferisce al filtro a livello IP per l’ambiente di hosting dell’applicazione. Il filtro a livello di dominio rimane inalterato.
Utilizzo l’integrazione Salesforce con elenchi degli IP consentiti configurati in modo esplicito. Devo fare qualcosa?
No.
Al momento, l’installazione WAF non richiede modifiche per le installazioni Salesforce esistenti.
La configurazione o il processo esistente, come descritto nella documentazione della Guida, rimane invariato e gli amministratori devono seguire tutti i passaggi relativi all’elenco degli IP consentiti.
Per ulteriori domande, ISV e partner Embed possono contattare il proprio Success Manager.
|
Prima segnalazione: novembre 2024 - Aggiornamento: gennaio 2025 |
Rimosso dall'elenco corrente: marzo 2025 |
|---|
I mittenti possono fornire una visualizzazione aggiuntiva degli accordi per i destinatari sui dispositivi mobili che elenca solo il campo all’interno dell’accordo disponibile per il destinatario.
I mittenti possono organizzare l’elenco dei campi in base alle proprie esigenze e raggruppare i campi in sezioni logiche per aiutare i firmatari a passare attraverso le immissioni dei campi con un minimo scorrimento.
I destinatari possono visualizzare l’elenco dei campi adatti per dispositivi mobili o la vista originale del PDF con i campi inseriti nel contenuto del documento.
Questa funzione verrà rilasciata:
- Verrà distribuita nell’ambiente sandbox l’11 dicembre 2024
- Verrà distribuita nell’ambiente di produzione il 4 marzo 2025
|
Prima segnalazione: maggio 2024 |
Rimosso dall'elenco corrente: marzo 2025 |
|---|
Nella nuova esperienza Richiedi firma, l’opzione per utilizzare un’unità esterna per caricare i file sarà limitata solo a OneDrive.
A chi utilizza altre opzioni per il caricamento dei file, si consiglia di utilizzare l’applicazione di un fornitore specifico per fornire un’unità di rete a cui è possibile accedere tramite il selettore di file nativo sul sistema locale dell’utente.
- Dropbox: https://www.dropbox.com/desktop
- Google Drive: https://support.google.com/drive/answer/10838124
- Box: https://support.box.com/hc/en-us/articles/360043697194-Installing-Box-Sync
- Acrobat/Document Cloud: https://www.adobe.com/acrobat/hub/share-sync-pdfs.html
|
Prima segnalazione: maggio 2024 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
Azione necessaria
Per garantire la continuità delle funzioni, tutte le integrazioni e le applicazioni che utilizzano le API SOAP di Adobe Acrobat Sign devono essere migrate all’ultima versione delle API REST v6 prima della data di disattivazione.
L’accesso alle API SOAP sarà rimosso per tutti i partner Embed a partire dal 1° marzo 2025.
Per garantire la continuità funzionale, tutti i partner Embed che utilizzano le API SOAP di Adobe Acrobat Sign devono migrare alla più recente API REST v6 prima del 1°marzo 2025.
Consulta la documentazione di riferimento su REST v6 e migrazione:
- Metodi API REST versione 6 per Adobe Acrobat Sign
- Migrazione da SOAP
Per qualsiasi richiesta, contatta il PSM designato per Adobe Acrobat Sign.
Nota
Questo aggiornamento interessa solo la versione Commercial del servizio Acrobat Sign. Gli account Government Cloud non sono interessati.
Questo aggiornamento si applica solo alla pagina Invia (Richiedi firme elettroniche). I flussi di lavoro Firma autonoma strutturata non sono ancora inclusi.
|
Prima segnalazione: marzo 2024 - Aggiornamento: gennaio 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
A partire dalla versione di aprile 2025, il nuovo ambiente Richiedi firma diventerà l’esperienza predefinita per la creazione di un nuovo accordo.
- Non sarà più possibile passare dal nuovo ambiente a quello classico e viceversa, in quanto i collegamenti per cambiare ambiente saranno disabilitati.
- Tramite il menu di amministrazione, gli amministratori potranno comunque abilitare l’esperienza classica e ripristinare i collegamenti per passare da un ambiente all’altro.
- Chi utilizza l’integrazione Notarize non sarà interessato da questa modifica.
|
Prima segnalazione: marzo 2024 - Aggiornato aprile 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
Nota
Questo aggiornamento interessa solo la versione Commercial del servizio Acrobat Sign. Gli account Government Cloud non sono interessati.
A partire dal rilascio di aprile 2025, l'ambiente moderno Request Signature diventerà l'esperienza predefinita disponibile durante la creazione di un nuovo modello Invia in blocco.
- Gli utenti non potranno tornare all'ambiente classico.
- Gli amministratori avranno la possibilità di abilitare l'esperienza classica e ripristinare i collegamenti di commutazione tramite il menu amministratore.
|
Prima segnalazione: febbraio 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
La scheda Account, disponibile per gli amministratori a livello di account di Acrobat Sign, verrà rinominata Amministrazione.
- Questo aggiornamento si applica esclusivamente all’ambiente autonomo di Acrobat Sign (Acrobat Sign Solutions e Acrobat Sign per la Pubblica Amministrazione).
- L’aggiornamento verrà implementato per l’ambiente Commercial ad aprile 2025 e per l’ambiente Government a maggio 2025.
Tenere presente che questa modifica è puramente estetica: non vi sono modifiche funzionali, solo aggiornamenti alle etichette delle schede.
Nota
L’etichetta Gruppo per gli amministratori a livello di gruppo non cambierà.
|
Prima segnalazione: marzo 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
- Esperienza di accesso utente migliorata: Acrobat Sign ha semplificato il processo di accesso e di autenticazione tramite il Sistema di gestione delle identità di Adobe (IMS).
- Il profilo organizzativo dell’utente viene selezionato automaticamente durante il processo di accesso per quelli autorizzati al servizio Acrobat Sign (identificando la richiesta come proveniente da un’origine Acrobat Sign)
- Gli utenti che riscontrano errori durante l’accesso avranno collegamenti nei messaggi di errore per contattare gli amministratori di Acrobat Sign per ricevere assistenza.
- A tutti gli utenti a cui è stato assegnato un diritto attivo ma che non hanno effettuato l’accesso al servizio verranno inviati fino a due promemoria e-mail. (Questo vale anche per gli utenti inattivi esistenti prima della data di rilascio)
Questi miglioramenti semplificano l’accesso, riducendo gli ostacoli e favorendo un’esperienza utente ottimale.
Ambienti disponibili: Commercial | Livelli di servizio disponibili: Acrobat Signs Solutions | Ambito di configurazione: abilitata per impostazione predefinita; non configurabile
|
Prima segnalazione: marzo 2025 - Aggiornato: aprile 2025 |
Rimosso dall'elenco corrente: giugno 2025 |
|---|
A partire da maggio 2025, Acrobat Sign implementerà limiti più rigidi per il numero di webhook creati negli account a livello Sviluppatore.
Questi limiti sono state appositamente selezionati per garantire l’affidabilità dell’infrastruttura webhook e ottimizzati per la verifica dei flussi di lavoro.
|
Che cosa cambia |
Limite precedente |
Nuovo limite |
Descrizione |
|---|---|---|---|
|
Numero di webhook attivi creati per canale |
10 |
1 |
È consentito un webhook per canale per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per un account |
100 |
2 |
Sono consentiti due webhook a livello di account per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per gruppo |
100 |
2 |
Sono consentiti due webhook di livello per gruppo per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per risorsa accordo |
50 |
1 |
È consentito un webhook per accordo per evento di abbonamento del webhook. |
|
Numero di webhook attivi creati per utente |
100 |
1 |
È consentito un webhook per utente per evento di abbonamento del webhook. |
Ambienti disponibili: Commercial Livelli di servizio disponibili:Sviluppatore Ambito di configurazione:abilitato per impostazione predefinita; non configurabile
|
Prima segnalazione: marzo 2025 |
Rimosso dall'elenco corrente: aprile 2025 |
|---|
I clienti Acrobat Sign possono ora abbonarsi al servizio Webhook di Acrobat Sign per ricevere notifiche proattive su interruzioni, disservizi ed eventi di manutenzione tramite il Adobe Status Portal.
Gestisci e aggiungi abbonamenti qui: Adobe Status Subscription Help.
Nota che il servizio Adobe Acrobat Sign è elencato nell’intestazione Document Cloud:
|
Prima segnalazione: marzo 2025 |
Rimosso dall'elenco corrente: giugno 2025 |
|---|
Nella versione di maggio 2025, l’API GET/agreements verrà ottimizzata per ridurre significativamente i tempi di risposta. I test interni mostrano miglioramenti con tempi fino a 10 volte inferiori.
Che cosa cambia
- Dimensioni di pagina più piccole: per supportare questi miglioramenti, il numero massimo di accordi restituiti per richiesta è stato ridotto a 500, ma questo limite potrebbe cambiare nelle versioni future. Ogni risposta include:
- Il numero effettivo di accordi restituiti
- Un collegamento alla pagina successiva dei risultati (se disponibile)
- Conteggio dei risultati dinamici: è comunque possibile richiedere un numero specifico di accordi, ma l’API restituirà tutti gli accordi che il servizio può fornire. Ogni risposta include:
Che cosa aspettarsi
In alcuni casi, potrebbe verificarsi un leggero ritardo tra la creazione di un accordo e il recupero utilizzando l’API GET/agreements. Questo ritardo è in genere molto breve; una richiesta di follow-up deve restituire il nuovo accordo.
Ambienti disponibili: Commercial, Government | Livelli di servizio disponibili: Acrobat Sign Services, Government | Ambito di configurazione: abilitato per impostazione predefinita; non configurabile
|
Prima segnalazione: aprile 2025 |
Rimosso dall'elenco corrente: agosto 2025 |
|---|
Tutti gli account che utilizzano il servizio Acrobat Sign for Government otterranno l'accesso per abilitare il nuovo ambiente Request Signature, insieme a diverse funzionalità create di recente che dipendono da esso:
- eWitnessing
- Accesso limitato agli accordi
- Applica tipo di firma
- Verifica identità
- CC per destinatario
- L’elenco dei destinatari e le proprietà dei destinatari sono modificabili dopo l’authoring
|
Prima segnalazione: settembre 2024 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Azione necessaria
Tutti i clienti che utilizzano l'API devono aggiornare le proprie API per utilizzare gli endpoint versione 6 il prima possibile per garantire la disponibilità ininterrotta.
Le versioni 1 a 4 dell’API REST di Acrobat Sign sono state disattivate e verranno rimosse dal servizio il 1° dicembre 2025.
L’aggiornamento delle API può comportare un impegno considerevole, pertanto si consiglia vivamente a tutta la clientela di definire l’ambito e il budget del proprio aggiornamento il prima possibile, in modo che il supporto possa pienamente dedicarsi a risolvere eventuali domande o problemi che potrebbero sorgere prima della data di scadenza, a dicembre 2025.
Sebbene le API REST v1-4 siano obsolete, continueranno a funzionare e le applicazioni continueranno a operare fino al 1 dicembre 2025, quando verranno rimosse le API REST v1-4.
Dopo il 1° dicembre 2025, le applicazioni basate sull’API REST v1–4 cesseranno di funzionare.
|
Prima segnalazione: aprile 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Tutti gli account che utilizzano il servizio Acrobat Sign for Government otterranno l'accesso per abilitare il nuovo ambiente Request Signature, insieme a diverse funzionalità create di recente che dipendono da esso:
- eWitnessing
- Accesso limitato agli accordi
- Applica tipo di firma
- Verifica identità
- CC per destinatario
- L’elenco dei destinatari e le proprietà dei destinatari sono modificabili dopo l’authoring
|
Prima segnalazione: settembre 2024 - Aggiornamento: aprile 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
L’infrastruttura Webhook 2.0 è stata implementata per tutta la clientela e, con il completamento di questa operazione, le notifiche per i firmatari sono state rimosse. Di conseguenza, il parametro webhookNotificationApplicableUsers del payload webhook non fornisce più dati utili e verrà rimosso da tutti i payload webhook.
L’ambiente sandbox verrà aggiornato nella versione di giugno.
Gli ambienti di produzione verranno aggiornati nella versione di luglio 2025.
L’ID utente e l’e-mail di invio possono essere trovati utilizzando i parametri initiatingUserId e initiatingUserEmail nel payload di notifica.
|
Prima segnalazione: agosto 2025 - Aggiornato ottobre 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Per contribuire a mantenere la stabilità del sistema e migliorare le prestazioni, Acrobat Sign introdurrà una soglia di polling nel rilascio del 4 novembre 2025 (versione 16.2.1). Questa modifica limita la frequenza con cui le applicazioni client possono effettuare il polling di specifici endpoint API.
- I clienti hanno due mesi dopo il rilascio della versione 16.2.1 per implementare le modifiche di polling raccomandate nel loro codice. Durante questa finestra temporale, il sistema si limiterà a REGISTRARE gli eventi di soglia dell'intervallo di polling.
- Dopo dicembre 2025, i criteri di protezione del polling verranno impostati su APPLICA e gli errori inizieranno a essere attivati per gli utenti.
Il polling ad alta frequenza crea un carico non necessario sui sistemi backend, con conseguente degrado delle prestazioni e tempi di risposta più lenti. Gli sviluppatori API sono incoraggiati a passare ai webhook per aggiornamenti in tempo reale.
Che cosa cambia
Questo criterio di sondaggio si applica a tutti gli endpoint API GET.
Esempi di endpoint interessati
Recupero dello stato:
- GET /agreements/{agreementId) – Recupera lo stato corrente di un accordo.
- GET /agreements/{agreementId)/documents/{documentId) – Recupera il flusso file di un documento all’interno di un accordo.
Elenco:
- GET/accordi: recupera gli accordi per l’utente.
- GET/accordi/{agreementId)/eventi: recupera le informazioni degli eventi per un accordo.
Verrà applicato un limite alla frequenza con cui l’utente effettivo può eseguire la stessa chiamata API al servizio Acrobat Sign. Viene restituito un errore se la stessa chiamata viene eseguita entro l’intervallo minimo di polling dallo stesso utente effettivo.
Dettagli della politica di polling
- Intervallo minimo di polling degli oggetti (MOPI): L'MOPI predefinito varia a seconda del livello di servizio e dei tipi di applicazione:
- Applicazioni partner Acrobat Sign: L'MOPI per un'app partner è determinato dal livello dell'account dell'utente.
- Livello GLOBAL/ENTERPRISE: 3 chiamate per intervallo di un minuto
- Tutti gli altri livelli: 1 chiamata specifica per intervallo di dieci minuti
- App cliente con account Global/Enterprise: tre chiamate identiche per intervallo di un minuto.
- App cliente con account Developer: una chiamata specifica per intervallo di 10 minuti.
- Applicazioni partner Acrobat Sign: L'MOPI per un'app partner è determinato dal livello dell'account dell'utente.
- Richieste duplicate in MOPI: se lo stesso utente effettivo effettua richieste GET identiche (stesso percorso e intestazioni) più di quanto consentito dal proprio livello nel MOPI, il sistema restituirà:
- Codice di stato 304 Non Modificato alle richieste HTTP condizionali che utilizzano un ETag.
- Codice di stato 429 Troppe richieste con un retry-after per altre richieste.
- Gestione ETag: questo criterio si applica quando i valori ETag vengono forniti nell’intestazione If-None-Match per endpoint che supportano già 304 Non Modificato.
Azione necessaria
Webhook: se la tua applicazione richiede aggiornamenti quasi in tempo reale, usa i webhook invece del polling.I webhook offrono un modo più efficiente e scalabile per ricevere aggiornamenti tempestivi.
Se non è possibile implementare i webhook, le app devono implementare meccanismi di caching lato client per archiviare e riutilizzare le risposte API. Quando si riceve una risposta 304 Non modificato, è necessario utilizzare i dati memorizzati nella cache invece di effettuare un'altra chiamata API.
I clienti hanno due mesi dopo il rilascio della versione 16.2.1 per implementare le modifiche di polling raccomandate nel loro codice. Durante questo periodo, il sistema REGISTRERÀ gli eventi di soglia dell'intervallo di polling.
Dopo dicembre 2025, i criteri di protezione del polling passeranno all'APPLICAZIONE e gli errori inizieranno a essere attivati per gli utenti.
Contatta il tuo CSM se hai bisogno di assistenza o hai domande.
L’ambiente sandbox abiliterà il criterio di polling per REGISTRARE gli errori il 17 settembre 2025 e sarà impostato su ENFORCE il 25 settembre 2025.
|
Prima segnalazione: agosto 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Per supportare i requisiti FedRAMP CSP, stiamo abilitando il protocollo IPv6 nel nostro ambiente Acrobat Sign for Government :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Prima segnalazione: settembre 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
La convalida delle impostazioni della lingua è stata rafforzata durante la creazione di un accordo tramite API. Se le impostazioni locali di un accordo non sono consentite dalle politiche dell'account, l'API rifiuta la richiesta con un errore chiaro. Questo riduce le discrepanze linguistiche involontarie e mantiene le esperienze dei destinatari allineate con le impostazioni approvate.
Chi è interessato
- Account che impostano le impostazioni locali dell'accordo nelle richieste API.
- Account che limitano le impostazioni locali disponibili o non consentono modifiche alle impostazioni locali durante l'invio.
Cosa è cambiato
Quando l'impostazione DISPLAY_LOCALE_INFO_DURING_SEND è abilitata (livello GLOBAL), l'API applica:
- Le impostazioni locali dell'accordo devono essere incluse nelle AVAILABLE_LOCALES dell'Utente.
- Se ALLOW_LOCALE_SELECTION_DURING_SEND è falso, le impostazioni locali dell'accordo devono corrispondere all'AGREEMENT_LOCALE dell'Utente.
Le violazioni causano il fallimento di POST /agreements con: "Le impostazioni locali non sono valide o mancanti."
Errore comune e come risolverlo
Errore: "Le impostazioni locali non sono valide o mancanti."
- Controlla le impostazioni locali utilizzate nella richiesta API (ad esempio, en_US).
- Conferma che le impostazioni locali appaiano in AVAILABLE_LOCALES per l'Utente chiamante.
- Se ALLOW_LOCALE_SELECTION_DURING_SEND è falso, assicurati che le impostazioni locali della richiesta corrispondano ad AGREEMENT_LOCALE.
- Se è necessaria flessibilità tra le regioni, abilita la selezione delle impostazioni locali al momento dell'invio (vedi Azione richiesta).
Compatibilità con le versioni precedenti
- Prima di questa modifica, alcune richieste con impostazioni locali non corrispondenti potevano avere successo. Tali richieste ora falliscono con un errore chiaro quando le convalide non passano.
- Nessuna modifica allo schema API; il comportamento di convalida cambia solo quando DISPLAY_LOCALE_INFO_DURING_SEND è abilitato.
Azioni necessarie
Gli amministratori e gli integratori API dovrebbero fare una delle seguenti operazioni:
- Allineare le impostazioni locali nelle richieste API con AVAILABLE_LOCALES e, se ALLOW_LOCALE_SELECTION_DURING_SEND è falso, far corrispondere esattamente AGREEMENT_LOCALE
- Oppure -
- Consentire la selezione delle impostazioni locali al momento dell'invio impostando:
- ALLOW_LOCALE_SELECTION_DURING_SEND = vero
- CAN_CHANGE_UI_LOCALE = vero
|
Prima segnalazione: dicembre 2025 |
Rimosso dall'elenco corrente: febbraio 2026 |
|---|
Adobe Acrobat Sign ruoterà il certificato SSL di Adobe Acrobat Sign il 7 gennaio 2026.
Azione necessaria
- Se hai integrazioni personalizzate con Acrobat Sign che utilizzano le API REST e se una di queste integrazioni ha 'bloccato' la chiave pubblica esistente, non è richiesta alcuna altra azione.
- Se stai utilizzando i certificati SSL di Acrobat Sign per SSO, o se stai bloccando il certificato stesso (o utilizzando altri metodi), puoi trovare i nuovi certificati SSL di Acrobat Sign nei requisiti di sistema di Adobe Acrobat Sign.
- Se la configurazione SSO supporta più certificati/catene di certificati pubbliche, si possono aggiungere subito i nuovi certificati e rimuovere dalla configurazione quelli precedenti dopo la sostituzione in gennaio.
- Se il tuo SSO non supporta più certificati/catene pubblici, dovrai sincronizzare il cambio SSL con Acrobat Sign il 7 gennaio 2026.
I nuovi certificati SSL saranno primario il 7 gennaio 2026.
|
Prima segnalazione: marzo 2026 |
Attuale Rimosso dall'elenco Current: giugno 2026 |
|---|
Un’attività di manutenzione programmata del database è pianificata per l’11 aprile 2026 alle 19:30 ora del Pacifico. La finestra di manutenzione dovrebbe durare fino a 30 minuti.
Questa manutenzione interesserà tutti gli ambienti in Acrobat Sign e si applica solo agli account gestiti da Adobe (IMS). Gli account che gestiscono i propri utenti direttamente in Acrobat Sign non sono interessati.
Durante questo periodo:
- La creazione di nuovi account e il provisioning degli utenti subiranno ritardi.
- Un numero limitato di utenti potrebbe riscontrare problemi di accesso.
- Le richieste di utilizzo transazioni dell’account dalle interfacce amministrative di Adobe potrebbero non riuscire, impedendo temporaneamente l’assegnazione dei diritti.
Tutti i servizi interessati dovrebbero tornare al normale funzionamento al completamento della manutenzione.
|
Prima segnalazione: marzo 2026 |
Rimosso dall'elenco Current: giugno 2026 |
|---|
Gli ID documento restituiti dall’API ora utilizzano un formato di codifica a 16 bit invece del precedente formato di codifica a 12 bit e potrebbero includere caratteri asterisco finali come parte del valore restituito. Acrobat Sign accetta ID documento con o senza questi caratteri finali, ma alcune applicazioni potrebbero non gestire correttamente il formato espanso, il che può influire sul recupero o sulla visualizzazione del documento.
Questo aggiornamento riflette una modifica nella gestione degli ID documento nel servizio. Se la tua integrazione recupera documenti utilizzando ID documento restituiti dall’API, rivedi la logica attuale per assicurarti che supporti il formato ID più lungo e possa accettare il valore restituito come fornito. Se necessario, i caratteri asterisco finali possono essere omessi prima di riprovare la richiesta.
L’accesso diretto tramite Acrobat Sign non dovrebbe esserne influenzato.
|
Prima segnalazione: febbraio 2026 - Aggiornamento: aprile 2026 |
Rimosso dall'elenco Current: giugno 2026 |
|---|
La pagina Home di Acrobat Sign viene riprogettata per rendere più semplice l’avvio degli accordi, il monitoraggio delle attività e l’accesso alle funzioni chiave, inclusa la possibilità di copiare gli accordi inviati di recente, visualizzare i riquadri di azione in un ordine più intuitivo, identificare rapidamente gli elementi In corso e In attesa del tuo intervento e usufruire di un banner Novità semplificato che riduce la dispersione visiva, aiutando gli utenti a spostarsi più velocemente, ridurre gli accordi mancati e navigare in un’esperienza Home più mirata.
La nuova pagina Home sarà resa disponibile nei 10 giorni successivi al rilascio:
Data |
Frammenti |
5 maggio 2026 |
IN1, JP1, AU1, SG1 |
11 maggio 2026 |
EU1, EU2, NA4 |
14 maggio 2026 |
NA1, NA2, NA3 |
Nota
La pianificazione del rollout viene fornita come linea guida e può subire delle modifiche man mano che procede.
|
Prima segnalazione: marzo 2026 |
Rimosso dall'elenco Current: giugno 2026 |
|---|
A partire dalla versione 17.0.1 del 17 marzo, la scheda Token di accesso nel menu Preferenze personali visualizza la data di scadenza per ogni chiave di integrazione. Questo aggiornamento migliora la visibilità nella gestione del ciclo di vita delle chiavi consentendo ai possessori delle chiavi di vedere quando una chiave scadrà.
Le chiavi di integrazione hanno un periodo di validità di 10 anni. Dopo la data di scadenza, la chiave non può più essere utilizzata e deve essere sostituita con una nuova chiave.
Questa modifica non influisce sul funzionamento delle chiavi esistenti e non modifica il ciclo di vita della chiave. Espone solo la data di scadenza nell’interfaccia in modo che gli amministratori possano monitorare la durata delle chiavi e pianificare le sostituzioni in anticipo.
Non è richiesto alcun intervento. Gli amministratori dovrebbero rivedere periodicamente le loro chiavi di integrazione e sostituire quelle che si avvicinano alla scadenza per evitare interruzioni del servizio.
|
Prima segnalazione: marzo 2026 |
Rimosso dall'elenco Current: giugno 2026 |
|---|
A partire dalla versione del 5 maggio 2026, i report di audit registreranno il metodo di firma utilizzato quando un firmatario applica la propria firma.
Per ogni evento ESIGNED e DIGSIGNED, l’audit trail identifica se il firmatario ha utilizzato un metodo di firma basato su desktop (DIGITATO, DISEGNATO, IMMAGINE) o un metodo di firma basato su dispositivo mobile (MOBILE_TYPE, MOBILE_DRAW, MOBILE_IMAGE).
Questo aggiornamento migliora la visibilità della conformità consentendo agli amministratori e ai team di conformità di verificare il metodo di firma direttamente nel rapporto di audit, riducendo l’ambiguità e minimizzando i rifiuti non necessari degli accordi durante i processi di revisione e audit. Questo aggiornamento è abilitato per impostazione predefinita per tutti i clienti, senza opzione di configurazione.
Nota
L’applicazione di una firma solo con un timbro non è inclusa nei tipi di firme identificate.
|
Prima segnalazione: dicembre 2025 - Aggiornamento: febbraio 2026 |
Rimosso dall'elenco Current: giugno 2026 |
|---|
L’esperienza della pagina di accesso di Acrobat Sign viene aggiornata per tutti gli utenti come parte della versione 17.0, pianificata per il 3 febbraio 2026. - Il nuovo processo di accesso offre un’esperienza più pulita e coerente richiedendo a tutti gli utenti di fornire solo il proprio indirizzo e-mail. Non appena l’indirizzo e-mail viene accettato, viene fatto riferimento all’account dell’utente e la pagina di follow-up visualizza le opzioni di autenticazione configurate per tale account, eliminando passaggi non necessari e schermate legacy. Questo rende l’accesso più veloce, semplice e intuitivo per tutti.
- Come parte della nuova esperienza di accesso, il formato e-mail per gli utenti Acrobat Sign Enterprise che accedono direttamente all’interfaccia web ora applica un limite di 64 caratteri alla parte locale di un indirizzo e-mail (quella che precede il simbolo “@”).
Questa esperienza di accesso aggiornata viene implementata per fasi nell’ambiente Server di Acrobat Sign. La pianificazione del rollout è mostrata di seguito:
|
Ambiente Acrobat Sign |
Data di rollout |
|
IN1 (India) SG1 (Singapore) |
3 febbraio 2026 |
|
AU1 (Australia) NA3 (Nord America) |
10 febbraio 2026 |
|
JP1 (Giappone) |
17 febbraio 2026 |
|
EU2 (Europa) NA4 (Nord America) |
2 marzo 2026 |
|
EU1 (Europa) NA2 (Nord America) |
5 marzo 2026 |
|
NA1 (Nord America) |
10 marzo 2026 |
Nota
La pianificazione del rollout viene fornita come linea guida e può subire delle modifiche man mano che procede.
|
Prima segnalazione: febbraio 2026 |
Rimosso dall'elenco «Current»: giugno 2026 |
|---|
