Guida all’aggiornamento di Adobe Acrobat Sign for Salesforce

A partire dalla versione 21.0, l’oggetto SIGN_Signed_Agreement__c (nome etichetta: “Accordo firmato”) è stato dichiarato obsoleto.

I clienti che desiderano ottenere l’URL dell’accordo firmato devono utilizzare la chiamata dell’accordo REST API GET /agreements/{agreementId}/combinedDocument/url

Nota: l’URL restituito dalla chiamata API è protetto e valido solo per un periodo di tempo limitato.

Di seguito è riportata la nuova sequenza (a partire dalla versione 21.0) di aggiornamento dell’accordo e dei suoi oggetti correlati:

1. Allegati 
2. Destinatari 
3. Accordo (stato e altri attributi)
4. Eventi dell’accordo
5. Feed di Chatter

A partire dalla versione 21.x tutti i processi asincroni (che comprendono aggiornamenti automatici e mappature dei dati) non utilizzano più i metodi Future bensì un nuovo approccio consigliato da Salesforce, Queueable.

A causa di questa modifica, eventuali personalizzazioni dell’organizzazione abbonata che prevedono l’aggiunta di lavori alla coda di Salesforce nel corso di un processo di aggiornamento automatico o di mappatura dei dati daranno luogo a un errore di tipo “System.LimitException: troppi lavori queueable aggiunti alla coda: 2”

Questo si verifica perché un processo queueable può aggiungere un solo lavoro queueable figlio, che è già occupato da Adobe Sign (consulta la sezione sui limiti Queueable di Apex).

“Quando si concatenano più lavori, è possibile aggiungere un solo lavoro da un lavoro in esecuzione con System.enqueueJob. Ogni lavoro padre queueable può quindi avere un solo lavoro figlio. Non è possibile avviare più lavori figlio da uno stesso lavoro queueable.”

Quando si verifica questo errore, lo stato dell’accordo non cambia e/o la mappatura dei dati non viene eseguita correttamente. 

Per risolverlo, individua il fattore scatenante (che può essere un trigger, generatore di processi o flusso di lavoro) e disattivalo oppure impostalo su una chiamata sincrona, o ancora rimandalo ad esempio di un’ora.

• Lo stato dell’accordo ora viene aggiornato dopo l’aggiornamento dei documenti e dei destinatari.
  Per la V 21 o versioni precedenti, lo stato era impostato prima.

• L’oggetto Accordo firmato che memorizza gli URL immagine non è inserito in questo momento.
  Per la versione v21 veniva inserito dopo il completamento di tutti gli altri aggiornamenti.
• La dimensione massima delle richieste o risposte di callout è limitata a 12 MB per codice Apex asincrono, in base ai limiti di Salesforce: https://developer.salesforce.com/docs/atlas.en-us.210.0.apexcode.meta/apexcode/apex_gov_limits.htm
  I documenti di dimensioni superiori a 12 MB non possono essere recuperati da Sign a causa del limite precedente.

• Le descrizioni degli eventi dell’accordo ora corrispondono alle descrizioni restituite dall’API di Sign e presenti nei report di audit.
• Il processo di aggiornamento ora viene eseguito come processo batch Apex nativo (processo asincrono) in Salesforce.
  Precedentemente era un aggiornamento che utilizzava le chiamate API dall’esterno di Salesforce. I trigger attivati da tali aggiornamenti di stato che avviano processi asincroni non funzionano più, in quanto Salesforce limita la chiamata di un altro processo asincrono da parte di un processo asincrono già in esecuzione.
• L’oggetto accordo viene ora aggiornato tutto in una transazione.
  Prima della versione v21, gli aggiornamenti degli attributi dell’accordo venivano suddivisi in chiamate di aggiornamento separate.
• Ora gli aggiornamenti sono più affidabili in quanto il back-end di Sign ritenta automaticamente gli eventi non riusciti per un determinato numero di volte.
  Prima della versione v21, gli accordi non riusciti potevano essere ritentati solo mediante un aggiornamento manuale dall’interno di Salesforce
• Gli aggiornamenti manuali ora aggiornano tutti gli aspetti degli accordi, inclusi gli oggetti correlati.
• Gli accordi push ora vengono eseguiti in modalità asincrona (come gli aggiornamenti regolari) e gli attributi aggiuntivi vengono aggiornati (come gli aggiornamenti regolari).
• Sono state introdotte nuove impostazioni per abilitare o disabilitare gli aggiornamenti dei diversi aspetti dell’accordo.
• Quando un PDF firmato viene archiviato in Salesforce, alla fine del nome del file PDF non verrà più aggiunto un descrittore (-firmato o -approvato).

Al termine dell’aggiornamento, segui i passaggi riportati di seguito per ristabilire una connessione OAuth ad Acrobat Sign:

1. Seleziona la scheda Amministrazione Adobe Acrobat Sign .
2. Seleziona Abilita aggiornamenti di stato automatici.
3. Seleziona Abilita.
4. Seleziona Consenti.

Nella versione v20, l’utente di richiamata di Salesforce non doveva essere necessariamente un utente con licenza per Adobe Sign. 

In seguito ai miglioramenti apportati nella versione v21 alla mappatura push, ora l’utente di richiamata deve disporre di un ID utente attivo nell’account Acrobat Sign collegato all’organizzazione Salesforce.

Gli utenti della versione v20 che utilizzano la mappatura push devono assicurarsi che l’utente di richiamata sia già stato abilitato in Adobe Acrobat Sign prima dell’aggiornamento. In caso contrario la mappatura push non funzionerà più (finché l’utente non sarà stato abilitato) dopo l’aggiornamento alla versione v21.

La funzione di mappatura push che collegava automaticamente gli oggetti correlati mediante l’impostazione “Copia account/opportunità referente” è stata estesa in modo da includere anche gli accordi inviati da Salesforce.

• Ad esempio, per gli accordi inviati da Salesforce a cui non è collegato un Account o un’Opportunità, nella ricerca Opportunità e Account dell’accordo verrà rispettivamente copiata, in automatico, la prima voce di ricerca Opportunità o Account per il Referente del destinatario.

Prima della versione v21, i feed Chatter venivano popolati solo se l’accordo veniva inviato dall’interno di Salesforce.

Con questo aggiornamento il feed Chatter è stato esteso in modo da includere anche gli accordi inviati dall’esterno di Salesforce (accordi push)

Prima della versione v21, nella vista Accordo l’URL e l’immagine PDF venivano aggiornati dopo che il primo destinatario avesse completato il suo intervento.

Ora l’immagine e l’URL vengono aggiornati prima, nello stato di precompilazione o quando l’accordo è stato Inviato per la firma al primo destinatario.

Per abilitare questa funzionalità non è necessaria alcuna configurazione.

È stata aggiunto un nuovo stato di accordo, In attesa della mia delega, per indicare quando un accordo è in attesa che il mittente deleghi l’autorizzazione del destinatario corrente.

Per abilitare questo stato non è necessaria alcuna configurazione.

Il modello di accordo dispone di un campo “Giorni alla scadenza” (echosign_dev1__Days_Until_Expiration__c).  Si tratta di un campo numerico che è stato dichiarato obsoleto nella versione v21.

È stato invece aggiunto un nuovo campo di testo “Giorni alla scadenza” (nome API: echosign_dev1__Days_Until_Expiration2__c) che consente di fare riferimento ad altri campi nell’oggetto principale (ad esempio, {!Expiry_Date__c})

Quando si esegue l’aggiornamento da una versione precedente, eventuali dati di modulo associati al campo di scadenza precedente vengono automaticamente copiati nel nuovo campo. Non è quindi necessario alcun intervento diretto.

I campi Account, Opportunità, e Contratto non sono più disponibili nella pagina del modello.

Gli amministratori possono configurare questi campi del modello utilizzando la funzione Mappatura dei dati nel campo dell’accordo

In precedenza, il mittente poteva definire la posizione assoluta nell’ordine delle firme come “Il mittente firma per primo” o “Il mittente firma per ultimo”.

Questo campo non è più disponibile nelle pagine Nuovo modello. Il mittente può scegliere di inserirsi in qualsiasi posizione nell’ordine delle firme.

È stata rimossa l’opzione che consentiva di impostare il flusso di firma complessivo come “Sequenziale” o “Parallelo”.

Il nuovo stile di modello consente un flusso di lavoro completamente configurabile, che può essere interamente sequenziale (indice firmatario da 1 a 1+N), parallelo (l’indice di tutti i firmatari è 1) o una combinazione di sequenziale e parallelo in cui l’indice della firma viene configurato in base al flusso di lavoro specifico.

Cinque impostazioni sono state dichiarate obsolete nella versione v21. Tutte le impostazioni si trovavano nella sezione Impostazioni di Adobe Sign in Impostazioni personalizzate.

Le cinque impostazioni sono:

• Aggiungi file PDF audit a elenco alleg.: attiva questa impostazione per allegare il PDF dell'audit trail al record dell'accordo dopo che l'accordo è stato firmato.
• Agg. file PDF firm. come alleg. separ.: attiva questa impostazione per allegare il PDF degli accordi firmati come allegati separati quando vi sono più documenti inviati in una singola transazione. Per non ricevere più l’accordo firmato come file PDF unito, contatta il supporto Adobe per assistenza.
• Agg. file supporto a elenco allegati: attiva questa impostazione per allegare i PDF dei documenti di supporto al record dell'accordo dopo che l'accordo è stato firmato. Tramite i campi del documento di supporto nell'accordo, i firmatari caricano e allegano la documentazione di supporto alla transazione dell'accordo.
• Aggiungi collegamento al file PDF firmato per accordi inviati (abilitata per impostazione predefinita): questa impostazione si applica soltanto agli accordi inviati al di fuori di Salesforce. Abilita questa impostazione per aggiungere un collegamento relativo al file PDF firmato al record dell’accordo.
• Aggiungi file PDF firmato per gli accordi inviati (abilitata per impostazione predefinita): questa impostazione si applica ad accordi inviati a Salesforce dall’esterno di Salesforce. Abilita questa impostazione per allegare il PDF firmato al record dell’accordo.  

I clienti che utilizzano queste impostazioni possono configurare la nuova impostazione nella sezione delle impostazioni per l’aggiornamento dell’accordo di Adobe Sign.