Skip to main content
Question

Reusing existing DocGen forms across multiple objects

  • April 24, 2026
  • 4 replies
  • 37 views

Forum|alt.badge.img+7

Looking for help with reusing existing DocGen forms on different Salesforce objects.

  • Currently, all DocGen forms are configured on the Account object.
  • Requirement is to reuse the same forms on Opportunity and Contract objects.
  • I assumed that passing the correct object type and object Id during the Create and Upload step would be sufficient.
  • However, when the document is generated and viewed in SF DAL, it always gets stored under the Account folder instead of the runtime object (Opportunity/Contract).

Has anyone successfully reused DocGen forms across multiple objects?
Is there additional configuration required to override the source object or target folder behavior?

Happy to share more details if needed.

4 replies

James.McDermott
Docusign Employee
Forum|alt.badge.img+4

Hi ​@Servesh 

Unfortunately if you need to read data from Salesforce directly into a Document Generation form you need to link the form itself to a single Salesforce object. This in turn means that the URL for the form will expect a reference to that specific object type, i.e. it would need to be launched from an account and passed an account ID. Even if you create a copy of the document generation form it will still be linked to the same object, so there is no easy way to do this. 

You would need to create a form for each object type. 

The only thing you could do would be to look at all those fields that are not directly linked to Salesforce fields and create them in a form library so that they can be reused in several different forms. 

https://support.docusign.com/s/document-item?language=en_US&bundleId=uqj1643324072491&topicId=rsu1576795540593.html&_LANG=enus

If you create a “Common Fields” library and make sure its not linked to a Salesforce object you can then use those fields in all you subsequent forms regardless of if they are mapped to Accounts, Opportunities, or Contracts. 

I would recommend creating three additional libraries, Account Data, Opportunity Data, Contract Data, each mapped to their respective objects in Salesforce. 
 
In each library you could have a section with the fields you would need from each object listed (e.g. Account Name, Opportunity Name etc). 

You can then create a form/configuration to launch from the Account object, one for the Opportunity object and one for the Contract object.

In the Account form you can use the “Account Data” library (as its mapped to the same object type) and you can use the “Common Fields” library. In the Opportunity form you can use the “Opportunity Data” library and the “Common Fields” library, and so on. 


Forum|alt.badge.img+7
  • Author
  • Digital Collaborator
  • May 22, 2026

Thanks James,
Appreciate the detailed response. That makes sense. For my use case, I was generating the document from create and upload step, that means I had some basic information regarding the object id, which I used in Find or Create EOS Parent step and moved the generated document to that folder in the following step.


James.McDermott
Docusign Employee
Forum|alt.badge.img+4

Ah ok.

Although you are launching the form via the workflow instead of directly from a link coming from salesforce, the same would still apply. Because the create or upload document step still uses a form tied to a single object type.

Depending on your workflow setup you could, use the EOS Parent folders object type attribute to determine which document generation config to select

 

The only other alternative I can think of (if you just want to use a single form that is not associated to Salesforce), would be to use a salesforce ETL step to create custom XML that you would then feed into the Create or Upload step. You just need to ensure that the XML structure output from the ETL step is the same regardless of the object you are querying. As long as the XML node name matches the fields merge tag, then the form will prepopulate with the values retrieved from the ETL step

There are more details on how to use ETLs in this thread

 

 


Forum|alt.badge.img+7
  • Author
  • Digital Collaborator
  • May 22, 2026

The ETL step seems like a great idea. Will try that the first chance I get. Thanks again for sharing ​@James.McDermott