When DocuSign sends an email to a user requesting a signature, the View Documents button contains a link to a URL such as this:
https://demo.docusign.net/Member/EmailStart.aspx?a=564ffc65-28s7-402b-a499-cfec5526db3c&er=ac335504-8a6d-49a0-bfb6-3793887c0722
I know that the second parameter in the URL call is the recipient Id, which I can see in the envelope. However, I cannot find the first parameter.
Is there anyway I can regenerate the URL?
The reason I ask is that we have a website with a message center. Upon logging into our website, if the user has documents that require signature, I want to display a list of links for them to click and sign.
If you have a website with a message center and login I believe you should shift your paradigm of how you use DocuSign. DocuSign has a concept of an embedded signer. That means you notify the signer and when they log into your site you can make a web service call to present the person with a signing in an IFRAME or a separate window.
You can find the breakdown of that scenario in this code walkthrough:
http://iodocs.docusign.com/APIWalkthrough/embeddedSigning
A broader overview is here:
http://www.docusign.com/developer-center/explore/features/embedding-docusign
It is impossible for you to figure out or regenerate the GUIDs that are passed with envelope notification. That's one of the security features of DocuSign notifications.
Hope this helps.
Related
I am trying to integrate Docusign in my Web application. The website workflow will be as follows:
Users visit my website and log in.
Users will be given the option to choose Docusign Templates.
After selection, users need to sign that document.
After a successful signing, the signed document is sent to some authority.
My problem is how can I link my users to Docusign to sign. Does every user needs to have an account for embedded signing?? I need some help in understanding the flow of authentication and signing in DocuSign REST API. I have gone through the documentation but didn't understand properly. When I try to use the auth grant GitHub code to understand the flow. After logging in, it throws a null pointer exception. Please, someone, help me.
You can find code example in different languages to do what you're asking (sign from a template). You will want to use embedded signing so that the user sign as part of the app and not remote signing (via email).
As for your authentication question, no, signers never need to be part of the account. The sender can be a single user that is "sending" envelopes that are embedded in the app. So while there's no sending technically, you can think of it this way.
Hope this makes sense, please ask additional questions if not clear
recipientID is a GUID uniquely used to identify a recipient in DocuSign. When you create an envelope, each recipient should have one.
"and If the same name+email combination comes again, will it get the same signature or generate a new one?" It will remember it if they have an account.
I am using the DocuSign REST Api and noticed that the lifetime of a URL obtained using the EnvelopeViews API (https://developers.docusign.com/esign-rest-api/reference/Envelopes/EnvelopeViews/createRecipient) is only a few minutes. However, I have gotten emails in the past with DocuSign links. How are these links able to be added to an email (and therefore have a longer lifetime)?
Is there a separate API that can be used to get a longer-life link like the one in the email?
For example, here is an email that has a Review Document DocuSign link:
Good question. Here's what you can do.
Your application wants to let Larry sign a document using the
EnvelopeViews::createRecipient API call.
Your application should store the details needed for the API call in your app's database. Something like: envelopeId, signerEmail, clientUserId.
Create a guid for the database record and add it to the database record.
Now you can look up the database record via either the row's key or
via the guid. Ensure that the guid database column is indexed.
Now create a signing url that you will send to Larry. Something like:
https://myapplication.example.com/docusign-ceremony/[guid]
Send the url to Larry
When Larry clicks on the URL:
Your app is invoked
Look up the guid in the url in your database. You should find the
record that you stored there.
Retrieve all of the record's info: envelopeId, signerEmail,
clientUserId.
Call the EnvelopeViews::createRecipient API call with the data
and get back the signing ceremony url (that must be used within
5 minutes)
Redirect the user's browser to the url.
They'll sign the document(s) and then be re-directed back to your
application.
Done.
And guess what? This is pretty much what DocuSign does itself.
The response from Larry K above is correct, you would need to handle this on your side.
These are all the parameters that you can send as part of the request body for the POST {vx}/accounts/{accountid}/envelopes/{envelopeid}/views/recipient API endpoint and there are no options to set the expiration time for the recipient view that you create.
You could look into using PowerForms to see if they fit your needs. With PowerForms you can create a URL that users can click and it will allow them to fill out a specific DocuSign envelope. This might not fit your needs if you need to pre-fill some of the fields with information related to the specific recipient but it might be worth looking at.
PowerForms Documentation:
https://www.docusign.com/features-and-benefits/features/powerforms
Please correct me if I'm wrong but I think that your goal is creating the recipient view URL, creating an email formatted in a specific way and sending that email to the recipients.
If you use the branding feature you could specify the format for your email (if you want to use a specific message) and just send the envelope to your recipients. Once the recipients receive the email they'll see the message in the format that you specified and the link for accessing the envelope would be a regular DocuSign link that doesn't expire.
The link below shows how to create Brands in your account. Specifically signing brands would allow you to set the email content.
If you have multiple email formats you could create multiple brands and just specify the brandId when creating the envelope.
I hope this helps.
Branding:
https://support.docusign.com/guides/ndse-admin-guide-configure-branding
I am building some functions to create my JSON using the sign-client PHP API and Models. I am create an envelope on docusign using the API and sending signers emails where they go to docusign to sign. I am not using embedded signing. I am doing this all though the API and plan to get and API plan so will not have all the web-based access.
I have one or more signers and after they sign I need to direct them to a URL on my site where they can make a payment. This URL us specific to each envelope, not the same for all signers.
I believe what I need to add is a 'returnUrl' to the createEnvelope so after the users sign, they are redirected back to my site. Here is what I have, but it is not working.
$signer = new \DocuSign\eSign\Model\Signer();
$signer->setName($signer_details['name']);
$signer->setEmail($signer_details['email']);
$signer->setRoleName($signer_details['role']);
$signer->setRecipientId(1);
$signer->setRoutingOrder(1);
$signer->setEmailRecipientPostSigningUrl('https://www.example.com');
By default, after signing the signer is given a docusign page. I am pretty sure there is a variable I can use to redirect them to my site. Anyone know how to do this?
Thom
Thanks!
If you want to redirect signer back to your App after signing is completed then you can configure Destination URL in your Branding. You can find details here, check Destination URLs for post-signing navigation section. Destination URL in Branding will be used only for Remote Signing.
The returnUrl property only applies for embedded signing.
Otherwise you would not be able to set it via the API - you would need to set it in the Branding options under "Go to Admin" and then "Brands" and then default brand, "Edit" and then "Destination URLs" and you can set the return URL for signing there based on the action that the signer takes.
Embedded signing allows you to set the returnUrl parameter and use a distinct URL for every session to return back to a specific place in your application instead of a generic one.
See https://docs.docusign.com/esign/guide/usage/embedded_signing.html
Unfortunately, the emailRecipientPostSigningUrl parameter is currently undocumented. I've asked the DocuSign engineering group for more information on it.
Meanwhile, please provide more information on what you want to do. Are you using embedded signing or signing via email notification from DocuSign?
Please edit your question to provide the additional information.
Added
As indicated in other answers, if you want to have a per-envelope URL then you either:
Use embedded signing. This is probably your best bet.
Or use the one url for all envelopes (via branding), then that url determines the real url for the envelope and further redirects the signer. I don't know if your first url receives the envelope_id or other information about what the signer did.
I'm using DocuSign's REST API to create envelopes in embedded signing mode. With the function CreateRecipientView i get only a temporary link. But i would prefer to get an permanent link like in the notification mail. How can i get this link/URL?
Getting permanent signing links is not possible using the DocuSign rest API.
For remote signers, only the signer can receive the signing link through email. No one else will have access to the signing URL.
Setting permanent signing/access link is possible with "embeddedRecipientStartURL" by using a captive recipient aka "clientUserId" and your own URL endpoint whereby you authenticate your users and determine if they can access the envelope via a Request Recipient View.
Documentation here.
You can also request emails be sent per captive recipients as well as many other "Portal" centric options that put you in full control of the user experience.
To give your signers permanent links, your application creates the links by itself. Eg myapp.myserver.com/signing_links/95a086f7-a76e-40ec-938e-987be996d220
The number should be a guid, not a database record key. This is needed to prevent someone from guessing what one of these permanent links is, so they can't read (or sign!) someone else's documents.
When someone opens their browser to go to one of the signer links, your application looks up the guid in the your app's database. The database record will include the DocuSign envelope_id and the recipient_id that the link represents.
Next your app uses that data to request an embedded recipient view link from DocuSign. Then (if you get a good response back from DocuSign), your app redirects the user's browser to the signing page on DocuSign.
(You'd get back an error from DocuSign if the recipient had already signed, or the envelope had been voided, etc.)
Guess what? The above is more or less how DocuSign gives out the "permanent" links in its emails--those links always redirect to one of the 5-minutes-only signing ceremony links.
Remember that you need to authenticate the signers, or include additional authentication options in your envelope, since you don't know who is going to end up pressing one of your app's signer links.
Setting vs Getting permanent signing/access link is possible with "embeddedRecipientStartURL" by using a captive recipient aka "clientUserId" and your own URL endpoint whereby you authenticate your users and determine if they can access the envelope via a Request Recipient View.
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST%20API%20References/Recipients/Signers%20Recipient.htm
You can also request emails be sent per captive recipients as well as many other "Portal" centric options that put you in full control of the user experience.
So Net/Net, LarryK and CodingDawg are correct, each from a specific view. It ultimately is up to you to decide which way works best for your application and users.
Hello Docusign Team Member,
Currently we are using the docusign for e-signatures and it is working very well. However, we need to integrate to with our internal project management tool called as AtTask.
AtTask has its own approval process, all I need from docusign is a link which managers can click into while being asked for signatures.
To briefly explain the process:
We have these set of documents, which is first being approved by the procurement manager, then it automatically goes to the Project director, When he signs it, it automatically goes to the Assistant Director, when he signs it, it gets routed back to the project admin that initiated the process.
Now, my question is, how can I create this process on docusign and get one link that I can use in our PM tool..? I was seeing that one possible way to do it is by using your API feature.. Could you please help me with that..?
Your help is very much appreciated.
There are a couple of ways you could set up your desired workflow however please note that you will not be able to do all of this with just one link. You'll either need to generate a unique URL for each recipient, or you can use email to initiate the requests. Both are very easy to setup.
In the DocuSign system there are two general methods for initiating your signature requests-
1. Email Delivery
2. Embedding Feature
I'll briefly describe each but for a good explanation of the differences please see this page from the DocuSign Developer Center
http://www.docusign.com/developer-center/explore/features/embedding-docusign
When you setup signature requests through the DocuSign Console they are sent using the first method- Email - and the recipients are known as "remote" recipients. This means that each recipient receives an email when it's their turn to sign, and they start the signing workflow by clicking the link in the email request.
You can add as many recipients you want to the envelope and using the Routing Order property you can control the order that each recipient signs the documents. If two recipients have routing order 1 and 2, for example, then the second recipient can not sign until the first recipient is done signing. If they have the same routing order, then they can sign at the same time.
With the second method - Embedding - your recipients are known as "captive" or "embedded" recipients, and they will start the signing process directly by clicking on a hyperlink (i.e. instead of waiting for an email and clicking from there they can access it immediately). This is done by generating a URL token. For more info on how to create URL tokens for your recipients please see the above link to Dev Center.
You can intermix your recipients on a given envelope, meaning you can have embedded and remote recipients in the same envelope, so if you want you could make your Procurement Manager an embedded recipient (so that they start signing by opening a URL) and then all the remaining recipients remote recipients so that once the procurement manager signs the system then automatically emails the next manager for their signature, and so on. Or if you don't want to ever wait for any emails then you could make each recipient an embedded one, but they will still have to at least click a link (or have one automatically opened for them) to start their signing workflow.
The two best resources for this are the above link, which I'm referencing here again, and the API Walkthroughs. The last three walkthroughs all focus on Embedding DocuSign...
DocuSign Embedding Feature
DocuSign API Walkthroughs