Chiave del problema
Ultimo aggiornamento il
2 apr 2026
Note sulla versione di Adobe Sign: 2021
Adobe Sign: marzo 2021
Funzionalità migliorate
Moduli web con più firmatari
Gli account che utilizzano moduli web ora hanno la possibilità di consentire più destinatari esterni nel processo di firma.
I destinatari aggiuntivi vengono definiti dal firmatario iniziale:
Usa modelli di libreria per creare moduli web
Gli autori ora possono utilizzare modelli di libreria esistenti per creare nuovi moduli web.Il file viene importato con tutti i campi intatti:
"Liquid Mode" in Adobe Sign per la visualizzazione mobile
Liquid Mode è una funzionalità opzionale per la generazione di una visualizzazione reattiva che consente di migliorare la visualizzazione dei documenti in base al tipo di dispositivo del firmatario.
Il documento firmato viene archiviato nella versione PDF standard mentre i destinatari possono visualizzare Liquid Mode sui dispositivi mobili e passare alla visualizzazione del documento originale.
Ora puoi caricare il tuo documento HTML e generare una visualizzazione Liquid Mode per i telefoni cellulari.
Maggiori dettagli sull'opzione Liquid Mode sono disponibili qui >
Blocca il valore Nome per gli utenti noti durante la firma tramite i metodi di firma immagine o disegnata
In alcune situazioni può essere preferibile impedire che il nome del destinatario possa essere modificato all’atto della firma. Adobe Sign offre flessibilità in tal senso, rispettando la preferenza per il nome del firmatario. In ambienti soggetti a norme di conformità, questa flessibilità è inaccettabile e pertanto è stato introdotto un nuovo controllo che consente di bloccare i nomi dei destinatari dell’accordo.
Gli amministratori ora hanno la possibilità di impedire ai destinatari con valori Nome noti di cambiare tali valori quando applicano una firma disegnata o immagine.
Situazioni in cui il valore del nome è noto:
- Quando il destinatario ha un Adobe Sign ID
- Quando il nome viene inviato tramite API
- Quando i campi Informazioni firmatario vengono completati durante la compilazione del modulo
- Quando il nome viene bloccato durante il completamento di un'autenticazione KBA o documento di identità
Maggiori dettagli su questa funzionalità sono disponibili qui >
Miglioramenti all'autenticazione basata sulla conoscenza
Sono stati aggiunti controlli al metodo KBA di autenticazione dell'identità che possono richiedere al mittente di fornire un Nome per il destinatario e tale valore Nome rimane bloccato durante il processo di firma.
Opzioni per la sicurezza avanzata delle e-mail
Sono disponibili due nuove opzioni per migliorare la sicurezza e-mail. Entrambe le impostazioni sono attivate per impostazione predefinita:
- Includi un collegamento nelle e-mail per visualizzare l’accordo firmato
- Includi nelle e-mail un’immagine della prima pagina dell’accordo
- Opzione abilitata per impostazione predefinita
- Quando abilitata, un'immagine della prima pagina del contratto è visibile in alcune distribuzioni e-mail
Aggiornamenti API REST v6
Intestazioni standard in ogni richiesta API REST V6
Per impostazione predefinita, in ogni richiesta API REST v6 ora sono presenti le seguenti intestazioni standard:
/AGREEMENTS
Tutti gli endpoint /agreements che hanno un agreement id path ora restituiscono un codice di errore 404 AGREEMENT_DESTROYED se l'accordo è stato eliminato tramite Strumenti GDPR.
MODELLI DI LIBRERIA
PUT /libraryDocuments/{libraryDocumentId} - Ampliato per includere il nuovo campo ownerId
Nota
Queste modifiche interessano solo l’API REST v6.
Qualsiasi chiamata API REST v6 che non include queste intestazioni documenterà esplicitamente tale assenza.
- GET /libraryDocuments - Ampliato per includere il nuovo campo ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Ampliato per includere i nuovi campi: ownerId, ownerEmail, e ownerName
Nuovi campi nell'oggetto LibraryDocumentInfo:
Campi con comportamento aggiornato:
MODULI WEB (/WIDGETS)
- POST /widgets - L'utilizzo di un libraryDocumentId per creare un modulo web è ora supportato con un id valido
Codice di stato aggiunto:
- PUT /widgets - L'utilizzo di un libraryDocumentId per creare moduli web è ora supportato con un id valido
Codice di stato aggiunto:
- PUT /widgets/{widgetId} - Ampliato per includere il nuovo campo ownerId
Codice di stato aggiunto:
Modifiche a livello di esperienza
- GET /widgets/{widgetId} - Ampliato per includere i nuovi campi: ownerId, ownerEmail, ownerName e creatorName
Nuovi campi nell'oggetto WidgetInfo:
Campi con comportamento aggiornato:
/MEGA SIGN
NUOVO:
- GET /megaSigns/{megaSignId}/formFields - Recupera i dettagli dei campi del modulo di un contratto principale Mega Sign
Parametri:
Oggetto risposta:
- PUT /megaSigns/{megaSignId}/formFields - Aggiorna i campi del modulo di un contratto Mega Sign
Parametri:
Oggetto risposta:
AGGIORNATO:
- POST /megaSigns - AUTHORING è stato aggiunto come valore di stato per supportare la creazione di un modello Mega Sign
Parametro modificato:
- PUT /megaSigns/{megaSignId}/state - AUTHORING è stato aggiunto come valore di stato per supportare la creazione di un modello Mega Sign.Di conseguenza, megaSignCancellationInfo non è più un campo obbligatorio
Le nuove pagine Home e Gestisci sono state abilitate per tutti gli account rimanenti
Tutti gli account hanno avuto i controlli aggiornati per abilitare le pagine moderne Home e gestire per i loro utenti.
I controlli nel menu amministratore rimangono disponibili per gli account che devono tornare all'esperienza classica:
Livello di servizio Adobe Sign e ID account esposti nel menu Amministratore
Gli amministratori ora possono trovare il proprio Account ID nella pagina Impostazioni globali:
L'ID del gruppo è reperibile nella pagina Impostazioni del gruppo:
Configurazione HIPAA esplicita
È disponibile una nuova pagina che mostra chiaramente quando l’account è abilitato per la gestione di accordi soggetti ai requisiti HIPAA
- Questo controllo è visibile solo a livello di account Gli amministratori a livello di gruppo non hanno accesso
- Questo controllo è di sola visualizzazione, per indicare chiaramente quando l'account è configurato
- Contatta il tuo Success Manager o il supporto per abilitare la configurazione HIPAA
Ulteriori informazioni sulle impostazioni HIPAA sono disponibili qui >
Il pulsante "Invito all'azione" è cambiato per i clienti che utilizzano l'applicazione desktop Outlook sui sistemi Windows
I destinatari che utilizzano un client e-mail Outlook Desktop riscontreranno una modifica nel pulsante di “Invito all’azione” nelle e-mail di Adobe Sign.
La nuova esperienza rimuove il pulsante HTML blu e fornisce invece un collegamento testuale cliccabile:
Nota
Questo cambiamento interessa solo le app desktop di Outlook sui sistemi Windows.Altri client di posta elettronica e sistemi operativi continueranno a ricevere il modello con il pulsante blu.
Delega di accordi con firme digitali
La possibilità di delegare un accordo con firme digitali apposte è stata migliorata per consentire la delega dalla notifica e-mail originale al destinatario, tramite delega automatica quando configurata da un utente e tramite l'azione Sostituisci firmatario corrente nella pagina Gestisci.
Interfaccia aggiornata per l'integrazione dei pagamenti
L'interfaccia Pagamenti è stata aggiornata per esporre meglio i controlli di autenticazione, creando un processo di configurazione più semplice.
Il valore massimo per la governance dei dati è stato aumentato a 5475 giorni (15 anni)
I clienti che utilizzano regole di governance dei dati per eliminare automaticamente gli accordi dal sistema Adobe Sign ora possono impostare quella data di eliminazione a un massimo di 15 anni (rispetto ai dieci precedenti).
L'etichetta di testo a livello di campo per la convalida del numero di previdenza sociale statunitense è stata aggiornata:
L'etichetta di testo a livello di campo per la convalida del numero di previdenza sociale statunitense è stata aggiornata per chiarire che l'SSN è specifico degli Stati Uniti:
Promemoria: l'autenticazione sociale è stata rimossa
Come annunciato a novembre, il metodo di autenticazione tramite identità sociale è stato rimosso dall'elenco dei metodi di autenticazione nel menu Amministratore.
Promemoria: l'integrazione Twitter personale è stata rimossa
Come annunciato a dicembre, la funzionalità che consente agli utenti di effettuare connessioni autenticate personali a Twitter è stata rimossa.
Gli utenti inattivi riceveranno una notifica e-mail quando verranno inclusi in un accordo
Gli utenti che sono impostati su uno stato inattivo ora ricevono una notifica e-mail che indica al destinatario di delegare l'accordo a un altro utente.
Problemi risolti
Adobe Sign: maggio 2021
Funzionalità migliorate
Trasferire la proprietà dei modelli libreria e dei moduli web a un nuovo utente
La modifica del proprietario di una risorsa può essere effettuata da qualsiasi amministratore dell’account che ha accesso alla risorsa.
L'amministratore può assegnare la proprietà della risorsa a qualsiasi utente sotto la propria autorità.
- Gli amministratori di account hanno accesso a tutte le risorse condivise e a tutti gli utenti. Pertanto, gli amministratori a livello di account possono riassegnare la proprietà di qualsiasi modello libreria o modulo web a qualsiasi altro utente nel proprio account.
- Se la risorsa è configurata per essere disponibile solo per un utente (il proprietario), significa che non è condivisa e quindi non può essere riassegnata a un nuovo proprietario.
- Gli amministratori dei gruppi possono accedere solo ai modelli libreria e ai moduli web dei gruppi di cui sono amministratori.
- Gli amministratori di gruppo possono solo riassegnare una risorsa a un utente il cui gruppo primario rientra nella loro autorità amministrativa
Endpoint API aggiornati per il trasferimento di risorse
Gli endpoint descritti di seguito sono disponibili solo nell’API REST v6.
Esteso per supportare l’aggiornamento del proprietario del documento libreria.
LibraryDocumentInfo:
Codici di stato e di errore aggiuntivi:
Esteso per supportare l’aggiornamento del proprietario del widget.
WidgetInfo:
Codici di stato e di errore aggiuntivi:
Nuovi campi nell’oggetto LibraryDocument:
Nuovi campi nell'oggetto LibraryDocumentInfo:
Campi con comportamento aggiornato:
Nuovi campi nell'oggetto WidgetInfo:
Campi con comportamento aggiornato:
Modifiche a livello di esperienza
Il valore di ritorno predefinito v6 REST GET /workflows{workflowId} è cambiato
La chiamata API v6 REST GET /workflows{workflowId} è stata aggiornata per restituire la versione corrente del WorkflowID (rispetto all'ID della versione originale, che era il valore restituito prima del rilascio di maggio)
Questo aggiornamento allinea l'esperienza API predefinita con l'esperienza Webhook, fornendo lo stesso WorkflowID, che dovrebbe migliorare lo sviluppo e la gestione delle applicazioni.
Se, per qualsiasi motivo, il tuo account richiede che l'API restituisca l'ID originale (come faceva prima del rilascio di maggio), contatta il supporto per richiedere che il tuo account restituisca gli ID della versione base per i flussi di lavoro
Problemi risolti
Adobe Sign: giugno 2021
Utenti in più gruppi
Gli amministratori di gruppi di più account ora possono ora concedere agli utenti del proprio account l’accesso a più gruppi: possono aprire l’opzione per utilizzare i gruppi come modello di flusso di lavoro, quindi applicare specifici controlli di invio e firma per i modelli libreria disponibili per il gruppo.
Gli account Enterprice e Business esistenti che desiderano eseguire l’aggiornamento possono rivedere il processo di aggiornamento qui >
Una sintesi delle differenze che possono avere un impatto è disponibile qui >
Nuova modalità Liquid Mode in Sign
È possibile attivare la vista Liquid Mode per la visualizzazione su smartphone dei contenuti HTML inviati tramite la pagina Invia o l’API sendAgreement. L’opzione per abilitare Liquid Mode in Sign per la visualizzazione dei contenuti HTML è ora disponibile nell’elenco dei menu Amministrazione a livello di account e di gruppo.
Informazioni dettagliate sui documenti in modalità Liquid Mode >
Nota
La modalità Liquid Mode è attualmente disponibile solo negli ambienti NA1, NA2 e NA4.
Aggiornamenti diretti dei moduli web
I moduli Web in stato Bozza possono essere modificati per cambiare:
- il nome del modulo Web;
- Aggiungere l’indirizzo e-mail di uno o più controfirmatari
- l'indirizzo e-mail delle parti in copia per conoscenza
- i file allegati da modificare;
- i campi nel modulo Web (precedentemente disponibili).
L’aggiornamento di un modulo Web Attivo consente di modificare gli elementi del modulo senza cambiare l’URL originale e offre un processo fluido qualora sia necessario aggiornare il contenuto di un modulo Web incorporato o inviato al pubblico. Gli elementi che possono essere modificati sono:
- i file (documenti) e i campi applicati per i destinatari;
- controfirmatari (dalla pagina Gestisci);
- parti in Cc (dalla pagina Gestisci).
Nota
Per abilitare la funzionalità diretta per modulo web, è necessario abilitare l’opzione Consenti partecipanti aggiuntivi nel menu Impostazioni globali:
Timbro di partecipazione: controllare la visualizzazione del titolo e dell’azienda
Sono stati aggiunti dei controlli che consentono di includere o meno nel campo del timbro del partecipante i valori Titolo e Azienda del destinatario (derivati dal profilo utente).
Ulteriori dettagli sono disponibili nella pagina sui tipi di campo >
Opzioni di ricerca migliorate: corrispondenze per prefisso e frase
Sono state introdotte opzioni di ricerca avanzate per consentire pattern di ricerca più specifici e ottenere quindi risultati più mirati.
Ulteriori dettagli sulla funzione di ricerca in Adobe Sign >
OAuth 2.0 è la nuova specifica predefinita
È stata aggiunta una nuova versione (migliorata) dell’endpoint OAuth per evitare errori di utilizzo. Con questa versione:
- api_access_point / web_access_point restituisce solo nella richiesta di token di accesso (nel corpo).
- Adobe Sign non accetta il segreto come parametro di query.
- È supportata la rotazione del segreto client
Nei prossimi mesi, l’endpoint OAuth v1 continuerà a funzionare per le connessioni esistenti al fine di garantire l’accesso continuo.
La deprecazione di OAuth v1 verrà annunciata sulla pagina delle notifiche tecniche una volta programmata.
Rotazione segreto client
I segreti client dell’applicazione possono essere ruotati da un amministratore che disponga dell’accesso all’ID applicazione nell’interfaccia utente di Adobe Sign:
Modifiche a livello di esperienza
Gli amministratori dei gruppi possono visualizzare solo le applicazioni API che rientrano nella proprio ambito di amministrazione
La visibilità delle applicazioni associate all’account è ora limitata per mostrare solo le applicazioni che rientrano nell’ambito di amministrazione dell’utente. Questa modifica interessa solo gli amministratori dei gruppi.
- Gli utenti vedono le applicazioni di loro proprietà.
- Gli amministratori dei gruppi visualizzano le app nei gruppi che sono autorizzati ad amministrare.
- Gli amministratori degli account vedono tutte le applicazioni dell’account.
Aggiornamento dell’e-mail inviata al mittente al completamento di un accordo
La notifica e-mail finale per un accordo che viene inviata al mittente è stata aggiornata per fornire un elenco completo di tutte le parti a cui è stato notificato l’accordo completato.
Solo il mittente originale riceverà questo modello e-mail.
Risultato API REST v6 aggiornato per GET /agreements/{agreementId}/signingUrls
Prima della versione di giugno, quando si chiamava GET /agreements/{agreementId}/signingUrls, l’API restituiva un errore 404 subito dopo la creazione dell’accordo.
Per un breve periodo di tempo, dopo che l’errore 404 era stato cancellato, la richiesta restituiva una risposta diversa da 404, ma includeva solo gli URL di firma del mittente (mentre la partecipazione del firmatario era ancora in corso di definizione).
Con la versione di giugno 2021, un errore con codice 404: AGREEMENT_NOT_EXPOSED verrà restituito fino al completamento dell’elenco degli URL di firma, e a quel punto verrà distribuito un codice 200.
I clienti che non desiderano continuare a provare la chiamata API finché non viene restituita la risposta 200, sono invitati a utilizzare i webhook e a rispondere all’evento AGREEMENT_CREATED.
Problemi risolti
Adobe Sign: agosto 2021
Modifica a livello di esperienza
- Supporto internazionale Aadhaar: i clienti di tutte le istanze Adobe Sign possono ora utilizzare il servizio opzionale Aadhaar come provider di firma digitale. In precedenza il servizio era disponibile solo per gli account nell’istanza IN1. Il componente Aadhaar può essere acquistato a un costo aggiuntivo per ogni transazione di firma.
- Aggiornamento REST v6: POST /users: la chiamata API REST v6 POST /users è stata aggiornata per creare l’utente nel gruppo Default dell’account se non viene definito il parametro opzionale primaryGroupId. Questa modifica interessa solo la v6 dell’API REST.
Problemi risolti
|
|
Descrizione |
|---|---|
|
4299495 |
Risolto un problema nel progettista del flusso di lavoro che impediva il funzionamento di un URL definito dal cliente nelle istruzioni. |
|
4308294 |
Risolto un problema nel file CSV del rapporto in cui i campi To e Nome destinatario potevano rimanere vuoti quando lo stesso indirizzo e-mail del destinatario veniva utilizzato più di una volta nell'accordo. |
|
4310569 |
I modelli di Adobe Sign sono stati esclusi dalle opzioni sandbox. |
|
4311098 |
Risolto un problema per cui gli amministratori di gruppo non potevano aggiornare gli utenti in un gruppo tramite caricamento CSV. |
|
4311723 |
Risolto un problema per cui la chiamata API GET /groups/ID/users non riusciva se l'utente si trovava su un'istanza Adobe Sign diversa. |
|
4312103 |
Risolto un problema per cui gli utenti SAML creati tramite caricamento in blocco si trovavano in stato Creato (anziché Attivo). |
|
4312309 |
Risolto un problema per cui gli amministratori di gruppo non potevano riassegnare la proprietà dei moduli web se venivano creati da altri utenti del loro gruppo. |
|
4312840 |
Risolto un problema con l'attivazione di nuovi utenti quando veniva inviata una seconda e-mail di attivazione al nuovo utente e veniva utilizzato il collegamento della seconda e-mail. |
|
4314751 |
Risolto un problema per cui l'opzione per rifiutare l'accordo non era visibile quando si firmava per conto di un altro utente. |
|
4315033 |
Risolto un problema per cui gli amministratori account non potevano reimpostare la password quando la modalità SAML era impostata su Obbligatoria. |
|
4315605 |
Risolto un problema per cui le immagini del documento di identità non venivano elaborate correttamente. |
|
4316057 |
Risolto un problema per cui il documento di identità produceva un errore indicando che non era possibile trovare i quattro angoli del documento. |
|
4316474 |
Risolto un problema per cui l'opzione Firma per conto di era visibile negli account in cui l'opzione non era abilitata. |
|
4316659 |
È stato risolto un problema a causa del quale l’indirizzo e-mail per “actingUserEmail” in una chiamata GET /agreements/id restituiva un’e-mail generata dal sistema dopo la firma completa dell’accordo. |
|
4317095 |
Risolto un problema per cui il nome di un destinatario veniva importato nell'etichetta Partecipante 1 quando l'autenticazione basata sulla conoscenza veniva utilizzata per il primo firmatario. |
|
4317221 |
Risolto un problema per cui le e-mail di notifica automatiche per webhook non riusciti venivano inviate al creatore del webhook nonostante la configurazione prevedesse di non notificare il creatore. |
|
4317347 |
Risolto un problema per cui l'autenticazione di OAuth in Power Automate reindirizzava l'utente alla pagina Home. |
|
4317429 |
Risolto un problema per cui gli amministratori non potevano aggiornare la proprietà Può inviare per gli utenti durante l'aggiornamento tramite caricamento CSV. |
|
4317548 |
Risolto un problema per cui alcuni clienti che utilizzavano l'iPad vedevano la pagina web anziché la pagina ottimizzata per dispositivi mobili. |
|
4317629 |
Risolto un problema di visualizzazione dei nomi contenenti un apostrofo che mostravano il codice HTML dell'apostrofo. |
|
4318175 |
È stato corretto un problema a causa del quale gli utenti ricevevano un errore durante l’archiviazione di un account tramite il collegamento e-mail. |
|
4319012 |
È stato risolto un problema a causa del quale gli utenti creati tramite il POST /users REST v5 e v6 non venivano creati nel gruppo predefinito. |
|
4320197 |
Risolto un problema per cui il Rapporto di identità del firmatario non poteva essere scaricato dalla pagina Gestire a causa del pulsante inattivo. |
Adobe Sign: settembre 2021
Funzionalità migliorate
- Sandbox: i clienti di livello Enterprise hanno la possibilità di acquistare l'accesso a un ambiente sandbox per testare modelli, flussi di lavoro dei clienti, applicazioni API e altro ancora. Questi oggetti possono essere spostati dalla produzione alla sandbox per eseguire aggiornamenti in un ambiente sicuro, quindi, con gli aggiornamenti verificati e pronti per la distribuzione, possono essere trasferiti nuovamente alla produzione.
- Supporto per firme digitali ECDSA - Adobe Sign ora supporta firme digitali più sicure ed efficienti basate sul formato ECDSA, che utilizza la crittografia a curva ellittica come definito nello standard ANS X9.62-2005.
Ora sono supportate le curve NIST con funzioni hash SHA-2, definite dagli standard FIPS, che offrono ai nostri partner Trust Service Provider (TSP) del Cloud Signature Consortium la possibilità di fornire ai firmatari credenziali a curva ellittica più veloci e sicure, comprese quelle che soddisfano i requisiti consigliati per l’uso da parte del governo federale degli Stati Uniti e di Singapore.
- Aggiornamento di Liquid Mode: l’esperienza di firma in modalità Liquid Mode è stata estesa oltre gli accordi, per includere anche i moduli web. La modalità Liquid Mode può migliorare notevolmente l’esperienza del firmatario: riduce infatti la necessità di pizzicare e ingrandire per visualizzare il contenuto del modulo e facilita l’attivazione dei campi da compilare.
Inoltre, la modalità Liquid non è più limitata agli shard nordamericani.Tutti gli account Enterprise e Aziende ora hanno accesso indipendentemente dalla posizione.
- Nuovi TSP: Cleverbase (Paesi Bassi), PrimeSign (Austria), Sectigo (globale) e TrustPro (Irlanda) sono i nuovi fornitori Trust Service Provider del Cloud Signature Consortium che forniscono certificati per applicare firme digitali sicure che soddisfano i più elevati standard e requisiti di conformità.
- Personalizza i campi A e CC nelle intestazioni e-mail ai destinatari - I clienti preoccupati per la divulgazione degli indirizzi e-mail tramite le intestazioni e-mail ai destinatari possono scegliere di nascondere i valori degli indirizzi e-mail nei campi A e CC.
- Questa opzione è disponibile per gli account di livello Enterprise e Business e può essere configurata a livello di account e gruppo.
- È possibile accedere ai controlli della funzionalità navigando su Impostazioni account > Impostazioni e-mail > Personalizza campi A e CC.
Modifiche a livello di esperienza
- Accettazione delle Condizioni d'uso Adobe nelle pagine di firma elettronica - Per rispettare i requisiti legali di Adobe, Adobe Sign sta aggiornando il comportamento di accettazione delle Condizioni d'uso (ToU) nella pagina di firma elettronica. Con la nuova esperienza, tutti i destinatari «sconosciuti» devono accettare le Condizioni d'uso di Adobe Sign e l'Informativa sulla privacy (facendo clic sul pulsante Continua ) prima di interagire con l'accordo.Questa accettazione è distinta da qualsiasi ToU personalizzata che l'account cliente potrebbe aver configurato, che continuerà a essere risolta secondo la configurazione di accettazione TOU/CD dell'account.
- Un destinatario "sconosciuto" è qualsiasi indirizzo e-mail che non sia un'e-mail utente registrata e attiva in un account attendibile.
- Gli utenti “noti”, invece, hanno già accettato le condizioni di utilizzo di Adobe Sign durante il processo di registrazione, al momento della verifica del proprio account utente, e pertanto non viene richiesto loro di accettarlo di nuovo.
Di seguito è riportato un esempio del flusso di consenso implicito per un accordo con Condizioni d’uso personalizzate configurate dal cliente:
- Accetta le Condizioni d’uso di Adobe Sign selezionando il pulsante Continua (dopo aver aperto l’accordo).
- Compila i campi dell’accordo in base alle esigenze.
- Accetta l'Informativa al cliente e le Condizioni d'uso personalizzate selezionando il pulsante Fai clic per firmare.
- Blocco dei valori dei nomi applicabile anche alle firme digitate - Con la versione di marzo è stata introdotta un’impostazione con cui consentire o impedire a un destinatario la possibilità di modificare il valore del proprio nome durante la firma, a condizione che il nome sia stato fornito o sia noto (tramite API o profilo utente). Le firme digitate erano escluse da questa funzionalità, e alcuni firmatari potevano quindi modificare il valore del proprio nome durante il processo di firma. Con la versione di settembre, questa funzionalità è stata aggiornata affinché l’impostazione di blocco del nome venga rispettata per tutti i tipi di firma, incluse quelle digitate.
- I clienti che hanno abilitato Digitare nome e iniziali e disabilitato I firmatari possono cambiare nome o iniziali vedranno un cambio di comportamento: il valore del nome non è più modificabile durante il processo di firma per le firme digitate.
- Per offrire ai firmatari la possibilità di modificare il valore del nome durante il processo di firma, è necessario abilitare l’impostazione I firmatari possono modificare il nome o le iniziali (nel menu Preferenze firma).
- Gli utenti inattivi possono firmare accordi - Adobe Sign adesso tratta gli utenti inattivi come se fossero sconosciuti al sistema (per firmare accordi in entrata). Quando viene richiesto a un utente Inattivo di firmare un contratto, viene creato un nuovo ID utente monouso per la firma di quel singolo contratto. L’ID utente monouso è indipendente dall’ID utente inattivo e dall’account che lo gestisce. Ciò comporta varie implicazioni:
- Gli accordi inviati a un utente Inattivo possono essere firmati, poiché lo stato Inattivo non interessa gli ID utente monouso generati per tali accordi.
- Gli accordi firmati con l’ID utente monouso non sono considerati asset dell’ID utente inattivo e non risiedono nell’account di quest’ultimo.
- Le condivisioni dall’ID utente inattivo non includono gli accordi firmati con l’ID utente monouso.
- I rapporti creati per l’ID utente inattivo non considerano gli accordi firmati con l’ID utente monouso.
- Se l’ID utente inattivo viene riattivato, nella pagina Gestisci non saranno visibili i record degli accordi firmati con un ID utente monouso.
Sono previste due eccezioni al comportamento di cui sopra:
- Non è possibile firmare gli accordi che erano stati inviati all’utente prima questi fosse contrassegnato come inattivo (l’accordo era già associato all’ID utente inattivo).
- Gli utenti configurati esplicitamente per non essere autorizzati a firmare accordi continueranno a non essere autorizzati ad alcuna azione di firma.
Gli utenti inattivi continuano a non poter accedere al sistema Adobe Sign né a inviare accordi sotto la loro autorità (con qualsiasi metodo).
- Maggiore sicurezza per l’accesso ai moduli web tramite password: i moduli web prevedono un ritardo in seguito a diversi tentativi non riusciti di accedere a un URL protetto da password.
- Supporto internazionale Aadhaar: i clienti di tutte le istanze Adobe Sign ora possono utilizzare il servizio opzionale Aadhaar come provider di firma digitale. In precedenza il servizio era disponibile solo per gli account nell'istanza IN1. Il componente Aadhaar può essere acquistato a un costo aggiuntivo per ogni transazione di firma.
- Condivisione limitata degli accordi - La condivisione degli accordi è stata limitata quando si condivide l'accordo a un indirizzo e-mail esterno.
- Gli account con più licenze possono condividere un accordo fino a dieci volte.
- Gli account individuali possono condividere un accordo fino a 5 volte.
- La condivisione di un accordo con utenti interni è illimitata.
- Gli account con più licenze possono condividere un accordo fino a dieci volte.
- Il nome azienda personalizzato in Autenticazione telefonica è stato rimosso dal servizio: il valore del nome dell'azienda personalizzabile che poteva essere inserito nel metodo di Autenticazione telefonica è stato rimosso dal servizio come annunciato nella Notifica tecnica di giugno.
- Gli account abilitati per HIPAA ora possono accedere ai controlli per le immagini e i collegamenti nei messaggi e-mail dei destinatari, nella pagina delle impostazioni globali/del gruppo.
- L'ordine in cui gli Allegati sono inclusi nel PDF finale è stato aggiornato per ordinare prima per numero di pagina, e poi per posizione del campo (quando si legge da sinistra a destra; dall'alto verso il basso)
- La funzionalità Sostituisci destinatario nella nuova pagina Gestisci consente ora al mittente di includere un messaggio facoltativo per il nuovo destinatario.
Ulteriori dettagli sulla funzione Sostituisci destinatario >
- Ai firmatari esterni che accedono agli accordi completati devono superare un processo di autenticazione, se per l’accordo in questione è stata configurata l’autenticazione a più fattori (non viene più chiesto di accedere ad Adobe Sign).
- I moduli Web ora segnalano i valori dei campi dei moduli Web non verificati quando si accede ai dati dei campi utilizzando la funzione Scarica dati per campo modulo nella pagina Gestisci.
Aggiornamenti per le API
- Opzione di lettura dell'accordo per i moduli web: sono disponibili due nuove chiamate API REST v6 per consentire l'accesso alla visualizzazione dei moduli web:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} restituisce ora il ruolo del partecipante nella risposta.
Problemi risolti
| 4292343 | Maggiore chiarezza della firma quando si utilizza l’opzione firma DIGITA sui dispositivi mobili. |
| 4295123 | È stato risolto un problema che poteva impedire la visualizzazione delle firme digitali all’apertura in un browser. |
| 4299289 | È stata migliorata l’esperienza Sostituisci destinatario consentendo al mittente di includere un messaggio per il nuovo destinatario. |
| 4299857 | È stato risolto un problema che poteva causare la mancata applicazione del sigillo del certificato in un accordo firmato. |
| 4304261 | È stato risolto un problema a causa del quale poteva verificarsi la mancata presenza dell’opzione Leggi accordo nel menu Opzioni. |
| 4308516 | È stato risolto un problema a causa del quale agli utenti veniva richiesto di ottenere il consenso dell’amministratore per l’utilizzo di OneDrive. |
| 4310225 | È stato risolto un problema relativo agli accordi contenenti più firme che potevano innescare un errore del server. Messaggio di errore: “La firma applicata al documento non è valida. Cancellala e firma di nuovo.” |
| 4310416 | È stata aggiornata l’API REST v5 per creare utenti in uno stato attivo durante la creazione tramite POST /users. |
| 4311287 | È stato risolto un problema a causa del quale, dopo la rimozione di un utente da un gruppo, il pulsante di navigazione Gruppo scompariva negli account in cui è abilitata la funzione Utenti in più gruppi. |
| 4311956 | È stato risolto un problema a causa del quale la dimensione del font designata per un campo non veniva mantenuta nell’esperienza del firmatario. |
| 4312302 | È stato risolto un problema a causa del quale veniva rimossa l’opzione Reimposta password se la modalità SAML era impostata su Obbligatorio. |
| 4312735 | È stato risolto un problema che causava il recapito delle notifiche degli eventi condivisi anche se tali notifiche erano state disabilitate. |
| 4313025 | È stato risolto un problema a causa del quale un utente con ruolo Compilatore non poteva compilare i campi non assegnati se era stato abilitato l’indirizzamento ibrido. |
| 4313030 | È stato risolto un problema a causa del quale, per gli account per i quali è abilitata la funzione Utenti in più gruppi, si poteva verificare un errore se si utilizzava un flusso di lavoro personalizzato e il gruppo primario del mittente non era autorizzato all’invio. |
| 4313264 | È stata aggiornata l’impostazione per HIPAA in modo da consentire l’accesso alle impostazioni per collegamento e immagine nell’e-mail, nella pagina Impostazioni globali. |
| 4315839 | È stato corretto un problema relativo ai flussi di lavoro personalizzati che non consentiva la precompilazione dei campi se il mittente era anche il secondo destinatario. |
| 4316058 | Il comportamento dei campi nei report è stato aggiornato per consentire la presenza di zero iniziali nei campi di testo. |
| 4317382 | È stato corretto un problema relativo ai pulsanti di scelta, a causa del quale nella loro descrizione veniva visualizzato il codice HTML degli apostrofi invece dell’apostrofo. |
| 4317978 | È stato aggiornato il modo in cui gli allegati vengono ordinati nel PDF finale, per raggrupparli prima in base al numero di pagina del campo e quindi in base alla posizione relativa del campo (nei documenti con lettura da sinistra a destra e dall’alto al basso). |
| 4318598 | La chiamata API REST v6 GET/workflows/{workflowId} ora restituisce nella risposta il ruolo del partecipante. |
| 4318606 | La funzione “Scarica dati per campo modulo” nella pagina Gestisci ora restituisce i valori dei campi per i moduli Web non ancora verificati. |
| 4318617 | È stato risolto un problema a causa del quale, per gli account in cui è abilitata la funzione Utenti in più gruppi, l’amministratore di un gruppo non poteva inviare di nuovo un invito. |
| 4318679 | È stato risolto un problema intermittente che poteva causare il mancato caricamento dei documenti della firma scritta. |
| 4318926 | È stato corretto un problema che poteva innescare un errore (“La funzionalità cookie è disattivata nel browser”) durante la generazione di un accordo da un dispositivo mobile. |
| 4318991 | È stato risolto un problema a causa del quale l’impostazione di errore di accesso massimo veniva ignorata se SAML era impostato su Consentito. |
| 4319068 | I destinatari esterni ora devono superare un processo di autenticazione a due fattori (anziché accedere ad Adobe Sign) per accedere agli accordi completati, se è stata configurata l’autenticazione a più fattori. |
| 4319422 | È stato risolto un problema a causa del quale un destinatario poteva essere sostituito senza confermare la password (per accordi con autenticazione basata su password) |
| 4319455 | È stato risolto un problema nella condivisione avanzata a causa del quale le impostazioni potevano non essere persistenti dopo il salvataggio. |
| 4320123 | È stato risolto un problema che poteva generare un errore durante il tentativo di visualizzare e approvare un accordo nella pagina Gestisci. |
| 4320205 | È stato risolto un problema che poteva impedire il salvataggio del lavoro già fatto durante la pre-compilazione di un accordo tramite condivisione avanzata. |
| 4320542 | È stato risolto un problema relativo agli account abilitati per la funzione Utenti in più gruppi, a causa del quale tutte le affiliazioni di gruppo di un utente potevano risultare rimosse se si rimuoveva un gruppo mediante la funzione di ricerca. |
| 4321357 | È stato risolto un problema che poteva generare un errore nella pagina di invio se era selezionata l’autenticazione basata sulla conoscenza ed era abilitata l’opzione “Richiedi nome all’invio”. |
| 4322445 | È stato migliorato l’authoring per colori di fondo coerenti. |
| 4322956 | È stato risolto un problema relativo ai modelli e-mail personalizzati a causa del quale i destinatari non potevano vedere l’indirizzo e-mail effettivo del firmatario. |
| 4323609 | In Sviluppo: è stato risolto un problema a causa del quale gli accordi completati mediante il caricamento di un documento firmato non attivavano la notifica webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4323968 | È stata migliorata la funzione di blocco della firma in modo da includere le firme digitate quando il valore del nome viene fornito tramite profilo o API. |
Adobe Sign: ottobre 2021
Funzionalità migliorate
- Link per segnalazione abuso: gli account di livello Small Business e Individual includono ora un collegamento tramite il quale i destinatari possono accedere a un metodo per segnalare attività di potenziale abuso in relazione alle richieste di accordi in entrata.
- Integrazione con Notarize: l’integrazione di Adobe Sign con la piattaforma Remote Online Notarization (RON) di Notarize consente ai clienti di aggiungere un servizio di autenticazione ufficiale online remoto come parte delle transazioni Adobe Sign. Questo servizio può essere abilitato per i clienti negli Stati Uniti con un piano di livello Enterprise e Business, venduto direttamente da Adobe tramite il Programma ETLA. Le transazioni Notarize possono essere acquistate come componente aggiuntivo a pagamento solo per questi clienti.
- Aggiornamenti della pagina Invia: I clienti per i quali è stato abilitato il servizio di autenticazione ufficiale possono selezionare l’opzione Richiede autenticazione ufficiale nel record del destinatario, a destra del metodo di autenticazione:
- Aggiornamenti della pagina Invia: I clienti per i quali è stato abilitato il servizio di autenticazione ufficiale possono selezionare l’opzione Richiede autenticazione ufficiale nel record del destinatario, a destra del metodo di autenticazione:
Nota
Anche chi utilizza la pagina Invia nelle proprie applicazioni o integrazioni avrà accesso alla funzionalità di autenticazione ufficiale.
Dopo aver configurato l’accordo e fatto clic su Avanti, al mittente vengono presentate ulteriori opzioni di configurazione per il processo di autenticazione ufficiale:
- Aggiornamenti API - Sono stati apportati aggiornamenti significativi alle API per supportare l’integrazione Notarize:
POST /agreements
L’API POST /agreements è stata aggiornata per supportare l’invio di un accordo per l’autenticazione ufficiale.
- Per indicare un utente come partecipante a una sessione di autenticazione, è necessario utilizzare un nuovo ruolo, NOTARY_SIGNER.
- Un nuovo attributo NotaryInfo è stato aggiunto alla definizione AgreementInfo per contenere tutte le opzioni associate alla creazione di un nuovo accordo che richiede l’autenticazione ufficiale.
|
Nome parametro |
Oggetto REST |
Descrizione |
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
memberInfos |
ParticipantInfo[] |
Array di oggetti ParticipantInfo, contenente dati specifici per i singoli partecipanti (ad esempio, e-mail). Tutti i partecipanti presenti nell’array appartengono allo stesso set. |
||||||||||||||||
|
role |
|
Ruolo assunto da tutti i partecipanti al set (firmatario, approvatore, ecc.) |
Estensione di FileInfo
È necessario estendere la definizione FileInfo per indicare quali documenti devono essere autenticati.
|
Nome parametro |
Tipo |
Impostazione predefinita |
Obbligatorio |
Descrizione |
|---|---|---|---|---|
|
documento |
Document |
|
facoltativo |
Un documento associato al contratto. |
|
label |
Stringa |
|
facoltativo |
Valore di etichetta univoco di un elemento di informazioni file. In caso di flusso di lavoro personalizzato, verrà mappato un file all’elemento file corrispondente nella definizione del flusso di lavoro. |
|
libraryDocumentId |
Stringa |
|
facoltativo |
ID per un documento libreria esistente che verrà aggiunto all’accordo |
|
transientDocumentId |
Stringa |
|
facoltativo |
ID per un documento transitorio che verrà aggiunto all’accordo |
|
notarize |
true |
false |
facoltativo |
Indica che il documento deve essere autenticato. |
Estensione di ParticipantInfo
La definizione di ParticipantInfo è stata estesa per consentire di specificare il metodo di autenticazione ufficiale.
|
Nome parametro |
Tipo |
Impostazione predefinita |
Obbligatorio |
Descrizione |
|---|---|---|---|---|
|
|
Stringa |
N/A |
obbligatorio |
E-mail del partecipante. |
|
notaryAuthentication |
Enum |
MULTI_FACTOR_AUTHENTICATION |
facoltativo |
MULTI_FACTOR_AUTHENTICATION: l’autenticazione ufficiale viene eseguita utilizzando un metodo di autenticazione a due fattori |
NotaryInfo
Un nuovo campo facoltativo notaryInfo è stato aggiunto alla definizione AgreementInfo per contenere l’oggetto NotaryInfo che specifica opzioni aggiuntive associate all’autentiticazione.
|
Nome parametro |
Tipo |
Impostazione predefinita |
Obbligatorio |
Descrizione |
|---|---|---|---|---|
|
notaryType |
Enum |
Solo se Servizio di autenticazione on-demand Notarize è abilitato sull’account, |
obbligatorio |
NOTARIZE_NOTARY - Il servizio Notarize fornisce la persona addetta all’autenticazione |
|
payment |
Enum |
BY_SENDER |
facoltativo |
Applicabile solo se type == NOTARIZE_NOTARY |
|
appointmentStart |
Stringa |
"" |
facoltativo |
Stringa in formato ISO_DATE_TIME Vedi ISO_ZONED_DATE_TIME |
|
note |
Stringa |
nessuno |
facoltativo |
Note sulla sessione di autenticazione ufficiale. |
|
notaryEmail |
Stringa |
"" |
facoltativo |
e-mail della propria persona addetta all’autenticazione ufficiale |
Esempio di /agreement
PUT|GET /agreements/{aid}
L’API PUT /agreements/{aid} supporterà l’aggiornamento di un accordo con opzioni di autenticazione ufficiale. L’API GET /agreements/{aid} restituirà tutte le opzioni impostate per l’autenticazione ufficiale dell’accordo. Per visualizzare gli attributi aggiornati, consulta la sezione POST /agreements.
Codici di errore
I codici di errore esistenti per POST /agreements rimangono invariati. Abbiamo definito un nuovo codice di errore come indicato di seguito:
|
Codice di errore REST |
Codice di stato HTTP |
Messaggio |
Scenario |
|---|---|---|---|
|
PERMISSION_DENIED |
403 |
L’impostazione dell’utente o il token dell’ambito OAuth non consentono di inviare l’accordo per l’autenticazione ufficiale. |
L’errore verrà generato se il ruolo è impostato su NOTARY_SIGNER e per il chiamante API (ovvero il potenziale mittente) non è abilitata la funzione di autenticazione ufficiale e/o se il fornitore del servizio di autenticazione ufficiale non è stato impostato. |
Impatto sulla documentazione
Nell’oggetto AgreementInfo della richiesta, l’elemento “status” include il nuovo stato dell’accordo “WAITING_FOR_NOTARIZATION”.
POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens
L’API può essere utilizzata dai clienti (firmatari per autenticazione) per ottenere un token di firma che consenta loro di completare la fase di firma elettronica del flusso.
- È stata aggiunta una nuova funzionalità di firma per acquisire il nuovo ruolo: ACCEPT_BEFORE_NOTARIZATION.
- Non si devono ottenere token di firma per completare la fase di autenticazione ufficiale.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status
L’API può essere utilizzata dai clienti (firmatari per autenticazione) per completare la fase di firma elettronica del flusso. Per consentire l’uso del nuovo ruolo, è stato introdotto un nuovo valore di stato enum: ACCEPTED_BEFORE_NOTARIZATION.
|
Attributo |
Tipo |
Descrizione |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Stato |
Enum<String>
|
|
||||||||||||||
Il firmatario per l’autenticazione può seguire la sequenza di chiamate API riportata di seguito per completare la fase di firma elettronica:
- GET /agreements/{agreementId}/members: per recuperare l’ID partecipante del firmatario per l’autenticazione e l’ID del set di partecipanti
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens: per richiedere il token di firma per il firmatario per l’autenticazione con funzionalità ACCEPT_BEFORE_NOTARIZATION
- POST /transientDocuments: per caricare un documento che è stato rivisto
- PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status: per inviare un documento rivisto e completare la fase di firma elettronica.
Nuovo evento webhook
I clienti possono abbonarsi a un nuovo evento webhook, AGREEMENT_READY_FOR_NOTARIZATION, per essere avvisati quando l’accordo è pronto per l’autenticazione ufficiale. L’evento non è visibile nell’interfaccia utente dei webhook e se ne possono ricevere le notifiche tramite la chiamata API POST /webhooks.
Impatto sulla documentazione
Le seguenti API non sono state modificate, ma la relativa documentazione è stata aggiornata per includere il nuovo stato di accordo “WAITING_FOR_NOTARIZATION” o il nuovo ruolo “NOTARY_SIGNER”.
GET /agreements
Nell’oggetto UserAgreements/UserAgreement, l’elemento “status” include ora lo stato corrispondente “WAITING_FOR_NOTARIZATION”.
GET /agreements/{agreementId}
Nell’oggetto AgreementInfo di risposta, l’oggetto “status” ora include lo stato corrispondente “WAITING_FOR_NOTARIZATION”.
GET /agreements/{agreementId}/events
L’API è aggiornata per supportare i nuovi eventi READY_TO_NOTARIZE e NOTARIZED.
Nell’oggetto di risposta Event
- L’elemento “participantRole” ora include il nuovo ruolo NOTARY_SIGNER.
- L’elemento “type” include nuovi eventi READY_TO_NOTARIZE e NOTARIZED. L'elemento “description” sarà rispettivamente “Documento inviato per autenticazione” e “Documento autenticato ricevuto”
GET /agreements/{agreementId}/members/participantSets/{participantSetId}
Nell’oggetto di risposta DetailedParticipantSetInfo, l’elemento “status” ora include lo stato corrispondente “WAITING_FOR_NOTARIZATION”.
PUT /agreements/{agreementId}
L’oggetto di richiesta AgreementInfo ora include lo stato “WAITING_FOR_NOTARIZATION”.
PUT /agreements/{agreementId}/members/participantSets/{participantSetId}
Lo stato WAITING_FOR_NOTARIZATION è uno dei valori dell’elemento “status” nell’oggetto DetailedParticipantSetInfo.
POST /agreements/{agreementId}/view
Lo stato "WAITING_FOR_NOTARIZATION" è stato aggiunto come una delle visualizzazioni consentite.
GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo
Se il partecipante specificato nel percorso della richiesta ha un ruolo di firmatario per autenticazione, l’API restituirà la configurazione di firma ACCEPT_BEFORE_NOTARIZATION, in linea con tutte le altre configurazioni di firma per questo accordo/partecipante.
Problemi risolti
| Problema | Descrizione |
| 4308901 | È stato corretto un problema in cui la delega di un accordo con autenticazione telefonica causava un errore se il numero di telefono delegato aveva lo stesso codice paese. |
| 4314113 | È stato risolto un problema a causa del quale non era possibile modificare le date di scadenza predefinite durante l’invio di un nuovo accordo. |
| 4318558 | È stato corretto un problema a causa del quale la sostituzione di un destinatario con autenticazione telefonica causava un errore con il seguente messaggio: “L’ID del set di partecipanti specificato non è valido.” |
| 4319038 | È stato risolto un problema a causa del quale il mittente non aveva l’opzione di “Verifica identità destinatari esterni” durante l’invio tramite il flusso di lavoro “Invia in modalità collettiva”. |
| 4319798 | È stato risolto un problema a causa del quale la selezione di un pulsante di scelta risultava nell’attivazione di un campo diverso. |
| 4320154 | È stato risolto un problema che poteva impedire il salvataggio di un modello di libreria in una nuova relazione di gruppo. |
| 4323013 | È stato risolto un problema a causa del quale l’apertura di un modulo web nella pagina Gestisci generava il seguente errore: “Il documento non è ancora disponibile o non avrà pagine da visualizzare.” |
| 4323554 | È stato risolto un problema a causa del quale le indicazioni di ora/data degli eventi per l’aggiornamento dei diritti di amministratore potevano produrre due record con gli stessi valori temporali. |
| 4323609 | È stato risolto un problema a causa del quale il caricamento di un accordo firmato nella pagina Gestisci non attivava il webhook AGREEMENT_WORKFLOW_COMPLETED. |
| 4325142 | È stato risolto un problema a causa del quale nei modelli e-mail personalizzati non veniva riportato il nome corretto di un partecipante se questi aveva annullato l’accordo. |
| 4326747 | È stato risolto un problema che poteva causare il mancato completamento del processo di caricamento della pagina Invia in modalità collettiva, omettendo le azioni Carica e Invia. |
| 4326855 | È stato risolto un problema che poteva impedire ai destinatari di rifiutare l’approvazione di un accordo. |
| 4327000 | È stato corretto un problema a causa del quale le credenziali Smart-Id potevano generare un errore relativo ad algoritmi non trovati. |
