Skip to main content
arrow-left Back to Docusign.com

In a previous data ingestion effort by my former team, we integrated account data from another system into Salesforce. As part of this process, we established a mapping between Salesforce Accounts and DocuSign CLM Accounts using a naming convention that combines the account Name and ID. (not same as salesforce account Id but another field)

However, we’ve encountered a problem: although the migrated account folders follow the correct naming convention, they are not being linked to the corresponding existing Salesforce Accounts. Instead, new Salesforce Accounts are being created, resulting in data inconsistency.

Expected Behavior:

  • Migrated DocuSign CLM account folders that match the existing naming convention should be mapped to the corresponding Salesforce Account.

Actual Behavior:

  • Despite matching names and IDs, new Salesforce Accounts are being created instead of linking to the existing ones.

Potential Cause (Hypothesis):

  • The mapping logic might be relying on more than just the folder name (e.g., internal IDs, metadata mismatches, or case sensitivity).

Has anyone came across this issue? Any help is greatly appreciated.

​@Servesh 

Your assumption is correct, the actual mapping is not determined by the folder name, but relies on the External Object Storage (EOS) ID, which needs to be added in order to allow Salesforce to successfully search for the folder in CLM.

When doing the data migration to CLM, you also need correlating Salesforce ID for the specific object to map it to the EOS folder. Otherwise they are not connected and Salesforce will create a new EOS folder as the ID cannot be found.

This Docusign Support article will provide the required information in the “Find or Create EOS Parent Folder” section:

Find or Create EOS Parent Folder: Finds the next highest External Object Storage (EOS) folder in the folder tree, above the subfolder that you specify. The folder is based on a specific object type (for example, Salesforce.Opportunity). If an EOS folder does not exist, the product creates it and associates it to the specified folder.

  • Step Name: (Required text field) Sets a name for the workflow step. The product automatically provides a unique name. We recommend keeping the default name.
  • Step Description: (Text field) Describes the step. The description displays below the step in the workflow designer and in the process monitor. A meaningful description is helpful during workflow administration and troubleshooting.
  • Folder Id: Specifies the ID of the record that is associated with the folder.
  • Type: Specifies the Salesforce object type for the folder that you want to find or create. Use the format Salesforce.object (for example, Salesforce.Account).
  • Folder Name: Specifies the name of the folder to create if there is no existing associated folder.
  • Folder Path: Specifies the path where the folder will be created.
  • Output: Stores the step results in a new variable or existing variable for use later in the workflow.
  • Last action output conditions: Unselected, Success, Failure

Thanks ​@Michael.Rave , can you suggest how can I update the mapping attribute to null after moving one folder into another?

​@Servesh 

The best approach is to include the additional workflow step into the migration workflow or create a new workflow that will do this for the documents that were migrated. This will require a second CSC with the IDs from Salesforce to be mapped.

Code of ConductAccessibility statement

Docusign Community

Code of Conduct