Is it possible to use custom “Merge Fields” in the email resource file?
According to https://support.docusign.com/en/guides/docusign-email-resource-file-v1-1 it is possilbe to use merge fields for DocuSign data e.g. [Data:RecipientName]]
Additionally we want to use merge fields for non DocuSign data.
For example a hotline number that is based on customers (signers) segment). The hotline number is part of the rest-api-call as a recipient custom field
Unfortunately there is not a way to leverage custom merge fields in this manner, even if the metadata is stored as recipient custom field data.
Related
I'm trying to get the list of all the envelopes created from a specific template in java.
EnvelopeTemplateResults envTempResults = templatesApi.listTemplates(accountId);
I can get the list of all the templates in the account by iterating through envTempResults and calling the method getTemplateId(). Is there a way for me to get the envelopes created from these templates?
Alternatively, is there a way to get all the bulk envelopes sent out (specifically I want to get all the Batch IDs) or a list of all the envelopes in the account?
An envelope and a template are the same thing conceptually, they are both a set of documents, recipients and fields.
The only difference is that you take a template and use it as a "boilerplate", which basically means you duplicate/copy the template into an envelope.
From that point on the envelope lives in the system independently, and there's no direct means to track what template was used to create it.
The solution that most customers/developers found is to use unique values or characteristics of the template/envelope to find out. It can be anything, from the type/number of recipients or documents, to the location of tags etc.
The best way to do it is by using metatdata, or custom fields. These are copied (just like everything else is copied) and you can add one called "templateName" which will always have the templateName in it and then you can use that to find the list of envelopes created from this template.
https://www.docusign.com/blog/developers/the-trenches-track-your-templates-envelope-custom-fields Shows you how to do that.
However, if you want to do this, it will only work for envelopes created from that point onwards. It will not be possible to search for envelopes created from the templates before you added the custom fields to them.
I am testing the Docusign API and I can send a document to sign and get it signed in the position I want using the SignHere data structure and setting the AnchorString.
I want to add a field for the signed date but what is the format and field name required. I can't see anywhere that tells me how to type these into a Word document.
I see you can create templates online using Docusign and put in these fields but I don't see how that will work for us. The document will be dynamically created by our document assembly system and then sent via the Docusign API so I need to build in the fields at that point when I add the signature anchor string.
So what is the Word document special field format and list of Docusign available fields please?
Also it would be good to know how to insert a field to ask the signer to enter some text. Any entry box.
Thanks for any help.
If you're using Salesforce to send out these documents, the DocuSign CLM product supports template codes in Word. See docs.
Otherwise, you can only specify locations of fields (tabs) in the Word doc. This is done via anchor strings also known as auto-place fields. Docs.
Placing the anchor strings in your Word doc is the first step. For the second step, I recommend that you create a DocuSign template by using the DocuSign web tool. Then, when you send the document via the API, you combine it with the template. Or better, you can insert the Word document into the template itself.
The advantage of this technique is that your business users, with the right instructions, can update the template by themselves.
An alternative is for the DocuSign API request to specify the document and the various fields (tabs) that should be included in the document for the signers.
Added
Two other options:
Create your source documents as HTML documents. You can include special tags to indicate different types of DocuSign fields. You can also indicate sections of documents that can be expanded/closed by the signer. HTML field documentation.
This is the best approach, IMHO.
Create your source documents as PDF Forms with form fields. DocuSign can then transform the PDF form fields into DocuSign form fields. There are limitations. Docs.
When sending a document to be signed, with DocuSign, I can choose a Document Label for the document with a dropdown list which I can manage administrative access. I don't, however, see the purpose of the Document Labels since I don't see any obvious way of using them to e.g. filter documents and create statistical reports. More information on the subject can be found here.
Can somebody describe to me the actual purpose of having these labels?
Here is screenshot of the Document Labels section:
Hmm, I agree the documentation you linked is missing some detailed information on what they are for. In Classic (and soon again to be in the New UI) they were called Envelope Custom Fields, from the old documentation they are classified as "fields that can be used to record information about the envelope, help search for envelopes and track information. The custom fields are shown in the Message window when a user is creating an envelope. The custom fields are not seen by the envelope recipients."
Think of it as an invisible label that you can than use to report on later. In the Reporting section of DocuSign it's actually called "Custom Field" and can be added to reports:
Envelope custom fields (Document Labels) are labels used to classify, record, and track information about envelopes sent by a user. These labels are shown to a sender when an envelope is being created; they are not seen by recipients.
The values for an envelope custom field can be free-text entries, or selected from a list of possible values. Envelope custom fields can be required or optional.
It is a metadata over envelopes. For instance, if you want to associate a case number or Invoice Number present in your system with an envelope but you do not want recipient to see it then you use Envelope custom fields (Document Labels) for this purpose. Then you can search envelope based on this label value in the Manage tab in your DocuSign Account. So Document Label helps in mapping data in your system with the envelopeId plus it helps you send extra data on an envelope which you do not want recipient to see.
I am trying to customize the brand resource file so that it uses the EnvelopeId within a query parameter in a custom html link so that the destination site can filter rows based on the Envelope.
For example, when using the following in the DocuSign XML Email resources file for the brand (e.g. in envelope completed email):
View Rows
DocuSign escapes the [[EnvelopeId]] (presumably because its within a link), causing the resulting html for the email to be
View Rows
instead of
View Rows
Is there a way to prevent the EnvelopeId from being escaped or another way to use the EnvelopeId with a custom link in the envelope completion email?
Whenever you see [[ ]] that refers to something called a DocuSign Merge Field. As you are referring to, these are dynamic variables which get replaced with expected values at runtime. I do not believe that EnvelopeID is a valid merge field in this context. The closest thing you have to referencing a link to the envelope is the [[QuickURL]] merge field.
If you were going down an API integrated route, you could specify the entire email message body contents via the API, and you would know the envelopeID at that point and could pass it in w/your logic.
Does anyone know the difference between using the Data Field in Standard set of fields versus defining a Custom field ?
JK
If you are talking about envelope custom fields - those are invisible during signing and should be used for meta-data only.
Here is a good reason to use envelope custom fields:
A loan origination system might have a loan ID and would put the loan ID as a meta data on all the DocuSign envelopes that pertain to that loan. This makes searching and cross linking easy.
Here is a good use case for regular "Secure Fields" or "Form Fields" or "Data Fields":
A system has address for a particular signer and wants to pre-populate that data for signing, but maybe give the signer an option to correct it. You put the data field on and then the user can fill it out or update it.
Hope this helps.