We can generate multiple Remote Signers web request and keep all the signatures from Remote signers on the same document based on the workflow and Routing Order.
The main challenge we are facing is:
If we have multiple Embedded signers and Remote signers on the same document.
How can we send the setup the web service request so that all the Signatures are captured on the same document.
Seems like for each Embedded signer an unique signing URLs is generated.
Is there a way we can maintain the same envelop for all the signers?
Please advise.
Thank you
Sure, that's easy. For any recipient who will sign through Embedded Signing you need to set their clientUserId property when you add them to the envelope. For remote signers simply do not include this property at all in those recipients' definitions.
To control the order of signing use the routingOrder property for each recipient. Note that you can only generate a signing URL for a recipient when it is their turn in the routing order, and that both serial and parallel routing is supported by the DocuSign platform.
For example, to have 3 people sign in order where the first and third recipients sign through embedded signing and the second is a remote signer - i.e. initiates through an email notification - you could use this JSON:
{
"status": "sent",
"emailSubject": "Embedded and Remote Signers",
"documents": [{
"documentId": "1",
"name": "contract.pdf",
"documentBase64": "base64 document bytes...",
}],
"recipients": {
"signers": [
{
"email": "john#email.com",
"name": "John Doe",
"recipientId": "1",
"routingOrder": "1",
"clientUserId": "1001"
},
{
"email": "sally#email.com",
"name": "Sally Doe",
"recipientId": "2",
"routingOrder": "2"
},
{
"email": "bob#email.com",
"name": "Bob Doe",
"recipientId": "3",
"routingOrder": "3",
"clientUserId": "1002"
}
]
}
}
Related
We have a requirement that we want to send DocuSign email to recipient who is marked as Captive /embedded. By default DocuSign will not send email to embedded signers. In case the recipient doesn't want to sign at our web site, they can open envelope later from their email. Is there some setting like that or some setting in Rest API call?
Found Answer at Here.
If sender sets embeddedRecipientStartURL to SIGN_AT_DOCUSIGN for particular recipient, the recipient is directed to an embedded signing or viewing process directly hosted at DocuSign.
In effect, this causes the recipient to be both embedded and receive an official "please sign" email from DocuSign.
Sample Json
{
"compositeTemplates": [{
"inlineTemplates": [{
"recipients": {
"signers": [{
"tabs": {
"fullNameTabs": [{
"fontColor": "white",
"pageNumber": 1,
"documentId": "1",
"xPosition": 400,
"yPosition": 15
}]
},
"name": "Full Name",
"email": "signersemail#email.com",
"recipientId": "1",
"clientUserId": "1000",
"embeddedRecipientStartURL": "SIGN_AT_DOCUSIGN"
}]
},
"sequence": "1"
}],
"document": {
"documentBase64": "<Base64Bytes>",
"documentId": "1",
"fileExtension": "pdf",
"name": "Doc.pdf"
}
}],
"status": "sent",
"emailBlurb": "Test Body",
"emailSubject": "Test Subject"
}
There are multiple ways to do that, depending on the exact use-case.
It seems that you want to first do embedded signing (which I assume you know how to do) and then if the user select something in your app - you want to send an email for the same exact recipient to sign the same exact envelope. So you have to make an additional API call at that point to update the recipient to remote and re-send the envelope.
That can be done using a PUT call to update the envelope. You have to add ?resend_envelope=true to that call
When using agents/intermediaries to assign signers in DocuSign, we set the clientUserId for the signers to use the embedded signing feature. But DocuSign will automatically send out the email to the assigned signers and we are not able to obtain the signing URL through the API POST {{baseUrl}}/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}}/views/recipient.
As suggested in this thread: https://stackoverflow.com/a/63810135/13191875 . It's due to the clientUserId was removed when agents/intermediaries change the signer's email/name info. It suggests that a workflow could be added to pause the process after the signer's email/name info is changed, and then add the clientUserId to the signer, then resume the workflow.
I tried with request body:
{
"recipients": {
"intermediaries": [
{
"clientUserId": "1",
"email": "aaa#example.com.au",
"name": "Intermediary",
"recipientId": "1",
"routingOrder": "1"
}
],
"signers": [
{
"clientUserId": "2",
"email": "example#example.com",
"name": "example",
"recipientId": "2",
"routingOrder": "2",
"tabs": {
"signHereTabs": [
{
"anchorIgnoreIfNotPresent": "false",
"anchorString": "Signature_anchor_1",
"anchorUnits": "pixels",
"anchorYOffset": "0",
"name": "Please sign here",
"recipientId": "1"
}
]
}
}
]
},
"workflow": {
"workflowSteps": [
{
"action": "pause_before",
"itemId": "2",
"triggerOnItem": "routing_order"
}
]
},
"emailSubject": "DocuSign API - Signature Request on Document Call",
"documents": [
{
"documentId": "1",
"name": "{{fileName}}",
"documentBase64": "{{fileBase64}}"
}
],
"status": "sent"
}
I can set the clientUserId after the signer's email/name is changed. But the workflow cannot be resumed by calling the API PUT {{baseUrl}}/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}}?resend_envelope=true. So the signer's signing URL cannot be obtained since the process is paused, the signer's status stays in created.
I also tried the with agents:
{
"recipients": {
"agents": [
{
"clientUserId": "1",
"email": "aaa#example.com.au",
"name": "Agent",
"recipientId": "1",
"routingOrder": "1"
}
],
"signers": [
{
"clientUserId": "2",
"email": "",
"name": "",
"recipientId": "2",
"routingOrder": "2",
"tabs": {
"signHereTabs": [
{
"anchorIgnoreIfNotPresent": "false",
"anchorString": "Signature_anchor_1",
"anchorUnits": "pixels",
"anchorYOffset": "0",
"name": "Please sign here",
"recipientId": "1"
}
]
}
}
]
},
"workflow": {
"workflowSteps": [
{
"action": "pause_before",
"itemId": "2",
"triggerOnItem": "routing_order"
}
]
},
"emailSubject": "DocuSign API - Signature Request on Document Call",
"documents": [
{
"documentId": "1",
"name": "{{fileName}}",
"documentBase64": "{{fileBase64}}"
}
],
"status": "sent"
}
After the name/email is added by the agent, the process is paused and I set the clientUserId for the signer, I verified that it is added by calling the get recipients info API. After I resume the process, an email is sent by DocuSign to the signer and I cannot get the embedded signing URL for that signer. I can see the clientUserId is removed for that signer by calling the get recipients info API again.
My question is:
when using agents/intermediaries in DocuSign, is it possible that we can obtain the embedded signing URL for the assigned signer whose email is updated/added by agents/intermediaries?
when using agents/intermediaries in DocuSign, is it possible that we can turn off that email from DocuSign to the signer, whose email is updated/added by agents/intermediaries?
when using agents/intermediaries in DocuSign, is it possible that we can obtain the embedded signing URL for the assigned signer whose email is updated/added by agents/intermediaries?
Yes, but you'll first need to assign a clientUserId to the recipient.
And since the recipient has already been sent an email invite to the signing ceremony, adding a clientUserId attribute is problematic since doing so will invalidate the email invite.
when using agents/intermediaries in DocuSign, is it possible that we can turn off that email from DocuSign to the signer, whose email is updated/added by agents/intermediaries?
To do this, you need to stop the workflow as I described in the other answer.
Much better would be to expand your API application so that it is used to change the name/email of the signer. That way your application can also set the clientUserId at the same time and the signer won't receive any email.
Basically, embedded signing is only intended to work if the envelope is created/edited via an API program. Your goal of using an API program and using the regular DocuSign Web App (which focuses on email delivery, not embedded signing) is mixing apples and oranges. It is possible but problematic.
You can potentially use the new Advanced Recipient Routing (ARR) feature to pause the envelope, obtain the information about the next recipient (via GET call to listRecipients) and then modify it to add the clientUserId. I have not tried this, but in theory that should work.
ARR is now available in demo/developer accounts for all new accounts created.
https://developers.docusign.com/docs/esign-rest-api/how-to/pause-workflow has information about how to create the envelope such that it pauses after a specific routing number.
https://developers.docusign.com/docs/esign-rest-api/how-to/unpause-workflow shows how to resume the envelope once you made your change.
The other thing you may need to do is add a webhook call for when the status of the intermediary was updated so you know when to update the next recipient (but before you can do that you would have to obtain the information about the new recipient).
I know that there is no authentication performed by Docusign when using embedded signers. In the RecipientViewReuest it allows for an authentication_method. So far I have found that 'none' and 'email' work fine. I assumed that this was a free form text field that allowed me to say something like 'Checked their IDs' But any I've used so far (besides none and email) cause an error, so I assume there a limited list of acceptable answers. Anyone know what they are?
You can enable the following recipient authentication types on your envelope:
Access Code
Phone Authentication
SMS
Knowledge-Base Authentication(KBA)
ID Verification (IDV)
In your case (for embedded signing) you have two separate API requests to make: The only change will come in your POST /envelopes call.
Ex. Let's say I wanted to add an access code to a particular recipient. Easy as adding the accessCode property when you create your envelope.
{
"documents": [{
"documentBase64": "JVBERi0xLjMNJeLjz...lRU9GDQo=",
"documentId": "1",
"fileExtension": "pdf",
"name": "Lorem"
}],
"emailBlurb": "Sample text for email body",
"emailSubject": "Please Sign",
"envelopeIdStamping": "true",
"recipients": {
"signers": [{
"name": "{SIGNER_NAME}",
"email": "{SIGNER_EMAIL}",
"roleName": "",
"note": "",
"routingOrder": 1,
"accessCode": "{ACCESS_CODE}"
"status": "created",
"tabs": {
"signHereTabs": [{
"documentId": "1",
"name": "SignHereTab",
"pageNumber": "1",
"recipientId": "1",
"tabLabel": "SignHereTab",
"xPosition": "75",
"yPosition": "572"
}]
}
}]
},
"status": "Sent"
}
Here is a full guide on this topic.
Matthew has provided the list of additional authentication that DocuSign can do for you if you wish.
Here is the list of authentications that you can list as having performed before calling the EnvelopeViews:createRecipient method.
They're listed on that page in the description for the recipientViewRequest.authenticationMethod attribute. Use the value that best describes the authentication that your application did.
Biometric
Email
HTTPBasicAuth
Kerberos
KnowledgeBasedAuth
None
PaperDocuments
Password
RSASecureID
SingleSignOn_CASiteminder
SingleSignOn_InfoCard
SingleSignOn_MicrosoftActiveDirectory
SingleSignOn_Other
SingleSignOn_Passport
SingleSignOn_SAML
Smartcard
SSLMutualAuth
X509Certificate
I am looking for solutions for the following questions in docusign node sdk.
1.how do we implement the multifactor authentication using docusgin node sdk.
2.how to display user information in template using embedded signing.
DocuSign currently offers up to nine (9) different forms of recipient authentication, you can read the docs and the website to see the full list. Two of the more popular recipient authentication flows when using the API are Access Code and SMS. In both methods a unique code is used to access the envelope.
With Access Code it's up to the sender how to deliver a sender-defined code to the recipient (i.e. they can call and give it to them, email it, or send through some other means). SMS Auth is the same concept except the DocuSign platform generates a unique code instead of it being sender-defined, and the code is sent through SMS to their mobile phone.
To add Access Code authentication for a recipient:
{
"status": "sent",
"emailSubject": "Envelope with Access Code Auth",
"documents": [{
"documentId": "1",
"name": "contract.pdf",
"documentBase64": "base64 document bytes...",
}],
"recipients": {
"signers": [{
"email": "john#email.com",
"name": "John Doe",
"accessCode": "99999",
"recipientId": "1",
"clientUserId": "100"
}]
}
}
The maximum length for an access code is 50 characters. Note that the above recipient would be set to sign in embedded fashion since their clientUserId is set.
To add SMS you need to use the composite templates feature (note that you do not need to include an actual template if you do not want to, just remove the serverTemplates node in that case):
{
"status": "sent",
"emailSubject": "Please sign this for me",
"compositeTemplates": [{
"serverTemplates": [{
"sequence": "1",
"templateId": "[TEMPLATE_ID]"
}],
"inlineTemplates": [{
"sequence": "1",
"recipients": {
"signers": [{
"name": "[SIGNER_NAME]",
"email": "[SIGNER_EMAIL]",
"routingOrder": "1",
"requireIdLookup": true,
"recipientId": "1",
"idCheckConfigurationName": "SMS Auth $",
"smsAuthentication": {
"senderProvidedNumbers": [
"1234567890"
]
}
}]
}
}]
}]
}
Replace "1234567890" with the recipient's mobile phone number. Note that the idCheckConfigurationName property must be set to "SMS Auth $".
When you say multi-factor authentication are you referring to "Access Code", "Phone", "SMS", or "Knowledge Based" authentication? If so take a look at EnvelopeRecipients Create in the API documentation, specifically the signer definition. The attributes I would look at are "requireIdLookup", "accessCode", "idCheckConfigurationName", "idCheckInformationInput", "phoneAuthentication", "smsAuthentication", & "socialAuthentications".
Another way to achieve this would be to use SSO and have your Identity Provider require multi-factor authentication.
I am creating composite templates that work correctly and I'm running into this issue.
I am adding 2 templates to sign via docusign. I set the routing orders for both of them as shown below:
Form 1
Order 1 RoleName signer test1#gmail.com
Order 2 RoleName signer2 test2#gmail.com
Form 2
Order 1 RoleName dataEntry test1#gmail.com
Order 2 RoleName dataEntry2 test2#gmail.com
This will send one email to test#gmail.com. This user completes all of his fields for both Form 1 and Form 2 in one request. This is what I want and expect. However, when test1#gmail.com completes their process, test2#gmail.com will receive 2 different emails. One to sign form 1 and the other to sign form 2. I'm trying to understand why test2#gmail.com doesn't work the same as test1#gmail.com. Can someone help explain what the reason is for receiving 2 separate emails for test2#gmail.com may be and if there's a way to fix it?
Note: When I do this via the docuSign website, it doesn't allow for the same recipient to be in that same routingOrder. It will bring up the error:
The role 'signer' conflicts with 'dataEntry'
The role 'signer2' conflicts with 'dataEntry2'
This behavior seemed strange to me since I'm able to send the envelope using the docusign rest API. If somebody could give me some clarification on this as well I'd appreciate it.
Thank you!
I am unable to repro the issue you describe. Here's what I did, and the Result:
I created two separate templates in DocuSign, each having a single document and two recipients/signers (with Role Names and Routing Orders that you specify above in your question).
I used the REST API (JSON request included below) to create/send an Envelope from these two Templates, specifying identical recipient information (name/email/recipient ID/routing order) for Recipient 1 and Recipient 2 across both Inline Template structures.
Result: Recipient 1 receives an email first, opens the envelope, and signs both documents at once. Then Recipient 2 receives an email, opens the envelope, and signs both documents at once. The Envelope status is "Completed" at that point.
I've included my API request below for your reference -- perhaps compare/contrast this with what you're doing? Also -- make sure that Recipient information (Name / Email / Recipient ID / Routing Order) is identical (including case) for each recipient between the first Inline Template and the second Inline template within the API Request -- any small difference in Name/Email/Recipient Id/Routing Order, and DocuSign will treat them as different/separate people (recipients).
POST https://{{env}}.docusign.net/restapi/{{version}}/accounts/{{acctId}}/envelopes
{
"emailSubject": "Please sign",
"emailBlurb": "Please sign...thanks!",
"status": "sent",
"compositeTemplates": [
{
"serverTemplates": [
{
"sequence" : 1,
"templateId": "TEMPLATE_ID_1"
}],
"inlineTemplates": [
{
"sequence" : 2,
"recipients": {
"signers" : [{
"email": "adamsemail#outlook.com",
"name": "Adam Adamson",
"recipientId": "1",
"roleName": "signer",
"routingOrder": "1"
},
{
"email": "bobsemail#outlook.com",
"name": "Bob Burns",
"recipientId": "2",
"roleName": "signer2",
"routingOrder": "2"
}
]
}
}]
},
{
"serverTemplates": [
{
"sequence" : 1,
"templateId": "TEMPLATE_ID_2"
}],
"inlineTemplates": [
{
"sequence" : 2,
"recipients": {
"signers" : [{
"email": "adamsemail#outlook.com",
"name": "Adam Adamson",
"recipientId": "1",
"roleName": "dataEntry",
"routingOrder": "1"
},
{
"email": "bobsemail#outlook.com",
"name": "Bob Burns",
"recipientId": "2",
"roleName": "dataEntry2",
"routingOrder": "2"
}
]
}
}]
}]
}