How to Populate Salesforce Fields from Conga Composer Documents

Subscribe to Our Blog

Get weekly updates
straight to your inbox

Submit your email address to subscribe.

By submitting this form you confirm that you agree to the storing and processing of your personal data by Conga as described in our Privacy Statement.

Conga Composer is a perfect app for merging data and content from Salesforce into customized documents, presentations and reports.  That said, I often describe Composer as a “one-way street” in the sense that it’s not built to capture data from outside Salesforce (like in a fillable document) and subsequently populate fields in Salesforce.

Fortunately, a few of Conga’s trusted eSignature partners handle this requirement perfectly.  For example, you may want to use Conga Composer to do things like:


1) Create and send a contract to a customer and ask them to fill in their preferred shipping method and shipment date.

2) Generate and send a renewal form to a client and ask them to update their contact information.

Integrating Conga Composer with an eSignature application has a ton of benefits, but in this post, I want to highlight two specific features of DocuSign for Salesforce and Adobe EchoSign that give you the ability to capture information from a document that’s been sent for eSignature and update fields in Salesforce.

Let’s break down the two use cases mentioned above to see how this works:

1) Sending a Contract, Confirming Shipping Information with DocuSign

One of the key features of DocuSign is the ability to add tags to a document that will define where a recipient will input information like their signature, initials, name, etc.  However, DocuSign also offers the ability to use custom tags to capture other types of information from signers.

Custom tags can be related to Salesforce, which gives you the ability to push the data from a DocuSign Envelope back into specific fields in your Salesforce environment.

The first step to this process is establishing your DocuSign custom tags, which is done in the preferences of the DocuSign Administration Console:

 DocuSign 1


Let’s take a look at the Shipping Method custom tag to see how it’s been configured:

 DocuSign 2

1) This tag is related to a Salesforce field – specifically, the Shipping_Method__c custom picklist field on the Opportunity object.  Checking the Writeback checkbox allows data from the custom tag to overwrite the field in Salesforce.  Lastly, the Salesforce picklist values are included in the Tool Tip field here in the DocuSign Custom Tag definition.

2) DocuSign offers a number of formatting options for the data that will populate this field.  This provides a handy way to match the formatting style of a custom tag with the rest of the content in your document.

3) Arguably the most important part of defining a custom tag is the Anchor.  This is a string of text that an administrator defines, and represents what will actually be added to a document template before merging it with Composer and sending it via DocuSign.

Take careful note of the {r} placeholder value in the anchor.  This is a variable – when you actually place the anchor in your template, you’ll replace this value with a number to indicate which signer role will complete this field.  For example, if I added this particular custom anchor tag to a document template for the first signer role, I would type in \Shipping_Method_1\.


Finally, the custom tag needs to be Shared in order for other DocuSign users (not just the administrator) to use it.

Phew!  Enough administrative consoles for now, let’s see these custom tags in action.  I’ve created a contract template that includes standard anchor tags to capture the signature of two recipients, but also two custom anchor tags for the first signer to input information:


Pro Tip: It’s highly recommended to apply white color to DocuSign anchor tags in document templates.  Otherwise, the literal text of the original anchor tag (like \s1\) will show up in the output file.  Coloring the tags white makes it so only the fillable tag shows in the output file, not the original anchor text.


In Salesforce, I’ve created a Conga Composer solution that runs from a custom button on the Opportunity.  On the Opportunity record where I’m creating my contract, the Shipping Method and Ship Date fields already have values:

 Robert Boyd 2

When I use Composer to generate my contract and send it through DocuSign for signature, the first recipient (in this case, my customer) is presented with this DocuSign Envelope:

 DocuSign 3

Notice how the DocuSign custom tags display the current values of the Shipping Method and Ship Date fields from Salesforce.  If the customer wanted ground shipping and April 10th was the correct date, they wouldn’t need to make any changes.


However, let’s say the customer wants to change the delivery method and also wants to push the shipment date a little farther into April.  They can modify these fields right here:

 Docusign 4

After making these changes, the customer could simply DocuSign the contract and it would be automatically routed to the second signer:

 Docusign 5

Here’s where the magic happens – after the first recipient modified the shipping method and ship date and signed the contract, the corresponding fields on our Opportunity back in Salesforce are updated:

 Robert Boyd 3

Beautiful!  With the use of custom tags, we’re able to capture up-to-date information from our signers and populate fields in Salesforce.  Integrating DocuSign with Conga Composer in this way allows for our proverbial one-way street to become more like a highway of data that can flow out of and back into Salesforce.  Gotta love those traffic analogies.


We’ve helped Conga customers leverage this DocuSign feature to do things like help normalize their data, capture key information to accelerate the time it takes to close a deal, and even onboard new employees.

2) Sending a Renewal Form, Capturing Updated Contact Information with Adobe EchoSign


Adobe EchoSign offers extremely flexible text tags that give administrators a great deal of control over what kind of information can be collected from recipients in the process of electronically signing a document.  EchoSign text tags allow you to do things like set specific locations for customers to sign and initial documents, but also capture data from signers that can be pushed back into specific fields in Salesforce.  In order to accomplish the latter option, EchoSign offers the Data Mappings feature.

EchoSign Data Mappings are defined in Salesforce and essentially link specific text tags to defined Salesforce fields.  To get a sense of how this works, let’s assume I’ve created a Conga Composer solution that runs from a custom button on the Contact object in Salesforce to create a Client Renewal Form that’s delivered through EchoSign.

Let’s take a look at the Composer template:

Back in Salesforce, I’ve created an EchoSign Data Mapping record to define exactly which Salesforce fields to update, as well as which text tags will update those fields:

1) First, we define which Salesforce object(s) to update.  In this case, I’m running my Composer solution from the Contact, which is also where I want to update fields with data from my signers.

2) Next, we specify exactly which Salesforce fields to update.  For this example, I’m capturing address details.

3) This is where we define where the data will come from.  I want signers of my renewal form to input data directly into an EchoSign Form Field in my client renewal document, so that’s what I’ve chosen for each of these field mappings.

4) This step is crucial – it’s where we specify the names of the text tags that will act as EchoSign form fields.  Notice that the values in this column match the highlighted parts of the text tags in the original Conga Composer template.

5) Finally, you also have the option of defining exactly where in the signing workflow that each data mapping will execute.  It’s often handy to map signer data to a specific field when an EchoSign Agreement is cancelled, declined, or expired.  However, in this case, the mappings will only run when the renewal form is Signed/Approved.

Now that we’ve set up our data mapping, let’s see how this works in practice.  Here on a Contact record in Salesforce, we can see that there is incomplete information for the mailing address:


After clicking the Composer button on a Contact record in Salesforce to generate my document and send it via EchoSign, the recipient is presented with this agreement:



After dutifully filling out the various fields, the recipient can sign the document:


Back on the same Contact record in Salesforce, we now see that there is updated, complete address information:

13_ContactFieldsAfter (1)

Perfect!  Not only did we renew a client, but we also updated their contact information in the process.

There are many ways to use both DocuSign custom tags and EchoSign data mappings for a variety of business purposes, but I hope this gives you an idea of what’s possible with these particular features when designing an integrated eSignature solution with Conga Composer.

Curious about using DocuSign or Adobe EchoSign with Conga Composer?  Check out our data sheets that highlight the features and benefits of each integration:

Thanks for reading – until next time!


Leave a Reply

Your email address will not be published. Required fields are marked *