User Guide Cancel

Adobe Acrobat Sign for Salesforce: Developer Guide

  1. Adobe Acrobat Sign Integrations
  2. What's New
  3. Product Versions and Lifecycle
  4. Acrobat Sign for Salesforce
    1. Install the Package
    2. Configure the Package
    3. User Guide
    4. Enable Digital Authentication
    5. Developer Guide
    6. Advanced Customization Guide
    7. Field Mapping and Templates Guide
    8. Mobile App User Guide
    9. Flows Automation Guide
    10. Document Builder Guide
    11. Configure Large Documents
    12. Upgrade Guide
    13. Release Notes
    14. FAQs
    15. Troubleshooting Guide
    16. Additional Articles
  5. Acrobat Sign for Microsoft
    1. Acrobat Sign for Microsoft 365
      1. Installation Guide
    2. Acrobat Sign for Outlook
      1. User Guide
    3. Acrobat Sign for Word/PowerPoint
      1. User Guide
    4. Acrobat Sign for Teams
      1. User Guide
      2. Live Sign Guide
      3. Mobile User Guide
      4. Release Notes
      5. Microsoft Teams Approvals
    5. Acrobat Sign for Microsoft PowerApps and Power Automate
      1. User Guide
      2. Release Notes
    6. Acrobat Sign Connector for Microsoft Search
      1. User Guide
      2. Release Notes
    7. Acrobat Sign for Microsoft Dynamics 
      1. Overview
      2. Dynamics Online: Installation Guide 
      3. Dynamics Online: User Guide 
      4. Dynamics On-Prem: Installation Guide 
      5. Dynamics On-Prem: User Guide
      6. Dynamics Workflow Guide
      7. Dynamics 365 for Talent
      8. Upgrade Guide
      9. Release Notes
    8. Acrobat Sign for Microsoft SharePoint 
      1. Overview
      2. SharePoint On-Prem: Installation Guide
      3. SharePoint On-Prem: Template Mapping Guide
      4. SharePoint On-Prem: User Guide
      5. SharePoint On-Prem: Release Notes
      6. SharePoint Online: Installation Guide
      7. SharePoint Online: Template Mapping Guide
      8. SharePoint Online: User Guide
      9. SharePoint Online: Web Form Mapping Guide
      10. SharePoint Online: Release Notes
  6. Acrobat Sign for ServiceNow
    1. Overview
    2. Installation Guide
    3. User Guide
    4. Release Notes
  7. Acrobat Sign for HR ServiceNow
    1. Installation Guide (Deprecated)
  8. Acrobat Sign for SAP SuccessFactors
    1. Cockpit Installation Guide (Deprecated)
    2. Recruiting Installation Guide (Deprecated)
    3. Recruiting User Guide
    4. Cloud Foundry Installation Guide
    5. Release Notes
  9. Acrobat Sign for Workday
    1. Installation Guide
    2. Quick Start Guide
    3. Configuration Tutorial
  10. Acrobat Sign for NetSuite
    1. Installation Guide
    2. Release Notes
  11. Acrobat Sign for SugarCRM
  12. Acrobat Sign for VeevaVault
    1. Installation Guide
    2. User Guide
    3. Upgrade Guide
    4. Release Notes
  13. Acrobat Sign for Coupa BSM Suite
    1. Installation Guide
  14. Acrobat Sign Developer Documentation
    1. Overview
    2. Webhooks
    3. Text Tags

Overview

Adobe Acrobat Sign for Salesforce: Developer Guide is designed to help Salesforce developers learn about the objects and parameters that are required to integrate your Salesforce package with Adobe Acrobat Sign.

Refer to the topics on this document to learn about:

Caution:

Adobe Acrobat Sign for Salesforce objects may change in a future release. If you build a custom solution that depends on objects that are changed, you may be required to update your customization.

Developer guidelines

  • If you need to know when the agreement is fully signed, implement an Apex trigger on the echosign_dev1__SIGN_Agreement__c object, after or before update (depending on the use case and requirements). When the echosign_dev1__Status__c field changes to Signed or Approved or other final statuses, the agreement is completed. 
  • If you need to know when each individual signed PDF is inserted, if for example you need to get each intermediate signed PDF, then implement an Apex trigger on the Attachment or ContentVersion objects, after insert, and watch for a parent agreement and a name which ends in "- signed.pdf" or "- approved.pdf" or other final status
  • If you need to know when an individual recipient has signed or approved, implement an Apex trigger on the echosign_dev1__SIGN_Recipients__c object, after or before update (depending on the use case and requirements). When the echosign_dev1__Status__c field changes Signed or Approved or other final statuses, the recipient is completed.  
  • If you need to know when a particular event which is part of the signing process occurs, such as an agreement being sent for signature or a reminder being sent, a trigger can be created on agreement events object (echosign_dev1__SIGN_AgreementEvent__c) and check for the type of the event
  • The Final Agreement Status names for a completed agreement are: "Signed", "Approved", "Accepted", "Form-Filled", and "Delivered"
  • The Final Agreement Status names for a terminated agreement are: "Cancelled / Declined", "Canceled / Declined", "Expired"

Order of updates

In v21 the order of updates has changed. Below is the sequence in which the agreement and its related objects are updated:

  1. Attachments 
  2. Recipients 
  3. Agreement (status and its other attributes)
  4. Agreement Events 
  5. Chatter Feeds 

Apex Services

Apex Method in use

Starting Acrobat Sign for Salesforce V 21.0, all asynchronous processes (including automatic updates and data mappings) use the Queueable method instead of the Future method, as recommended by Salesforce.
With this change, all customization jobs that are added to the Salesforce queue for auto-update or data mapping process will fail with this error: "System.LimitException: Too many queueable jobs added to queue:2."

The failure happens because a queueable process can only add one child queueable job, which is already taken up by Acrobat Sign. For details, refer to Queueable Apex Limits

When the agreement status does not change, or the data mapping does not run correctly, it may display this error: "When chaining jobs, you can add only one job from an executing job with System.enqueueJob, which means that only one child job can exist for each parent queueable job. Starting multiple child jobs from the same queueable job isn’t supported."

To resolve this error, look for the offending trigger, process builder, or workflow, and deactivate it or switch it to use a synchronous call or schedule it for later.

Agreement Template Service

The agreement template service is exposed as a global Apex service by the managed package. This allows Apex code outside of the managed package to load agreements based on existing agreement templates. The class and all exposed methods are marked as global to allow such access.

The Apex service is exposed via this invocation class: echosign_dev1.AgreementTemplateService

Methods

global

static Id load()

Loads an agreement using an agreement template marked as default and which has no master object type.

global

static Id load(String templateId)

Loads an agreement using the specified agreement template ID, which has no master object type.

 

global

static Id load(String templateId, String masterId)

Loads an agreement using the specified agreement template ID and the specified master record ID, whose type must match the master object type configured in the specified agreement template.

global

static Id load(String templateId, String masterId, Map<String,AgreementTemplateVariable> agreementTemplateVariables)

Loads an agreement using the specified agreement template ID and the specified master record ID, whose type must match the master object type configured in the specified agreement template. Also passes in the specified runtime variables as name value pairs.

 

global

static List<AgreementTemplateService.AgreementTemplateBasicInfo> getAgreementTemplateList(AgreementTemplateListOptions options)

Get a list of agreement templates based on filtering options. Return an empty list if no agreement template is the found with the filtering options.

global

static AgreementTemplateService.AgreementTemplateDetails getAgreementTemplateDetails(String templateId)

Get agreement template details for the specified agreement template ID.

Return an empty object if no agreement template found.

global

static String getAgreementTemplateUrl(String templateId)

Get the url to edit the agreement template given the agreement template ID.

global

static String getNewAgreementTemplateUrl()

Get the url to create a new Agreement Template in Adobe Sign.

 Constructors

Access

Signature

global

AgreementTemplateListOptions()

global

AgreementTemplateListOptions(String masterObjectType, Boolean isActive, Boolean hasAttachment, Boolean hasRecipient, Boolean autoSend)

Global Class properties

Global Class: AgreementTemplateService.AgreementTemplateListOptions

Access

Name

global

masterObjectType

global

isActive

global

hasAttachment

global

hasRecipient

global

autoSend

Note:

No filter is applied on its corresponding field when querying agreement templates if a field listed above has null value.

GLOBAL CLASS: AGREEMENTTEMPLATESERVICE.AGREEMENTTEMPLATEBASICINFO

Access

Name

global

name

global

recordId

global

url

global

isDefault

global

daysUntilExpiration

global

language

GLOBAL CLASS: AGREEMENTTEMPLATESERVICE.AGREEMENTTEMPLATEDETAILS

Access

Name

global

message

global

ccList

global

dataMappingName

global

mergeMappingName

global

url

global

recipients

GLOBAL CLASS: AGREEMENTTEMPLATESERVICE.RECIPIENTINFO

Access

Name

global

recipientRole

global

recipientType

global

recipientName

global

signOrder

Runtime Variables

The echosign_dev1.AgreementTemplateVariable global class has the following two global fields:

  • name: The variable name, which must match a runtime variable name configured in the agreement template.
  • value: The variable value used during the template load. The value depends on where the variable was used. For example, for a recipient, it has to be a contact, lead, or user record ID or an email. For a document variable, it must be an attachment record ID.

Result

Every method either returns the ID of the newly created agreement record or throws an exception with a detailed error message if something goes wrong during the load operation.

API Services

The Adobe e-Sign API template service is exposed as a global Apex service by the managed package. This allows Apex code outside of the managed package to invoke a set of Adobe e-Sign API's through these wrappers. The wrappers greatly simplify the API invocation because consumers do not need to create request and response data model. Also consumers do not need to handle the transformation of Salesforce data into e-Sign data models. Most of the complexity is abstracted from the consumer. For example, to send an agreement the consumer just passes in the agreement record ID, the service will handle querying it, extracting all of the relevant data, passing it on the API and parsing the result.

The class and all exposed methods are marked as global to allow such access.

  • v17 and below invokes SOAP API's
  • v18 and above invokes REST API's

The Apex service is exposed through the following invocation class: echosign_dev1.EchoSignApiService

Apex API Enhancement for Alternate Recipients

Starting version 24.14 or later, the updated Apex API allows you to replace or add alternate recipients and is accessible within the global class "EchoSignApiService," two new elements have been introduced:

  • A global function:

    /**

    * Input params:

    * toBeChangedRecipientId: SIGN_Recipient__c Id

    * newRecipientStr: JSON string of SIGN_Recipient__c of a new recipient for recipient replacement or alternate

    * changeType: REPLACE or ALTERNATE

    */

    global static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, RECIPIENT_CHANGE_TYPE changeType )

  • A global enumeration: RECIPIENT_CHANGE_TYPE {REPLACE, ALTERNATE}

Sample code to call this API for recipients (recipient type as Email)

// first query all the recipients associated with the agreement

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;

// find the recipient that needs to be replaced or an alternate

// in this case, find the recipient by its email.

// More conditions can be added to find the recipient that is to be replaced or needs an alternate.

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;

    }

}

// update emal address for new recipient

newRecipient.echosign_dev1__Email_Address__c = ''someNewUser@abc.com';

// serialize it to json string

String newRecipientStr = JSON.serialize(newRecipient);

Try {

    echosign_dev1.EchoSignApiService.changeRecipient(replacedRecipient.Id, newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE.REPLACE);

} catch (Exception ex) {

    // handle the exception and rethrow if needed

}

Methods

global

static void cancelDocument(Id agreementId)

Cancels the agreement with the specified agreement ID.

global

static echosign_dev1.EchoSignApiService.DocumentInfo getDocumentInfo(Id agreementId)

Retrieves detailed information for the specified agreement ID.

global

static List<EchoSignApiService.SigningUrl>

getSigningUrls(Id agreementId) 

Retrieves all signing URLs for the specified agreement ID.

global

static void removeDocument(Id agreementId)

Cancels the agreement with the specified agreement ID and deletes the agreement record in Salesforce (the agreement isn't removed from the Adobe e-Sign account).

global static void replaceSigner(Id replacementRecipientId)
Deprecated with V 24.14. The package versions prior to v24.14 can still use them as they rely on V5 APIs.
global static void replaceSigner(Id replacementRecipientId, String message)
Deprecated with V 24.14. The package versions prior to v24.14 can still use them as they rely on V5 APIs.

global

static echosign_dev1.EchoSignApiService.

SendDocumentResult sendDocument(Id agreementId)

Sends out the agreement with the specified agreement ID, returns the result with the document key and URLs.

global

static void sendReminder(Id agreementId)

Sends a reminder to the current signer for the specified agreement ID.

global static void updateAgreement(Id agreementId)  Updates the agreement with the specified agreementId
global static EchoSignApiService.AgreementViewUrl getViewAgreementUrl(Id agreementId)
Retrieves view/manage page from Sign for the specified agreement ID, which has a view property.
Note: For security reasons, the generated agreement URL only has a temporary lifespan so it generates a REST-HTTPS call to get a fresh URL from Adobe Sign services.
global static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE changeType ) Available starting v24.14, this API changes the agreement recipients.

Inner Classes

  • Global Class: DocumentHistoryEvent
PROPERTIES (2)

Access

Name

global

String eventType

global

String participantEmail

CONSTRUCTORS (1)

Access

Signature

global

DocumentHistoryEvent()

  • Global Class: DocumentInfo
PROPERTIES (5)

Access

Name

global

Map<string,list> historyByEmail

global

Map<String,EchoSignApiService.ParticipantInfo>
participantsByEmail

global

Map<String,EchoSignApiService.ParticipantInfo>
participantsByName

global

String senderEmail

global

String status

CONSTRUCTORS (1)

Access

Signature

global

DocumentInfo()

  • Global Class: ParticipantInfo
PROPERTIES (5)

Access

Name

global

String company

global

String email

global

String name

global

String status

global

String title

CONSTRUCTORS (1)

Access

Signature

global

ParticipantInfo()

  • Global Glass: SendDocumentResult
PROPERTIES (3)

Access

Name

global

String documentKey

global

Exception error

global

String url

CONSTRUCTORS (1)

Access

Signature

global

SendDocumentResult()

  • Global Class: SigningUrl
PROPERTIES (3)

Access

Name

global

String email

global

String esignUrl

global

String simpleEsignUrl

CONSTRUCTORS (1)

Access

Signature

Global

 

Apex Batch Services

Exposes the main e-Sign agreement actions on a bulk level, allowing an operation to be performed on a set of agreements. This class implements the Salesforce Database.Batchable interface. It can process any number of records, which will be broken down into sets of 5 and processing each set as an individual transaction, which allows governor limits to be respected.

The Apex batch service is exposed through the following invocation class: echosign_dev1.EchoSignActionBatch

Parameters

You must specify the following parameters to initialize a batch operation:

  • A list of the agreement record IDs on which to perform the provided action: The action can have any of the following supported values: Remind, Send, Cancel, Delete, or Update.
  • Current user session ID: Required only for an update action type.
  • Submitter user record: It's used to notify the user through an email once the bulk processing completes.

Usage Example

User submitterUser = UserInfo.getUserId();

EchoSignActionBatch batch = new EchoSignActionBatch( agreementIds, 'Remind', UserInfo.getSessionId(), submitterUser); Id syncProcessId = Database.executeBatch(batch, 5);

Agreement Template Batch

Takes in a SOQL query and an agreement template record ID. The query is executed to get a set of master object records, each of which is then run through the provided agreement template to generate an agreement record. This class implements the Salesforce Database.Batchable interface. It can process any number of records, which will be broken down into sets of 5 and processing each set as an individual transaction, which allows governor limits to be respected.

The record types returned by the SOQL query must match the provided agreement template master object type. For each record, the agreement template service is invoked.

The Apex batch service is exposed through the following invocation class:

echosign_dev1.AgreementTemplateBatch

Parameters

You must specify the following parameters to initialize a batch operation:

  • SOQL query to execute: It must contain the record ID as a selected field. Other fields are optional.
  • Agreement template record ID: It's used with the master record ID to load an agreement.

Usage Example

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);

Agreement Template Service Batch

Takes in a list of master object record ID's and the master object type, which are then queried, and each of which is then run through the provided agreement template to generate an agreement record. This class implements the Salesforce Database.Batchable interface. It can process any number of records, which will be broken down into sets of 5 and processing each set as an individual transaction, which allows governor limits to be respected.

The master object type provided must match the provided agreement template master object type. For each record, the agreement template service is invoked.

The Apex batch service is exposed through the following invocation class:

echosign_dev1.AgreementTemplateServiceBatch

Parameters

You must specify the following parameters to initialize a batch operation:

  • List of master record IDs.
  • Agreement template record ID: It is used with the master records to load an agreement.
  • Master object name to query for the master records.

Usage Example

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);

REST Services

Agreement Template Service

The agreement template service is exposed as a Salesforce REST web service by the managed package. This allows external systems outside of the Salesforce org to load agreements based on existing agreement templates. Please refer to the Creating REST APIs using Apex REST article for more details on how to access and invoke custom REST Apex services from within Salesforce. Invocations must provide a valid session ID for authentication and authorization.

The web service is exposed from the following URL:

https://<instance_name>.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id>?masterId=<master_id>&varName1=var Value1&varName2=varValue2

Note:
  • The instance name will vary depending on your org instance.
  • https://_<instance_name>_.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id> is a POST HTTP method for package versions 20.0 and later.
    • Versions prior to v20 use a GET method.

Template ID

The last part of the URL is the ID of the agreement template record in the current Salesforce organization which should be used to load the agreement. This part of the URL is optional. If omitted, the agreement template marked as the default will be loaded. If the template ID is omitted and no default agreement template ID exists, an error will be returned.

The template ID can be in the 15 or 18 character format.

Master ID

The masterId parameter specifies which master record should be used to load the agreement from the specific agreement template. This parameter is optional, but must be specified for any agreement template which specifies a master object type and references that master object in the template.

The master ID can be in the 15 or 18 character format.

Runtime Variables

Any additional parameters are used as runtime variables, as name-value pairs, used to populate any runtime variables specified in the agreement template.

Result

The REST web service returns a LoadResult object which contains the following fields:

  • agreementId : If the agreement load operation was successful, this contains the ID of the newly created agreement record.
  • error : If there was any error during the loading of the agreement, this field will contain a detailed error message.

Background Service

The background service capability allows package consumers to invoke various actions on an agreement object by updating the Background Action (echosign_dev1 Background_Actions c) field to the corresponding value. Once the field value is changed from a blank value or another value to one of the following values, the action is kicked off from a trigger that is part of the e-Sign managed package.

  • Remind
  • Send
  • Cancel
  • Delete
  • Update

All of the actions execute in an asynchronous future mode, so the status will be stored in the Error field on the agreement.

Backward Compatibility Changes

  • The agreement status is now updated after the documents and recipients are updated
    • Prior to v21 the status was set before.
  • The Signed Agreement object (which stores the Image URLs) is now not inserted at all
    • Prior to v21 it was inserted after all of the other updates were completed
  • Maximum size of callout request or response is limited to 12MB for asynchronous Apex as per Salesforce governor limits: https://developer.salesforce.com/docs/atlas.en-us.210.0.apexcode.meta/apexcode/apex_gov_limits.htm
    • Documents larger than 12MB can not be fetched from Sign due to above limit.
  • Agreement event descriptions have changed. It now matches the description as returned by Sign API and with the audit reports.
  • The update process is now run as a native Apex batch process (which is an asynchronous process) within Salesforce
    • Before it was an update using API calls from outside of Salesforce
    • Triggers off these status updates which kick off async processes no longer work because Salesforce limits calling another async process from an already running async process
  • Prior to v21, the agreement attribute updates were split up into separate update calls, now agreement object is updated all in one transaction.
  • Prior to v21, failed agreements could be only retried by doing a manual update from within Salesforce
    • Now updates are more reliable as the Sign backend automatically retries failed events for a specified number of times.
  • Manual updates now update all aspects of agreements including the related objects.
  • Push agreements now run in async mode, same as regular updates and additional attributes are updated, the same as regular updates.
  • There are new settings introduced to enable disable updates of different aspects of the agreement.
  • When a signed PDF is stored in Salesforce, there will no longer be a descriptor (-signed or -approved) appended to the end of the PDF file name.

Get help faster and easier

New user?