global
- Adobe Acrobat Sign-integreringar
- Nyheter
- Produktversioner och livscykel
- Acrobat Sign för Salesforce
- Installera paketet
- Konfigurera paketet
- Användarhandbok
- Användarhandbok för utvecklare
- Handbok om avancerad anpassning
- Användarhandbok för fältmappning och mallar
- Användarhandbok för den mobila appen
- Flödesautomatiseringsguide
- Användarhandbok för Document Builder
- Konfigurera stora dokument
- Användarhandbok för uppgraderingar
- Versionsinformation
- Svar på vanliga frågor
- Felsökningsguide
- Ytterligare artiklar
- Acrobat Sign för Microsoft
- Acrobat Sign för Microsoft 365
- Acrobat Sign för Outlook
- Acrobat Sign för Word/PowerPoint
- Acrobat Sign för Teams
- Acrobat Sign för Microsoft PowerApps och Power Automate
- Acrobat Sign Connector för Microsoft Search
- Acrobat Sign för Microsoft Dynamics
- Acrobat Sign för Microsoft SharePoint
- Översikt
- SharePoint On-Prem: installationshandbok
- SharePoint On-Prem: användarhandbok för mallmappning
- SharePoint On-Prem: användarhandbok
- SharePoint On-Prem: versionsinformation
- SharePoint Online: installationshandbok
- SharePoint Online: användarhandbok för mallmappning
- SharePoint Online: användarhandbok
- SharePoint Online: användarhandbok för mappning av webbformulär
- SharePoint Online: versionsinformation
- Acrobat Sign för Microsoft 365
- Acrobat Sign för ServiceNow
- Acrobat Sign för HR ServiceNow
- Acrobat Sign för SAP SuccessFactors
- Acrobat Sign för Workday
- Acrobat Sign för NetSuite
- Acrobat Sign för SugarCRM
- Acrobat Sign för VeevaVault
- Acrobat Sign för Coupa BSM Suite
- Utvecklingsdokumentation för Acrobat Sign
Översikt
Adobe Acrobat Sign för Salesforce: Utvecklar guide är utformad för att hjälpa Salesforce-utvecklare att lära sig om de objekt och parametrar som krävs för att integrera ditt Salesforce-paket med Adobe Acrobat Sign.
Läs mer om de olika ämnena i detta dokument:
Adobe Acrobat Sign för Salesforce-objekt kan ändras i en framtida version. Om du skapar en anpassad lösning som är beroende av objekt som sedan ändras kanske anpassningen måste uppdateras.
- Om du behöver veta när avtalet är helt signerat implementerar du en Apex-utlösare på objektet echosign_dev1__SIGN_Agreement__c, efter eller före uppdatering (beroende på typ av användning och krav). När fältet echosign_dev1__Status__c ändras till Signerat eller Godkänt eller annan slutlig status, är avtalet slutfört.
- Om du behöver veta när varje enskild signerad PDF-fil infogas, om du t.ex. behöver få varje mellanliggande signerad PDF-fil, ska du implementera en Apex-utlösare på objekten Attachment eller ContentVersion, efter infogning, och vara uppmärksam på ett överordnat avtal och ett namn som slutar på "signed.pdf" eller "approved.pdf" eller någon annan slutlig status
- Om du vill veta när en enskild mottagare har signerat eller godkänt implementerar du en Apex-utlösare på objektet echosign_dev1__SIGN_Recipients__c, efter eller före uppdatering (beroende på typ av användning och krav). När fältet echosign_dev1__Status__c ändras till Signerat eller Godkänt eller annan slutlig status, slutförs mottagaren.
- Om du behöver veta när en viss händelse som ingår i signeringsprocessen inträffar, till exempel ett avtal som skickas för signering eller en påminnelse som skickas, kan en utlösare skapas på avtalshändelseobjektet (echosign_dev1__SIGN_AgreementEvent__c) och kontrollera händelsetypen
- Statusnamn för slutgiltiga avtal för ett slutfört avtal är: "Signerat", "Godkänt", "Accepterat", "Formulär ifyllt" och "Levererat"
- Statusnamn för det slutliga avtalet för ett avslutat avtal är: "Avbrutet/avvisat", "Avbrutet/avvisat", "Utgånget"
I v21 har uppdateringsordningen ändrats. Nedan visas den nya sekvensen när avtal och relaterade objekt uppdateras:
- Bifogade filer
- Mottagare
- Avtal (status och övriga attribut)
- Avtalshändelser
- Chatter-flöden
Apex-metod som används
Från och med Acrobat Sign för Salesforce v 21.0 använder alla asynkrona processer (inklusive automatiska uppdateringar och datamappningar) kömetoden i stället för framtidsmetoden, som rekommenderas av Salesforce.
Med den här ändringen kommer alla anpassningsjobb som läggs till i Salesforce-kön för automatisk uppdatering eller datamappningsprocess att misslyckas med det här felet: "System.LimitException: för många köbara jobb har lagts till i kön:2."
Felet beror på att en köbar process bara kan lägga till ett köbart underordnat jobb, som redan är upptaget av Acrobat Sign. Mer information finns i Kögränser för Apex.
Om avtalets status inte ändras eller om datamappningen inte körs korrekt kan det här felet visas: "När du länkar jobb kan du bara lägga till ett jobb från ett körande jobb med System.enqueueJob, vilket innebär att bara ett underordnat jobb kan finnas för varje överordnat köbart jobb. Att starta flera underordnade jobb från samma köbara jobb stöds inte."
Lös felet genom att leta efter den felande utlösaren, processbyggaren eller arbetsflödet och inaktivera det eller ändra det till att använda ett synkront anrop eller schemalägga det till senare.
Avtalsmalltjänst
Avtalsmalltjänsten visas som en global Apex-tjänst av det hanterade paketet. Detta gör att Apex-kod utanför det hanterade paketet kan läsa in avtal som baseras på befintliga avtalsmallar. Klassen och alla exponerade metoder markeras som global för att medge sådan tillgång.
Apex-tjänsten visas via denna anropsklass: echosign_dev1.AgreementTemplateService
Metoder
|
static Id load() |
Läser in ett avtal med en avtalsmall som är markerad som standard och som inte har någon huvudobjekttyp. |
global |
static Id load(String templateId) |
Läser in ett avtal med den angivna avtalsmallens ID, som inte har någon huvudobjekttyp.
|
global |
static Id load(String templateId, String masterId) |
Läser in ett avtal med den angivna avtalsmallens ID och den angivna huvudpostens ID, vars typ måste matcha huvudobjekttypen som konfigurerats i den angivna avtalsmallen. |
global |
static Id load(String templateId, String masterId, Map<String,AgreementTemplateVariable> agreementTemplateVariables) |
Läser in ett avtal med den angivna avtalsmallens ID och den angivna huvudpostens ID, vars typ måste matcha huvudobjekttypen som konfigurerats i den angivna avtalsmallen. Skickar även de angivna körningsvariablerna som namnvärdepar.
|
global |
static List<AgreementTemplateService.AgreementTemplateBasicInfo> getAgreementTemplateList(AgreementTemplateListOptions options) |
Hämta en lista över avtalsmallar baserat på filtreringsalternativ. Returnera en tom lista om ingen avtalsmall hittas med filtreringsalternativen. |
global |
static AgreementTemplateService.AgreementTemplateDetails getAgreementTemplateDetails(String templateId) |
Hämta information om avtalsmallar för den angivna avtalsmallens ID. Returnera ett tomt objekt om ingen avtalsmall hittades. |
global |
static String getAgreementTemplateUrl(String templateId) |
Hämta URL:en för att redigera avtalsmallen utifrån avtalsmallens ID. |
global |
static String getNewAgreementTemplateUrl() |
Hämta URL:en för att skapa en ny avtalsmall i Adobe Sign. |
Konstruktörer
Åtkomst |
Signatur |
---|---|
global |
AgreementTemplateListOptions() |
global |
AgreementTemplateListOptions(String masterObjectType, Boolean isActive, Boolean hasAttachment, Boolean hasRecipient, Boolean autoSend) |
Globala Class-egenskaper
Åtkomst |
Namn |
---|---|
global |
masterObjectType |
global |
isActive |
global |
hasAttachment |
global |
hasRecipient |
global |
autoSend |
Inget filter tillämpas på dess motsvarande fält när frågor ställs till avtalsmallar om ett fält som anges ovan har ett null-värde.
Åtkomst |
Namn |
---|---|
global |
namn |
global |
recordId |
global |
url |
global |
isDefault |
global |
daysUntilExpiration |
global |
språk |
Åtkomst |
Namn |
---|---|
global |
meddelande |
global |
ccList |
global |
dataMappingName |
global |
mergeMappingName |
global |
url |
global |
mottagare |
Åtkomst |
Namn |
---|---|
global |
recipientRole |
global |
recipientType |
global |
recipientName |
global |
signOrder |
Körningsvariabler
Den globala klassen echosign_dev1.AgreementTemplateVariable har följande två globala fält:
- namn: variabelnamnet, som måste matcha ett körningsvariabelnamn som konfigurerats i avtalsmallen.
- värde: Det variabelvärde som används när mallen läses in. Värdet beror på var variabeln användes. För en mottagare måste det t.ex. vara ett kontakt-, lead- eller användarregistrerings-ID eller ett e-postmeddelande. För en dokumentvariabel måste det vara ett post-ID för en bifogad fil.
Resultat
Varje metod returnerar antingen ID för den nyskapade avtalsposten eller kastar ett undantag med ett detaljerat felmeddelande om något går fel under inläsningen.
API-malltjänsten Adobe e-Sign visas som en global Apex-tjänst av det hanterade paketet. Detta gör att Apex-kod utanför det hanterade paketet kan anropa en uppsättning API:er för Adobe e-Sign via dessa omslag. Omslagen förenklar API-anropet avsevärt eftersom konsumenterna inte behöver skapa begärande- och svarsdatamodeller. Konsumenterna behöver inte heller hantera omvandlingen av Salesforce-data till e-Sign-datamodeller. Det mesta av komplexiteten tas ifrån konsumenten. Om du t.ex. vill skicka ett avtal som konsumenten just skickar i avtalspost-ID, kommer tjänsten att hantera frågor om det, extrahera alla relevanta data, skicka dem till API för analys av resultatet.
Klassen och alla exponerade metoder markeras som global för att medge sådan tillgång.
- v17 och tidigare anropar SOAP API:er
- v18 och högre anropar REST API:er
Apex-tjänsten visas genom följande anropsklass: echosign_dev1.EchoSignApiService
Apex API-förbättring för alternativa mottagare
Från version 24.14 eller senare gör det uppdaterade Apex API att du kan ersätta eller lägga till alternativa mottagare och är tillgängligt inom den globala klassen "EchoSignApiService", två nya element har införts:
- En global funktion:
/**
* Indataparametrar:
* toBeChangedRecipientId: SIGN_Recipient__c Id
* newRecipientStr: JSON-sträng för SIGN_Recipient__c för en ny mottagare för mottagarersättning eller alternativ
* changeType: REPLACE eller ALTERNATE
*/
global static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, RECIPIENT_CHANGE_TYPE changeType )
- En global uppräkning: RECIPIENT_CHANGE_TYPE {REPLACE, ALTERNATE}
Exempelkod för att anropa detta API för mottagare (mottagartyp som e-post)
// Fråga först alla mottagare som är kopplade till avtalet
List<SIGN_Recipients__c> recipients = [SELECT Id, echosign_dev1__Agreement__c, echosign_dev1__Email_Address__c, echosign_dev1__ParticipantSet__c, echosign_dev1__Recipient_Type__c, echosign_dev1__Order_Number__c FROM echosign_dev1__SIGN_Recipients__c where echosign_dev1__Agreement__c = 'a0P7X000008Cc1GUAS'];
SIGN_Recipients__c newRecipient = null;
SIGN_Recipients__c replacedRecipient = null;
// Hitta mottagaren som behöver ersättas eller en alternativ
// I det här fallet hittar du mottagaren via e-post.
// Fler villkor kan läggas till för att hitta mottagaren som ska ersättas eller behöver ett alternativ.
for(SIGN_Recipients__c recipient: recipients) {
if (rep.echosign_dev1__Email_Address__c == 'someUser@example.com') {
newRecipient = recipient.clone(false, true, false, false);
replacedRecipient = recipient;
}
}
// uppdatera ny mottagares e-postadress
newRecipient.echosign_dev1__Email_Address__c = ''someNewUser@abc.com';
// serialisera det till json-sträng
String newRecipientStr = JSON.serialize(newRecipient);
Try {
echosign_dev1.EchoSignApiService.changeRecipient(replacedRecipient.Id, newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE.REPLACE);
} catch (Exception ex) {
// hantera undantaget och skicka tillbaka vid behov
}
Metoder
global |
static void cancelDocument(Id agreementId) |
Avbryter avtalet med angivet avtals-ID. |
global |
static echosign_dev1.EchoSignApiService.DocumentInfo getDocumentInfo(Id agreementId) |
Hämtar detaljerad information för angivet avtals-ID. |
global |
static List<EchoSignApiService.SigningUrl> getSigningUrls(Id agreementId) |
Hämtar alla signerings-URL:er för angivet avtals-ID. |
global |
static void removeDocument(Id agreementId) |
Annullerar avtalet med angivet avtals-ID och raderar avtalsposten i Salesforce (avtalet tas inte bort från Adobe e-Sign-kontot). |
global | static void replaceSigner(Id replacementRecipientId) |
Inaktuell med V 24.14. Paketversionerna före v24.14 kan fortfarande använda dem eftersom de är beroende av V5 API:er. |
global | static void replaceSigner(Id replacementRecipientId, String message) |
Inaktuell med V 24.14. Paketversionerna före v24.14 kan fortfarande använda dem eftersom de är beroende av V5 API:er. |
global |
static echosign_dev1.EchoSignApiService. SendDocumentResult sendDocument(Id agreementId) |
Skickar ut avtalet med angivet avtals-ID, returnerar resultatet med dokumentnyckel och webbadresser. |
global |
static void sendReminder(Id agreementId) |
Skickar en påminnelse till den aktuella undertecknaren för angivet avtals-ID. |
global | static void updateAgreement(Id agreementId) | Uppdaterar avtalet med angivet avtals-ID |
global | static EchoSignApiService.AgreementViewUrl getViewAgreementUrl(Id agreementId) |
Hämtar sidan visa/hantera från Sign för angivet avtals-ID, som har en vy-egenskap. Obs! Av säkerhetsskäl har den genererade avtals-URL:en bara en temporär livslängd, så den genererar ett REST-HTTPS-anrop för att hämta en ny URL från Adobe Sign-tjänster. |
global | static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE changeType ) | Detta API, som är tillgängligt från och med v24.14, ändrar avtalsmottagarna. |
Inre klasser
- Global Class: DocumentHistoryEvent
Åtkomst |
Namn |
---|---|
global |
String eventType |
global |
String participantEmail |
Åtkomst |
Signatur |
---|---|
global |
DocumentHistoryEvent() |
- Global Class: DocumentInfo
Åtkomst |
Namn |
---|---|
global |
Map<string,list> historyByEmail |
global |
Map<String,EchoSignApiService.ParticipantInfo> |
global |
Map<String,EchoSignApiService.ParticipantInfo> |
global |
String senderEmail |
global |
Strängstatus |
Åtkomst |
Signatur |
---|---|
global |
DocumentInfo() |
- Global Class: ParticipantInfo
Åtkomst |
Namn |
---|---|
global |
Strängföretag |
global |
Strängmeddelande |
global |
Strängnamn |
global |
Strängstatus |
global |
Strängtitel |
Åtkomst |
Signatur |
---|---|
global |
ParticipantInfo() |
- Global Class: SendDocumentResult
Åtkomst |
Namn |
---|---|
global |
String documentKey |
global |
Undantagsfel |
global |
Sträng-URL |
Åtkomst |
Signatur |
---|---|
global |
SendDocumentResult() |
- Global Class: SigningUrl
Åtkomst |
Namn |
---|---|
global |
Strängmeddelande |
global |
String esignUrl |
global |
String simpleEsignUrl |
Åtkomst |
Signatur |
---|---|
Global |
|
Visar de huvudsakliga e-signeringsavtalsåtgärderna på gruppnivå, vilket gör att en åtgärd kan utföras på en uppsättning avtal. Den här klassen implementerar Salesforce-gränssnittet Database.batchable. Den kan behandla valfritt antal poster, som kommer att delas upp i uppsättningar om 5 och bearbeta varje uppsättning som en enskild transaktion, vilket gör att styrningsgränser respekteras.
Apex-grupptjänsten visas via följande anropsklass: echosign_dev1.EchoSignActionBatch
Parametrar
Du måste ange följande parametrar för att initiera en gruppåtgärd:
- En lista över avtalspost-ID som den angivna åtgärden ska utföras på: Åtgärden kan ha något av följande värden som stöds: Påminn, Skicka, Avbryt, Ta bort eller Uppdatera.
- Aktuellt användarsessions-ID: Krävs endast för en uppdateringsåtgärdstyp.
- Skickarens användarpost: Används för att meddela användaren via e-post när bulkbearbetningen har slutförts.
Användningsexempel
User submitterUser = UserInfo.getUserId();
EchoSignActionBatch batch = new EchoSignActionBatch( agreementIds, 'Remind', UserInfo.getSessionId(), submitterUser); Id syncProcessId = Database.executeBatch(batch, 5);
Tar in en SOQL-fråga och ett post-ID för avtalsmallen. Frågan körs för att hämta en uppsättning huvudobjektsposter, som sedan körs via den angivna avtalsmallen för att generera en avtalspost. Den här klassen implementerar Salesforce-gränssnittet Database.batchable. Den kan behandla valfritt antal poster, som kommer att delas upp i uppsättningar om 5 och bearbeta varje uppsättning som en enskild transaktion, vilket gör att styrningsgränser respekteras.
De posttyper som returneras av SOQL-frågan måste matcha den angivna huvudobjekttypen för avtalsmallen. För varje post anropas avtalsmalltjänsten.
Apex-grupptjänsten visas via följande anropsklass:
echosign_dev1.AgreementTemplateBatch
Parametrar
Du måste ange följande parametrar för att initiera en gruppåtgärd:
- SOQL-fråga att köra: Den måste innehålla post-ID som ett valt fält. Övriga fält är valfria.
- Post-ID för avtalsmall: Används tillsammans med huvudpost-ID för att ladda ett avtal.
Användningsexempel
String agreementTemplateId = [SELECT Id from echosign_dev1__Agreement_Template__c where Name = 'Default Template']; String soqlQuery = 'SELECT Id from Contact where Account.IsActive = true';
AgreementTemplateBatch batch = new AgreementTemplateBatch(soqlQuery, agreementTemplateId); Id syncProcessId = Database.executeBatch(batch, 5);
Tar in en lista över huvudobjektspost-ID och huvudobjekttyp, som sedan efterfrågas, och som sedan körs genom den angivna avtalsmallen för att generera en avtalspost. Den här klassen implementerar Salesforce-gränssnittet Database.batchable. Den kan behandla valfritt antal poster, som kommer att delas upp i uppsättningar om 5 och bearbeta varje uppsättning som en enskild transaktion, vilket gör att styrningsgränser respekteras.
Den angivna huvudobjekttypen måste matcha den angivna huvudobjekttypen för avtalsmallen. För varje post anropas avtalsmalltjänsten.
Apex-grupptjänsten visas via följande anropsklass:
echosign_dev1.AgreementTemplateServiceBatch
Parametrar
Du måste ange följande parametrar för att initiera en gruppåtgärd:
- Lista över ID för huvudposter.
- Avtalsmallens post-ID: Används tillsammans med huvudposterna för att ladda ett avtal.
- Huvudobjektnamn som ska efterfrågas för huvudposterna.
Användningsexempel
String agreementTemplateId = [SELECT Id from echosign_dev1__Agreement_Template__c where Name = 'Default Template'];
AgreementTemplateBatch batch = new AgreementTemplateServiceBatch(new List<Id>{'01p50000000HoMB'}, agreementTemplateId, 'Contact');
Id syncProcessId = Database.executeBatch(batch, 5);
Avtalsmalltjänst
Avtalsmalltjänsten visas som en Salesforce REST-webbtjänst av det hanterade paketet. Detta gör att externa system utanför Salesforce-organisationen kan läsa in avtal som baseras på befintliga avtalsmallar. Se artikeln Skapa REST API:er med Apex REST för mer information om hur du får åtkomst till och anropar anpassade REST Apex-tjänster inifrån Salesforce. Anrop måste innehålla ett giltigt sessions-ID för autentisering och auktorisering.
Webbtjänsten visas från följande URL:
https://<instance_name>.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id>?masterId=<master_id>&varName1=var Value1&varName2=varValue2
- Instansnamnet varierar beroende på din organisationsinstans.
- https://_<instance_name>_.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id> är en POST HTTP-metod för paketversion 20.0 och senare.
- Versioner före v20 använder en GET-metod.
Mall-ID
Den sista delen av URL:en är ID:t för avtalsmallposten i den aktuella Salesforce-organisationen som ska användas för att läsa in avtalet. Den här delen av URL:en är valfri. Om den utelämnas läses avtalsmallen som är markerad som standard in. Om mall-ID:t utelämnas och det inte finns något standardavtalsmall-ID returneras ett fel.
Mall-ID:t kan vara i formatet med 15 eller 18 tecken.
Master ID
Parametern masterId anger vilken huvudpost som ska användas för att läsa in avtalet från den specifika avtalsmallen. Den här parametern är valfri, men måste anges för alla avtalsmallar som anger en huvudobjekttyp och refererar till huvudobjektet i mallen.
Master-ID:t kan vara i formatet med 15 eller 18 tecken.
Körningsvariabler
Eventuella ytterligare parametrar används som körningsvariabler, som namnvärdepar, som används för att fylla i eventuella körningsvariabler som anges i avtalsmallen.
Resultat
REST-webbtjänsten returnerar ett LoadResult-objekt som innehåller följande fält:
- agreementId: om inläsningen av avtalet lyckades innehåller detta ID:t för den nyligen skapade avtalsposten.
- fel: om det uppstod något fel när avtalet lästes in, innehåller det här fältet ett detaljerat felmeddelande.
Bakgrundstjänstens kapacitet gör att paketanvändare kan anropa olika åtgärder på ett avtalsobjekt genom att uppdatera fältet Bakgrundsåtgärd (echosign_dev1 Background_Actions c) till motsvarande värde. När fältvärdet har ändrats från ett tomt värde eller ett annat värde till ett av följande värden, utförs åtgärden från en utlösare som ingår i det e-Sign-hanterade paketet.
- Påminn
- Skicka
- Avbryt
- Ta bort
- Uppdatera
Alla åtgärder körs i ett asynkront framtida läge, så statusen lagras i fältet Fel i avtalet.
- Avtalsstatusen uppdateras nu efter det att dokumenten och mottagarna har uppdaterats
- Före v21 ställdes statusen in först.
- Det signerade avtalsobjektet (som lagrar bildens URL-adresser) infogas inte alls
- Före v21 infogades det när alla andra uppdateringar slutförts
- Den största storleken på en begäran eller ett svar begränsas till 12 MB för asynkron Apex enligt Salesforce-gränserna: https://developer.salesforce.com/docs/atlas.en-us.210.0.apexcode.meta/apexcode/apex_gov_limits.htm
- Dokument som är större än 12 MB kan inte hämtas från Sign på grund av gränsen ovan.
- Avtalshändelsernas beskrivningar har ändrats. De matchar nu beskrivningarna som returneras av Signs API och revideringsrapporterna.
- Uppdateringsprocessen körs nu som en inbyggd Apex-batchprocess (en asynkron process) i Salesforce
- Tidigare var det en uppdatering med API-anrop utanför Salesforce
- Utlösare för statusuppdateringar som startar asynkrona processer fungerar inte längre eftersom Salesforce begränsar anrop från en asynkron process till en annan asynkron process
- Före v21 delades uppdateringar av avtalsattribut upp i separata uppdateringsanrop, nu uppdateras alla avtalsobjekt i en transaktion.
- Före v21 kunde misslyckade avtal endast utföras på nytt genom en manuell uppdatering i Salesforce
- Nu är uppdateringarna tillförlitligare eftersom Signs backend automatiskt försöker göra om misslyckade händelser ett visst antal gånger.
- Manuella uppdateringar uppdaterar nu alla aspekter av avtal, inklusive relaterade objekt.
- Push-avtal körs nu i asynkront läge och ytterligare attribut uppdateras på samma sätt som i vanliga uppdateringar.
- Det finns nya inställningar som gör att uppdateringar av olika aspekter av avtal kan inaktiveras.
- När en signerad PDF-fil lagras i Salesforce kommer det inte längre att finnas en beskrivning (-signerad eller -godkänd) i slutet av PDF-filnamnet.