Adobe Sign for Salesforce - Upgrade Guide

The introduction of Workflows into the Salesforce package requires additional access permissions to be enabled.

If you intend to use workflows,  then you must refresh the OAuth links

No manual configurations or system changes are required

Chatter must be enabled to install the v21.5.11 package

Before you start the upgrade process, verify that Chatter is enabled:

• Navigate to: Setup > Platform Tools > Feature Settings > Chatter > Chatter Settings
• If Chatter is Disabled, click the Edit button
  • Check the Enabled check box
  • Save the page

As of v21.0, the SIGN_Signed_Agreement__c object (label name: Signed Agreement") has been deprecated.

Customers that would like to obtain the signed agreement URL should use the REST API agreement call GET /agreements/{agreementId}/combinedDocument/url

Note: The returned URL from the API call is secured, and only viable for a limited time.

Below is the new sequence (as of v21.0) 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 

As of v21.x all asynchronous processes (which include automatic updates and data mappings) have been switched from future methods to queuebale, the new approach recommended by Salesforce.

Due to this change, any customizations in the subscriber org which add jobs to the Salesforce queue as part of the auto update and/or data mapping mapping process will fail with an error "System.LimitException: Too many queueable jobs added to the queue: 2"

This happens because a queuebale process can only add one child queueable job, which is already taken up by Adobe Sign (refer to the "Queueable Apex Limits" section here).

"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."

The symptom of this error is that the agreement status does not change and/or the data mapping does not run correctly. 

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 in the future, for example 1 hr later.

• 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.

After the upgrade is completed:

• Navigate to the Adobe Sign Admin tab 
• Click the Enable Automatic Status Updates link to reestablish the OAuth connection to Adobe Sign
• Click Enable
• Click Allow to allow access

In v20, the Callback user in Salesforce was not required be an Adobe Sign licensed user. 

The improvements to Push Mapping in v21 require that the Callback user have an active userID in the Adobe Sign account that is connected to the Salesforce organization.

v20 Customers using PushMapping should ensure that the Callback user is already provisioned in Adobe Sign prior to upgrading. Otherwise the PushMapping will stop functioning (until the user is provisioned) after upgrading to v21.

The Push Mapping functionality that automatically linked related objects using the setting ‘Copy Contact Account/Opportunity’ has been expanded to include Agreements sent from Salesforce.

• e.g. Agreements sent from Salesforce will automatically copy the first Contact recipient’s Opportunity lookup to the Agreement’s Opportunity lookup and first Contact recipient’s Account lookup to the Agreement’s Account lookup, if the agreements sent do not have any linked Account/Opportunity

Prior to v21, Chatter feeds were only populated when the agreement was sent from within Salesforce.

This update expands the Chatter feed to include agreements sent from outside Salesforce (Push Agreements)

Prior to v21, the Agreement View only updated the PDF image and URL after the first recipient completed their action.

The image and URL now update earlier, when in a Prefill status, or when Out for Signature to the first recipient.

No configuration is required to enable this functionality.

A new Agreement status of Waiting for My Delegation is being introduced to reflect when an agreement is waiting for the Sender to delegate the current recipient authority.

No configuration is required to enable this status.

The Agreement Template has a "Days Until Expiration" field (echosign_dev1__Days_Until_Expiration__c).  This is a numeric field, and has been deprecated in v21.

A new "Days Until Expiration" field (api name: echosign_dev1__Days_Until_Expiration2__c) has been added, but is a text field, allowing it to reference other fields in the Master Object (e.g.{!Expiry_Date__c})

When upgrading from a previous version, any form data mapped to the legacy expiration field is automatically copied to the new field, so no direct action is required.

The Account, Opportunity, and Contract fields are no longer available on the template page.

Admins can configure these fields in the template using the Map Data into Agreement Fields feature

Previously, Senders could define their absolute position in the signature stack as "Sender Signs First" or "Sender Signs Last".

This field is no longer available on the New Template pages. Senders have the option to insert themselves in any position of the signature stack.

The toggle to control the overall signature flow as "Sequential" or "Parallel" has been removed.

The new template style allows a fully configurable workflow that can be wholly sequential (Signer index 1 through 1+N), parallel (All Signer indexes are 1) or a mixture of sequential and parallel where the signature index is configured to the specific workflow.

Five settings have been deprecated in v21. All settings were in the Adobe Sign Settings section of Custom Settings.

The five settings are:

• Add Audit PDF to Attachment List—Enable this setting to attach the PDF of the audit trail to the Agreement record after the agreement is signed.
• Add Signed PDF as Separate Attachments—Enable this setting to attach the PDF of the signed agreements as separate attachments when there are multiple documents sent in a single transaction. To stop receiving the signed agreement as a merged PDF, please contact Adobe Support for assistance. 
• Add Supporting Files to Attachment List—Enable this setting to attach the PDFs of the supporting documents to the Agreement record after the agreement is signed. Through the supporting document fields in the agreement, the signers upload and attach the supporting documents to the agreement transaction.
• Add Signed PDF Link for Pushed Agreements (Enabled by Default)—This setting applies only for pushed agreements sent outside of Salesforce. Enable this setting to add a link for signed PDF to the Agreement record.
• Add Signed PDF for Pushed Agreements (Enabled by Default)—The setting applies to agreements sent from outside of Salesforce and pushed into Salesforce. Enable this setting to attach the signed PDF to the Agreement record. 

Customers that are using the above settings can configure the new setting under Adobe Sign Agreement Update Settings.

Version 20.9 of the Adobe Sign for Salesforce package shifts the authorization for the objects used in large document support from the Site user to a licensed “callback” user that is explicitly granted authority.

Please remove all existing permissions on sensitive or nonpublic objects assigned to the site user on the respective site used for Large files or Push Agreement.

For existing customers that are upgrading to 20.9 or beyond, the recommended process is to:

1. Upgrade the Adobe Sign for Salesforce package to 20.9 (or later)

2. Create the new Callback User profile

• Clone the Standard User profile
  • Name the new profile with an intuitive name (eg: Adobe Sign callback user)
  • Edit the profile
    • Under Custom Tab Settings, ensure that both Adobe Sign Admin tabs are set to Default On
    • Under Custom Object Permissions, enable all values for the Agreement object
    • Ensure these Visualforce pages are enabled 
      • echosign_dev1.EchosignAdmin
      • echosign_dev1.SalesforceOAuthPage
    • Enable the echosign_dev1. AgreementAttachmentDownloadService Apex class
  • Save the profile

3. Enable the Attachment Service Invocation Count for the Callback User profile

• Navigate to Object Manager > Agreement > Fields & Relationships 
• Click on the Field Label Attachment Service Invocation Count
• Click the Set Feild-Level Security button
• Enable both Visible and Read-Only for the Callback User profile
• Click Save

4. Create a new user using a standard Salesforce License

• Give the user an intuitive name (eg: Adobe Sign Callback)
• Assign a Salesforce license
• Assign the profile you created above
• Save the new user
• Verify the user to establish the known password
• Log out of Salesforce

5. Define the Callback User

• Log in to Salesforce as the Callback User
• Navigate to the Adobe Sign Admin page
• Click Link an Account under the Callback User header
  • An Allow Access? page is presented seeking to link the currently authenticated userID
• Click Allow
  • Verify that the callback user is correctly linked
• Log out of Salesforce

5. Update the existing Site 

• Log in as your Salesforce Admin
• Navigate to Platform Tools > User Interface > Sites and Domains > Sites
• Click the Site Label to open the site details
• Click the Public Access Settings button
• Mouse over the Enabled Apex Class Access link, and click the Edit button
  • Remove the AgreementAttachmentService class
  • Add the LargeFileDownloadService class
  • Save the page
• Click the Edit button on the Adobe Sign Callback Profile page
  • Remove all permissions explicitly assigned to Site User
  • Click Save

Version 20.9 of the Adobe Sign for Salesforce package shifts the authorization for the objects used in push agreement support from the Site user to a licensed “callback” user that is explicitly granted authority.

Please remove all permissions assigned to site user on the respective sites.

For existing customers that are upgrading to 20.9 or beyond, the recommended process is to:

1. Create the new callback user

• Clone the Standard User profile
• Name the new profile with an intuitive name (eg: Adobe Sign callback user)
• Save the profile

2. Create a new “callback” user using a standard Salesforce license

• Give the user an intuitive name (eg: Adobe Sign Callback)
• Assign a Salesforce license
• Assign the profile you created above
  • Save the new user
• Assign the Adobe Sign Integration User permission set to the callback user created above
  • Save the permission set

3. Upgrade the Adobe Sign for Salesforce package to 20.9 (or later)

4. Define the Callback User

• Once the upgrade is complete, log in to Salesforce as the Callback User
• Navigate to the Adobe Sign Admin page (App Launcher > Adobe Sign for Salesforce > Adobe Sign Admin)
• Click Link an Account under the Callback User header
  • An Allow Access? page is presented seeking to link the currently authenticated userID
• Click Allow
  • Verify that the callback user is correctly linked
• Log out of Salesforce

5. Update the existing Site 

• Log in to Salesforce as your admin user
• Navigate to Platform Tools > User Interface > Sites and Domains > Sites
• Click the Site Label to open the site details
• Click the Public Access Settings button
• Click the View Users button
• Click on the Full Name link of the Site user
• Mouse over the Permission Set Assignments link, and click the Edit Assignments button
• Remove the Adobe Sign Integration User permission set
• Remove all other permissions explicitly assigned to Site User
• Click Save

Organizations that use the Lightning interface in Salesforce must have My Domain enabled for v20 of the Adobe Sign package to function properly.

Organizations using the Classic interface are not required to have My Domain configured at this time.

v20 of the Adobe Sign package includes three new recipient roles:

• Acceptor - The Acceptor role is appropriate when the Recipient needs to acknowledge an acceptance of the Agreement without formally approving the content
  
• Form Filler - Designed specifically for customers that have a need to fill in form content during the signature process
  
• Certified Recipient - Certified Recipients can have no (zero) form fields assigned to them. During their "signature" process, they will be asked to either delegate, decline or acknowledge the agreement

To gain access to these roles, they must be added in a three step process (four steps if you want to localize the roles to non-english languages).

Enable the roles in Adobe Sign:

1. Log in to Adobe Sign as an administrator
2. Navigate to Account > Account Settings > Send Settings > Allowed Recipient Roles
3. Enable the roles you need to support
4. Click Save

Enable the roles in the custom settings (Salesforce):

1. Log into Salesforce as and administrator
2. Navigate to Setup > Platform Tools > Custom Code > Custom Settings
3. Click the label Adobe Sign Settings
4. Click the Manage button
5. Click New (or Edit, if you have configured settings before)

The setting values are: 

• Enable Acceptor Role - Recipients marked as acceptors accept the document. They may be required to enter field data
• Enable Form Filler Role - Form fillers are enabled to fill in field level data
• Enable Certified Recipient Role - Certified Recipients acknowledge the agreement, but do not sign. They may be required to fill in field data

The status values of the recipient and agreement objects are tied directly to the roles that are enabled in the system. If you are enabling additional roles, then you also need to add the associated role values to various object picklists.  The process is consistent for each object, with some variation in the values added depending on the context of the object.

The object > fields that need to be updated are:

• Recipient > Recipient Role
• Recipient > Status
• Add Recipient > Recipient Role
• Agreement > Agreement Status
• Field Mapping > Map on Events
• File Mapping > Map on Events

The field values that should be added are:

The process to add the values and localize them is consistent across all objects.

Below is the process for Recipient > Recipient Role, and can be applied for each object in turn.

Add the roles to the Recipient picklist:

Once the new roles are enabled, the pick list values for the fields must be updated to include them.

1. Navigate to Setup > Platform Tools > Objects and Fields > Object Manager

2. Select Recipient form the list on the left

3. Select Fields & Relationships form the left rail

4. Select the Recipient Role field

5. Scroll down the page to the Values section, and select New

6. Enter the new Role values that you have enabled. Valid values are:

• Acceptor
• Form Filler
• Certified Recipient
• Delegate to Acceptor
• Delegate to Form Filler
• Delegate to Certified Recipient

7. Click Save when done

The resulting picklist should look like this (assuming you added all roles):

Localize the role statuses through the translation workbench:

1. Navigate to: Setup > Platform Tools > User Interface > Translation Workbench > Translate

• Select the Language that you want to localize to
• Select the Setup Component as Picklist Value
• Select Object as Recipient

• In the Master Picklist table, expand the Recipient Role folder

• Double-click the column space next to the English status to open the text field where the translation can be entered, and enter the appropriate localized value 

2. Click Save when done

The Document field of the Agreement object contains a hyperlink to the agreement. There are two changes to this field in the v20 release:

• The hyperlink text no longer has the status of the agreement appended to it. 

Prior to v20, hyperlink text contained the agreement name and the status “- signed” or “- approved” appended to the end:

Version 20 removes the appended status, leaving just the agreement name:

• Prior to v20, the Document field contained the hyperlink only when the agreement transaction was completed successfully. 

In the v20 package, the Document field always contains the latest PDF version of the Agreement:

The Help Text for the Chatter event Post when Agreement Sent can be updated to remain consistent with the new recipient roles.

1. Navigate to Setup > Platform Tools > Custom Code > Custom Settings
2. Click the label Adobe Sign Chatter Settings
3. Click the Edit link next to Post when Agreement Sent

4. Update the Help Text to read: Post Chatter update when agreement is sent for signature/approval/acceptance/ form-filling/delivery.

5. Click Save

As Adobe Sign has expanded, the infrastructure has shifted to more robust data centers, and this has caused some changes in the IP ranges that your Salesforce organization needs to trust to ensure optimal communication between the services.

Below are the incremental changes from v18 to v19.  Ensure that any sites configured are updated in addition to the core trusted networks.

With the v19 release, the organization's CRUD and FLS settings on both standard and custom objects are enforced. The App checks object and field level, read and write permissions. If the user doesn't have appropriate access, a permission denied error is shown.

After upgrading to v19, if a salesforce users gets permission denied error similar to:

Permission denied. Unable to insert field echosign_dev1__Contract__c in object: echosign_dev1__SIGN_Agreement__c

then the salesforce admin needs to add both read and write permissions to the agreement object, and for any custom fields they have created, to the relevant profiles.

• Navigate to: Setup > Administration > Users > Profile > {Profile name} 
• Scroll down to the Custom Field-Level Security section and click the View action for the Agreement object
• Provide Read and Edit access to relevant fields

There is one deprecated custom settings in version 19: 

• Enable Send Written Signature To Fax – Adobe Sign no longer supports sending an agreement to a phone number. Written signatures instead follow the same process as electronic signature until the first signer has to apply their signature. Then they download, sign, scan and upload that file back to Adobe Sign. 
  

>> More details on the Written Signature

There is one new tab in v19: Agreement Types

• A new custom object called Agreement Type (Agreement_Type__c) has been introduced to define an agreement type. It has one standard Name field, but additional fields can be added later to define your own custom fields. An object is used instead of a simple text field because this allows a unique record to define a type, which is more flexible and extensible. It also separates the type from the agreement template and the agreement, so the agreement template can change without being tied to the type and multiple templates can set the same type.
• A new parent lookup field called Agreement Type (Agreement_Type__c) has been added to the Agreement Template object, which points to the Agreement Type object. The field will appear in the Agreement Template Detail section on the agreement template page.
• A new parent lookup field called Agreement Type (Agreement_Type__c) has been added to the Agreement object, which points to the Agreement Type object. The field will not appear on the Agreement editor page.

Add the parent lookup field called Agreement Type (Agreement_Type__c) to the Agreement Template Page Layout:

• Navigate to Setup > Platform Tools > Objects and Fields > Object Manager > Agreement Template > Page Layout > Agreement Template Layout
• Select the Fields option
• Click the Agreement Type field and drag it onto the page layout
• Click Save

Upgrading customers are strongly recommended to adopt use of the Lightning page to ensure that new features are available as development continues to improve the product.

That said, there may be very good reasons you need to stay on one of the older page layouts. Refer to the guide on adjusting your Salesforce page layout to determine if moving to the Lightning page is best.

When the Adobe Sign application for Salesforce is upgraded from versions lower than v14 to the current build, users might not be able to perform actions such as Delete, Cancel, View, Remind, or Update on the existing agreements that were sent by other users before upgrade. 

Users may prompt an error when one of these actions is executed, similar to:

“INVALID_DOCUMENT_KEY” or “An internal server error has occurred”

This happens due to a legacy document key style that was used in versions of the application before version 14.

A one-time migration of those legacy keys is required. To this end, a new affordance as described below:

After completing the set-up steps, the following links will be available on the Adobe Sign Admin page:

• Fetch Missing Document Keys – Clicking this link will perform a batch action for fetching missing document keys for existing agreements
• Update Legacy Document Keys - Clicking this link will flush out the existing legacy document keys and fetch the new document keys for all the agreements existing in the org. 

In case there are any agreements that don’t have associated document keys, it will fetch document keys for them as well

Once the agreements have new document keys, users will be able to perform all agreement actions on existing agreements sent by other users.

Add Signed PDF Link for Pushed Agreement - This setting applies only for pushed agreements sent outside of Salesforce. Enable this setting to add a link for signed PDF to the Agreement record.

Any user directly interacting with Group Mappings, will need to ensure that they have the correct permissions.

• This is best achieved by adding the Adobe Sign Admin permission set to the user
• The user's profile must have the View Setup and Configuration permission enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Any user that uses the Adobe Sign API will require the Adobe Sign User permission set.

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

For users to interact with the Self Signing component for Adobe Sign:

• The Adobe Sign User permission set should be applied to the user
• The Salesforce Contact object must have Read enabled
  • The Email field on the Contact object must have Read enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that interact with the Agreement Templates require:

• The Adobe Sign Admin permission set to be added
• Access to all fields for the specified Master Object in Salesforce

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that trigger batch actions will require:

• The Adobe Sign Admin permission set

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Any user that uses Adobe Sign through S1 Mobile will require:

• The Adobe Sign User permission set
• The Salesforce Opportunity object must have Read enabled
  • The Name field on the Opportunity object must have Read enabled
    

• The Salesforce Account object must have Read enabled
  
  • The Name field on the Account object must have Read enabled
    

• The Salesforce Contract object must have Read enabled
  
  • The Name field on the Contract object must have Read enabled
    
  • The Contract Number field on the Contract object must have Read enabled
    

• The Salesforce Contact object must have Read enabled
  
  • The Name field on the Contact object must have Read enabled
    
  • The Email field on the Contact object must have Read enabled
    

• The Salesforce Lead object must have Read enabled
  
  • The Name field on the Lead object must have Read enabled
    
  • The Email field on the Lead object must have Read enabled

• The Salesforce Document object must have Read enabled
  
  • The Name field on the Document object must have Read enabled
    
  • The Type field on the Document object must have Read enabled
  • The Content Type field on the Document object must have Read enabled
    
  • The Body field on the Document object must have Read enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that need access to the Administration tab require the Adobe Sign Admin permission set.

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that leverage the Publisher actions require:

• The Adobe Sign User permission set
• The system permission Insert System Field Values for Chatter Feeds enabled 

• The Salesforce Opportunity object must have Read enabled
  • The Name field on the Opportunity object must have Read enabled
    

• The Salesforce Account object must have Read enabled
  
  • The Name field on the Account object must have Read enabled

• The Salesforce Contact object must have Read enabled
  
  • The Name field on the Contact object must have Read enabled
    
  • The Email field on the Contact object must have Read enabled
    

• The Salesforce Lead object must have Read enabled
  
  • The Name field on the Lead object must have Read enabled
    
  • The Email field on the Lead object must have Read enabled

• The Salesforce Document object must have Read enabled
  
  • The Name field on the Document object must have Read enabled
    
  • The Type field on the Document object must have Read enabled
  • The Content Type field on the Document object must have Read enabled
    
  • The Body field on the Document object must have Read enabled
• The Salesforce Quote object must have Read enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that edit Templates will require:

• The Adobe Sign Admin permission set
• The Salesforce Contact object must have Read enabled
  
• The Salesforce Lead object must have Read enabled
• The Salesforce Document object must have Read enabled
  
  • The URL field on the Document object must have Read enabled
    

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

The Agreement Template Processor requires:

• The Adobe Sign Admin permission set
• The Salesforce Contact object must have Read enabled
  
  • The Mobile Phone field on the Contact object must have Read enabled
    

• The Salesforce Lead object must have Read enabled
  
  • The Mobile Phone field on the Lead object must have Read enabled
    

• The Salesforce Opportunity object must have Read enabled
• The Salesforce Account object must have Read enabled
  
• The Salesforce Group object must have Read enabled
  
• The Salesforce Quote object must have Read enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that edit agreements require:

• The Adobe Sign User permission set

• The Salesforce Lead object must have Read enabled
  • The Company field on the Lead object must have Read enabled

• The Salesforce Event object must have Create enabled
  
  • All fields on the Event object must have Modify enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that edit the Merge Mappings require:

• The Adobe Sign Admin permission set
• Any object/field that the merge maps accesses requires Read and Modify enabled
  

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that leverage merge mappings require:

• The Adobe Sign User permission set
• The Salesforce Account object must have Read enabled
  
  • The Name field on the Account object must have Read enabled

• The Salesforce Opportunity object must have Read enabled
  
  • The Name field on the Opportunity object must have Read enabled

• Any object/field that the merge maps accesses requires Read and Modify enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Users that edit the Data Mappings require:

• The Adobe Sign Admin permission set
• Any object/field that the merge maps accesses requires Read and Modify enabled
  

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Data Mapping processing requires:

• The Adobe Sign Integration User permission set
• Any object/field that the data maps accesses requires Read and Modify enabled
  
• The Salesforce Attachment object requires access based on the parent record

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

The Chatter integrations requires:

• The Adobe Sign Integration User permission set
• The Salesforce system permission Insert System Field Values for Chatter Feeds enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

Push Agreements require that the linked Callback User have:

• The Adobe Sign Integration User permission set

• The Salesforce Account object must have Read and Create enabled

• The Salesforce Contract object must have Read and Create enabled
  

• The Salesforce Opportunity object must have Read and Create enabled
  

• The Salesforce Contact object must have Read and Create enabled
  • The Name field on the Contact object must have Read and Modify enabled
    
  • The Email field on the Contact object must have Read and Modify enabled
  • The Account field on the Contact object must have Read and Modify enabled
    

• The Salesforce Lead object must have Read and Create enabled
  • The Name field on the Lead object must have Read and Modify enabled
    
  • The Email field on the Lead object must have Read and Modify enabled
  • The Company field on the Lead object must have Read and Modify enabled

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason:

The Callback User must be configured and linked:

• The Adobe Sign Integration User permission set added
• The Callback User profile must enable the Administrative Permission for Modify Metadata

Additionally, the Site profile must be edited to:

• Add the LargeFileDownloadService class
• Remove the AgreementAttaqchmentService class

Below is an explicit listing of the objects, and the required fields, if using the permission set is not acceptable for any reason: