I'm working on a C#.net website and using DuoSecurity services to request electronic signatures. I want the users to sign the documents trough my web site so I decided to use the embedded signing feature.
To use this feature, you first need to create an envelope, but while creating an envelope I'm required to enter the signer's email address so DocuSign sends him an email with a link to the document, but I don't want this email to be sent.
To make it short, is there any way to create a DocuSign envelope without having DocuSign send an email to the signer? (I don't mind entering the signer's email, I have all the required information, it's just that for security purposes I don't want the end-user to receive the document URL trough email).
If not, is there any way to use the embedded signing feature without creating an envelope (I doubt it, but I really need a way to upload a document to DocuSign without them sending an email to the signer).
Thanks in advance,
The system will not send them an email if you are using Embedding functionality. To make use of Embedding and generate a URL token for a given envelope you need to set the clientUserId property for your recipients.
When the clientUserId property is present and its value is not null no email is sent to the recipient (only the envelope complete email gets sent once signing is done, but that is configurable). Basically the only thing you have to remember with embedding is that you set the clientUserId property for your recipients at the time they are added to the envelope, then when you are request a URL token you need to reference the same email, name, and clientUserId combination.
You're two best resources on this are the Embedding API Walkthroughs (see the bottom 3):
http://iodocs.docusign.com/APIWalkthroughs
And the DocuSign Dev Center page on Embedding functionality:
Features -> Embedding
Related
In docusign is it possible to create a signing request via the web interface and then retrieve the sigining URL via the API
at the moment, I update the Envelope using the API to attach a clientUserID as this is lacking when created via the web interface.
Then I retrieve the signing view url however, there is no signing tab when navigating to that url. The only action I have is to close.
I have tested using the API and the envelope contains signing tabs so I'm not sure what the issue would be.
Any help would be much appreciated!
When you send a DocuSign envelope if you assign one or more tabs to your recipient it becomes what's known as a Free Form signing experience, where the recipient decides where to sign the document.
On the other hand if you specify one or more tabs for the recipient then it's a Guided Signing experience. In guided signing the recipient can only sign and take actions at the tabs the sender has specified.
It sounds like you are successfully creating the envelope and signing URL but that there are no tabs configured for the signer. If that's the case you should confirm your code is identifying the recipient correctly by specifying the name, email, recipientId, and clientUserId values.
I would also check that the tabs are being set in your request body correctly for the given recipient. First get the recipient information for the envelope using the EnvelopeRecipients: list API to ensure the data is what you expect, then generate the signing URL using the corresponding data.
Using this python example from github as an example, I wrote an R package for interacting with the DocuSign embedded signing API.
I don't appear to fully understand the workflow for embedded signing, and I am hoping someone can help.
Here is what I would like:
I have an application with a sign up page. When users sign up I would like them to sign a document. So when they submit the sign up form, I generate an envelope using a template, and use their name and email in the templateRole parameter. I get a URL which I send the user to, which allows them to sign the document.
It appears though that the actual workflow involves sending an email to the signer first, and having them sign from a link in the email. This does not seem very "embedded" so I am a bit confused. Is this because I am using the sandbox API?
I see that that there is an authenticationMethod parameter, which takes values of either email, or HTTPBasicAuth or Password or PaperDocuments. Is this the reason it is using email instead of directly sending the user to a page where they can sign because I am chooseing email as the authenticationMethod?
Have I fundamentally misunderstood embedded signing?
The script you are referencing is for Embedded Sending.
The Embedded Sending view of an envelope allows users to edit the tabs, documents, recipients, and other settings of draft envelopes before sending them out for approval
So you are basically giving the Signer access to potentially modify the envelope(Add more signers, remove documents etc). The sender view should never be presented to the Signer.
If you are looking for Embedded Signing, then see this code
Embedded Signing - or the Recipient View workflow - allows users to sign directly through your app or website. When you embed your recipients you are telling the DocuSign platform your app will generate signing URLs, authenticate your recipients, present the signing request, and re-direct once the transaction is complete.
I have successfully created a system to use a document template to create a new envelope.
The system has a tabbed UI and iframe that fetches new URLs from the Docusign API every time a tab is changed, and when a URL expires.
My problem is that now, some clients will either be sign in-person or sign via email. After reading the docs, I don't see a way to change from an in-person to an email signer after the envelope has been created. Is that correct?
Is it possible to set whether a role will be in-person or email sign at the time of envelope creation, without affecting the original template?
If that is not possible, Is my best option to create a template with duplicate fields for both in-person and email signing, and only use the appropriate ones based on my case?
If you need to change an in-person signer to a remote signer, or vice-versa, or any other recipient type into another recipient type you have two options:
Perform an Envelope Correction
Remove then Add the Recipient back to the in-process envelope as a different type.
For option #1, using an envelope correction you can edit things like recipients, tabs, and even documents if they have not been signed yet. Make the following API call to request the correction URL of an envelope:
POST /v2/accounts/{accountId}/envelopes/{envelopeId}/views/correct
API Docs: https://docs.docusign.com/esign/restapi/Envelopes/EnvelopeViews/createCorrect/
For option #2, the system does not let you convert a recipient into another recipient type - HOWEVER - you can delete a recipient from an envelope then add them back in as a different type. For instance, delete an in-person signer and then add them back in as a signer.
You can see the needed calls through the EnvelopeRecipients Resource.
I am using the DocuSign API in an embedded manner. I create an envelope and add signers, the first signer always being set as embedded. This allows me to retrieve a URL that is then embedded in an iframe.
However, I also wish, to trigger an email (as soon as the envelope has been created, NOT upon completion) that gets sent to the primary recipient/signer as if they were a nonembedded signer.
I tried adding the signer twice, with the same role, to the recipients, but that didn't work. No email was sent.
Is there a way to accomplish this?
I believe there is a setting to enable this but that it needs to be enabled by someone on DocuSign's side, like your account manager. If you do not have an account manager yet please respond to the auto-generated emails that were sent out to you once you created your account, you should have 3 of them.
The account settings available are only for Completion emails. However, the REST API also supports an embeddedRecipientStartURL parameter on the signer object that triggers a normal DocuSign email. The value of this parameter is the URL that should be included in the email. This means you can link back to your own application and request the recipient view as normal.
Check here for more detail: Signer embeddedRecipientStartURL. Note: if you set this to a value of "SIGN_AT_DOCUSIGN" then DocuSign will provide its own URL and take care of signing. The trade-off is that you won't be able to initiate any bespoke authentication you are doing in your own application.
Create an envelope using Server Template and then get the return URL for Embedded signing and also send the Envelope to the recipient via email to sign the document. So that , User can sign the document either using Email Link (Remote) or Embedded link in Web. Please let me know there is any option to achieve this in DocuSign API ?
A solution is to specify both a clientUserId and an embeddedRecipientStartURL when creating a Recipient.
Specifying a clientUserId causes the recipient to be an "embedded" signer.
Specifying an embeddedRecipientStartURL causes the recipient to also receive an official DocuSign email inviting them to sign the documents.
The embeddedRecipientStartURL parameter is intended to be a URL that DocuSign can redirect the signer to within your app, and the idea is that you take care of any necessary authentication. However, rather than supply a URL to your own app, you can instead supply a magic value of "SIGN_AT_DOCUSIGN". In effect, this causes the recipient to be both embedded and receive an official "please sign" email from DocuSign."
A single recipient in an envelope workflow must be specified as EITHER a Remote recipient (so that DocuSign will send them an email when it's their turn in the routing order) OR an Embedded recipient (so that DocuSign will not send them an email) -- it's not possible to specify a recipient as both Remote and Embedded. However, in the scenario you describe, you might consider the following approach:
Specify the recipient as an Embedded recipient when you create the envelope.
Immediately after creating the envelope (or when it's that recipient's turn to view/sign the envelope), your application creates and sends an email to the recipient and includes a link to a page within your application (website) -- you can include querystring parameters on the link URL to contain recipient name and email address.
Develop the page in your application (the one that the email links to) such that it identifies the recipient (perhaps by reading the recipient name and email address from the querystring parameters in the URL), and then uses that information to make a "POST Recipient View" call to retrieve the URL from DocuSign that can be used to launch the recipient's signing session.
Using this approach, the recipient will still receive an email when it's their turn to sign -- but the email will be sent by your application -- and the link in the email will lead the recipient to your application where your application will then request (from DocuSign) and present (to the recipient/user) the URL to view/sign the envelope.