Adobe Acrobat Sign voor Salesforce: Upgradehandleiding

Vanaf v21.0 is het object SIGN_Signed_Agreement__c (labelnaam: Ondertekende overeenkomst") afgeschreven.

Klanten die de URL voor een ondertekende overeenkomst willen ontvangen, moeten de REST API-overeenkomst aanroep GET /agreements/{agreementId}/combinedDocument/url gebruiken

Opmerking: de geretourneerde URL van de API-aanroep is beveiligd, en slechts gedurende een beperkte tijd bruikbaar.

Hieronder ziet u de nieuwe volgorde (vanaf v21.0) waarin de overeenkomst en de bijbehorende objecten worden bijgewerkt:

1. Bijlagen 
2. Ontvangers 
3. Overeenkomst (status en andere kenmerken)
4. Overeenkomstgebeurtenissen 
5. Chatter-feeds 

Vanaf v21.x worden alle asynchrone processen, waaronder automatische updates en gegevenstoewijzingen, overgeschakeld van future methods naar queuebale, een nieuwe aanpak die wordt aanbevolen door Salesforce.

Als gevolg van deze wijziging mislukken eventuele aanpassingen in de organisatie van de org van het lid dat taken toevoegt aan de Salesforce-wachtrij als onderdeel van het proces voor automatisch bijwerken en/of gegevenstoewijzing, met de foutmelding 'System.LimitException: Te veel wachtrijtaken toegevoegd aan de wachtrij: 2'

De reden voor deze fout is dat een doorzoekbaar proces slechts één onderliggende doorzoekbare taak kan toevoegen, en dat gebeurt al door Adobe Sign (zie de sectie "Doorzoekbare Apex-limieten").

"Als u taken koppelt, kunt u slechts één taak toevoegen van een taak die wordt uitgevoerd met System.enqueueJob. Dit houdt in dat elke bovenliggende doorzoekbare taak slechts één onderliggende taak kan bevatten. Het systeem biedt geen ondersteuning voor het starten van meerdere onderliggende taken van dezelfde doorzoekbare taak."

Als gevolg van deze fout wordt de overeenkomststatus niet wordt gewijzigd en/of wordt de gegevenstoewijzing niet correct uitgevoerd. 

Om deze fout op te lossen, moet u nagaan welke trigger, process builder of workflow de fout veroorzaakt en deze deactiveren of omschakelen naar een synchrone aanroep. U kunt het betreffende proces ook uitstellen en bijvoorbeeld 1 uur later uitvoeren.

• De overeenkomststatus wordt nu bijgewerkt nadat de documenten en de ontvangers zijn bijgewerkt.
  Voor V 21 of eerder is de status al ingesteld.

• Het ondertekende overeenkomstobject dat de afbeeldings-URL's opslaat, wordt nu niet ingevoegd.
  Voorafgaand aan versie v21 werd dit object ingevoegd nadat alle andere updates waren voltooid.
• De maximale grootte van bijschriftverzoeken of reacties is beperkt tot 12 MB voor asynchrone apex volgens de Salesforce-beheerdersbeperkingen: https://developer.salesforce.com/docs/atlas.en-us.210.0.apexcode.meta/apexcode/apex_gov_limits.htm
  Documenten die groter zijn dan 12 MB, kunnen vanwege de bovenstaande limiet niet worden opgehaald van Sign.

• Beschrijvingen van overeenkomstgebeurtenissen komen nu overeen met de beschrijving zoals geretourneerd door de Sign-API en met de controlerapporten.
• Het updateproces wordt nu uitgevoerd als een native Apex-batchproces, een asynchroon proces, binnen Salesforce.
  Voorheen werden bij de update API-aanroepen van buiten Salesforce gebruikt. Triggers van deze statusupdates voor het starten van asynchrone processen functioneren niet meer omdat Salesforce beperkingen heeft ingesteld voor het aanroepen van andere asynchrone processen vanuit een asynchroon proces dat al actief is.
• Het overeenkomstobject wordt nu in één transactie bijgewerkt.
  Vóór v21 werden de updates voor overeenkomstkenmerken opgesplitst in afzonderlijke update-aanroepen.
• Updates zijn nu betrouwbaarder omdat de Sign-back-end mislukte gebeurtenissen automatisch een bepaald aantal keren opnieuw probeert.
  Vóór v21 konden mislukte overeenkomsten alleen opnieuw worden geprobeerd door een handmatige update uit te voeren vanuit Salesforce
• Bij handmatige updates worden nu alle aspecten van overeenkomsten bijgewerkt, inclusief de gerelateerde objecten.
• Pushovereenkomsten worden nu uitgevoerd in asynchrone modus, net als reguliere updates, en andere attributen worden bijgewerkt, net als reguliere updates.
• Er zijn nieuwe instellingen geïntroduceerd om updates van verschillende aspecten van de overeenkomst in en uit te schakelen.
• Wanneer een ondertekende PDF wordt opgeslagen in Salesforce, wordt er geen descriptor (-ondertekend of -goedgekeurd) toegevoegd aan het einde van de PDF-bestandsnaam.

Nadat de upgrade is voltooid, volgt u de onderstaande stappen om opnieuw een OAuth-verbinding met Acrobat Sign tot stand te brengen:

1. Selecteer het tabblad Adobe Acrobat Sign-beheerder.
2. Selecteer Automatische statusupdates inschakelen.
3. Selecteer Inschakelen.
4. Selecteer Toestaan.

In v20 hoefde de callbackgebruiker bij Salesforce geen gebruiker met een Adobe Sign-licentie te zijn. 

Pushtoewijzingsverbeteringen in v21 vereisen dat de callbackgebruiker een actieve gebruikers-ID heeft in het Acrobat Sign-account dat is verbonden met de Salesforce-organisatie.

v20-klanten die pushtoewijzing gebruiken, moeten ervoor zorgen dat de callbackgebruiker al is opgenomen in Adobe Acrobat Sign voordat ze gaan upgraden. Anders stopt de pushtoewijzing met werken (totdat de gebruiker is opgenomen) na het upgraden naar v21.

De pushtoewijzingsfunctionaliteit die automatisch gerelateerde objecten koppelde met behulp van de instelling Contactpersoonaccount/opportunity kopiëren, is uitgebreid met overeenkomsten die vanuit Salesforce zijn verzonden.

• bijv. Overeenkomsten die vanuit Salesforce worden verzonden, kopiëren automatisch de zoekactie Kans van de eerste contactontvanger naar de zoekactie Kans van de overeenkomst en de zoekactie van het account van de eerste contactpersoon van de ontvanger naar de accountzoekopdracht van de overeenkomst, als de verzonden overeenkomsten geen gekoppelde account/kans hebben

Voor v21 werden chatterfeeds alleen ingevuld wanneer de overeenkomst vanaf Salesforce werd verzonden.

Deze update breidt de Chatter-feed uit met overeenkomsten die van buiten Salesforce zijn verzonden (Pushovereenkomsten)

Voor v21 werden in de overeenkomstweergave de PDF-afbeelding en de URL alleen bijgewerkt nadat de eerste ontvanger zijn of haar actie had voltooid.

De afbeelding en URL worden nu eerder bijgewerkt wanneer de status Vooraf vullen actief is of wanneer Verzonden ter ondertekening naar de eerste ontvanger is verstuurd.

Er is geen configuratie vereist om deze functie in te schakelen.

Er wordt een nieuwe overeenkomststatus (Wachten op mijn delegatie) geïntroduceerd om aan te geven wanneer een overeenkomst wacht totdat de afzender de huidige ontvangersinstantie delegeert.

Er is geen configuratie vereist om deze status in te schakelen.

De overeenkomstsjabloon heeft een veld 'Dagen tot vervaldatum' (echosign_dev1__Days_Until_Expiration__c).  Dit is een numeriek veld dat werd afgeschaft in v21.

Er is een nieuw veld Dagen tot vervaldatum (API-naam: echosign_dev1__Days_Until_Expiration2__c) toegevoegd, maar dit is een tekstveld, waardoor het kan verwijzen naar andere velden in het hoofdobject (bijvoorbeeld {!Expiry_Date__c})

Bij het upgraden van een eerdere versie worden eventuele formuliergegevens die zijn toegewezen aan het verouderde veld voor de vervaldatum, automatisch naar het nieuwe veld gekopieerd, zodat er geen directe actie vereist is.

De velden Account, Opportunity en Contract zijn niet beschikbaar op de sjabloonpagina.

Beheerders kunnen deze velden configureren in de sjabloon met behulp van de functie Gegevens toewijzen aan overeenkomstvelden

Voorheen konden afzenders hun absolute positie in de handtekeningstapel definiëren als Afzender tekent eerst of Afzender tekent laatst.

Dit veld is niet meer beschikbaar op de pagina's voor Nieuwe sjabloon. Afzenders kunnen zichzelf op een willekeurige positie in de handtekeningenvolgorde plaatsen.

De optie voor het in- en uitschakelen van de controle over de gehele handtekeningsflow als Sequentieel of Parallel is verwijderd.

De nieuwe sjabloonstijl maakt een volledig configureerbare workflow mogelijk die volledig sequentieel kan zijn (Signer-index 1 tot en met 1+N), parallel (alle Signer-indexen zijn 1) of een combinatie van sequentieel en parallel waarbij de handtekeningindex is geconfigureerd voor de specifieke workflow.

Vijf instellingen zijn afgeschaft in v21. Al deze instellingen bevonden zich in de sectie Adobe Sign-instellingen van Aangepaste instellingen.

De vijf instellingen zijn:

• Audit-PDF toevoegen aan bijlagelijst – Schakel deze instelling in om na ondertekening van de overeenkomst een PDF van de audittrail aan de overeenkomstrecord toe te voegen.
• Ondertekende PDF toevoegen als afzonderlijke bijlagen – Schakel deze instelling in om de PDF van de ondertekende overeenkomsten als afzonderlijke bijlagen te koppelen als er meerdere documenten in één transactie worden verzonden. Neem contact op met de klantenservice van Adobe voor hulp als u de ondertekende overeenkomst niet meer als samengevoegde PDF wilt ontvangen.
• Ondersteunende bestanden toevoegen aan lijst met bijlagen – Schakel deze instelling in om na ondertekening van de overeenkomst de PDF's van de ondersteunende documenten aan de overeenkomstrecord toe te voegen. Met de ondersteunende documentvelden in de overeenkomst kunnen ondertekenaars de ondersteunende documenten uploaden naar en bijvoegen bij de overeenkomsttransactie.
• Ondertekende PDF-koppeling toevoegen voor gepushte overeenkomsten (standaard ingeschakeld)—Deze instelling is alleen van toepassing op gepushte overeenkomsten die buiten Salesforce worden verzonden. Schakel deze instelling in om een koppeling voor ondertekende PDF toe te voegen aan de overeenkomstrecord.
• Ondertekende PDF toevoegen voor gepushte overeenkomsten (standaard ingeschakeld)—De instelling is van toepassing op overeenkomsten die van buiten Salesforce worden verzonden en naar Salesforce worden gepusht. Schakel deze instelling in om de ondertekende PDF aan de overeenkomstrecord toe te voegen. 

Klanten die de bovenstaande instellingen gebruiken, kunnen de nieuwe instelling configureren onder Adobe Sign-instellingen voor het bijwerken van overeenkomsten.