I'm using the Docusign REST API. I've created an envelope with multiple recipients and I've retrieved the sender URL to open up the web consult to place signature/initial tags.
Is there any way with the API to not allow the sender to actually SEND without dragging at least one signature tag per recipient?
Re: Is there any way with the API to not allow the sender to actually SEND without dragging at least one signature tag per recipient?
Not specifically. But here are some ideas to improve the situation:
Include signer tabs for the sender
As part of creating the envelope, include a signer recipient tab for each of the recipients. Then the person editing the document would simply move the tab around on the screen rather than having to drag it over from the tab toolbox on the left side.
Give more responsibility to your integration application
Enable your integration to have more control over the business process and therefore not show the "sending screen" to the sender. This way, your senders spend more time interacting with your app, and your app has more control over the situation.
For example:
If only a couple of document types will be sent, enable the sender to choose the document type and to fill in its parameters via your app. Then you can send the document out for signing and your app can place the various tabs.
Or when the sender uploads a document to your app, you can check the document for anchor text such as "//signer1//" Then, your app adds a signer tab with anchor text //signer1//. See this recipe.
Or enable the senders to upload docs, but use a standard "Signing page" that your app will append to all of the envelopes. When the signer signs, the extra doc (the signing page) looks as a continuation of the prior docs in the envelope. Your app would auto-generate the signing page, including the signature tabs on that page.
If you can, I would recommend that you not enable people to upload docs. (Or maybe just attachments to the main docs). Instead, reach agreement with the business process owner on what are the possible docs that can be sent. Figure out the best format for each, and enable your app to auto-generate the docs based on inputs from the senders and from other business databases/apps.
Related
My use case only requires Docusign for e-signature of pre-filled PDF forms.
The PDF forms will be generated on our application side where some fields will be automatically filled (using xPressions) and the user will fill in the remaining blank fields.
The use case:
In our web application the user is presented with a task/action.
After invoking the task the user is presented with a PDF form.
The user fills in the blank fields of the PDF form and closes it.
The user is then invited to e-sign the document.
The web applications initiates a session with Docusign and transfers the PDF document to Docusign.
The web application hands control over to Docusign (in an IFrame) where the user can add a signature to the document.
Docusign hands control back to the web application.
The user task is complete.
The web application retrieves the e-signed document.
End
In this use case we don't have a need for Docusign templates or powerforms as the PDF generation solution already exists. This existing PDF generation solution is quite complex and it would not feasible or cost effective re-implement within the Docusign solution.
My question, is the above, e-signature-only, use case feasible within the docusign solution?
You will want to use "embedded signing" to keep the entire flow within your web app. This is accomplished by specifying a "captive recipient" as the signer. In addition to name and email address, you will specify a "clientUserId" for the signer. This should be specific and unique to the actual signer, e.g. a "customer ID", employee ID, etc. In a pinch, you can use the email address.
See (https://developers.docusign.com/docs/esign-rest-api/esign101/concepts/embedding/).
You can use this API endpoint to create an envelope by passing your pdf.
See guide and section "Attaching documents to an envelope"
createSender creates a URL, which I would like to use to let the sender preview the document before it's send out. Hence the documents are created using templates and and the API.
The link which is created would lead me out of my UI. Does the user need to sign in? Future plan is to have many user's, which have no DocuSign account.
For embedded sending Your app will have to authenticate the user. If you are doing a Service Integration then your Api account will be used as the sender.
Once the sending url is generated using the createSenderView api, there is no authentication required to access the URL.
You also have an option to build a User Application using the docusign Api where your App can support sending from multiple accounts.
The createSenderView requires that the person is a DocuSign user (with their own account and password).
Only DocuSign users can send. We charge for sending, not for signing or receiving.
What exactly do you want to preview? (And why?)
the documents themselves? Use the EnvelopeDocuments resource. You can also preview the thumbnails of the documents.
the documents with the "fields" ("tabs") that indicate where people will sign? I'm not sure that is do-able.
or the recipients and their routing order? Use EnvelopeRecipients: list method.
Added
Another solution is to use a dummy certified delivery "recipient". Add this recipient as the first recipient. This will block the envelope from proceeding on the recipient routing.
Then get the envelope's documents to show as a preview.
Then, if ok, alter the envelope's recipients to remove the certified delivery recipient. The envelope will then continue on with the first "real" recipient.
We need to be able to handle a scenario where the document PDF needs to be updated and resent, after the envelope is In Process. Do we always need to create a new envelope or can we reuse the current envelope ID?
Our process goes roughly like this:
A PDF document is generated (not using a DocuSign template).
We create an envelope for the document PDF.
The first signer (our employee) signs the document (using an embedded signing page).
The other signers sign the document (also using an embedded signing page).
Firstly, we want to know if we're forced to incur another "sent" envelope (i.e. we're billed) every time we want to update a document PDF. Secondly, we're looking for a clean way to implement updates, without the need to manage multiple envelopes.
Yes you will unfortunately have to make a new envelope if you want to make changes to the underlying document(s) of the envelope after it has been sent. This is actually a fundamental part of the service and the reason is not to make you incur a new envelope - instead it's actually a security / legal requirement.
Imagine that we are in the old world and I need two people to sign a document on paper. I have the first person sign, then before the second person signs I make a change to the document that says the first person owes me $1,000,000. Then the second person signs, the document completes, and now you have a signature from both people but it contains content that the first person did not actually agree to (and they apparently owe you $1,000,000 now!). That's the main reason why you can't change the underlying document once it's been sent.
Two possible workarounds I can think of:
1. Add data fields or other Stick-eTabs to the envelope for the parts of the document that might change.
2. Use the signer attachments tab to add additional documents.
For #1, let's say you send out a sales contract for $100,000, but after it's been sent a new price is determined. If the $100,000 is in the document content itself then you can not edit it and you'd have to create a new envelope with the new document; however if it's through a Data Field then your recipients can simply edit the value as the document works towards completion.
For #2, there are special Stick-eTabs you can add called Signer Attachment Tabs which allow recipients to attach whole documents and other files to the envelope. You could utilize this to add your changes to the envelope.
Is there a human involved in updating/replacing the document, or are you looking to fully automate the process with the API? As Ergin stated, it's not possible to add/remove documents using the API once an Envelope has been Sent. However, it IS possible for the Sender of the envelope to "Correct" (and re-send) the Envelope using the DocuSign web console -- including adding or removing documents for an Envelope that's already been Sent, but documents can be ONLY be removed/replaced IF none of the recipients have yet acted on the Envelope. i.e., once at least one recipient has acted on the Envelope, it won't be possible for the Sender to remove/replace documents in the Envelope (although they can Add new documents, as long as the Envelope is still in-process).
You can use the API to launch the "Correct Envelope" view as follows:
POST https://demo.docusign.net/restapi/v2/accounts/{acctId}/envelopes/{envelopeId}/views/correct
The response to this operation will return a URL that you can use to launch the "Correct Envelope" view.
Finally, one important caveat about using the "Correct Envelope" feature to enable the Sender to modify documents in an envelope: once the person is logged into the DocuSign web console where they'll correct the envelope, they'll have full access to that user account in the DocuSign web console -- i.e, they'll be able to access all Envelopes in that user account (Sent Items, Inbox, Deleted Items, etc.), send new Envelopes, access user settings via "Preferences", etc. So, be careful using the Correct view if you're concerned at all with providing the person with full access to that user account within the DocuSign web console.
Note: In order for the Sender to be able to add/remove Documents in the "Correct Envelope" view, the "Advanced Correct" feature must be enabled for the DocuSign account (in Preferences >> Features).
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.
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