I am trying to understand if it is possible to have multiple people sign a document within one iFrame or if a new token needs to be generated (and new iFrame created) for each person who wants to sign.
Currently in my application, I use the Template ID to instantiate a new envelope. The template has 3 roles: Agent, Client1, and Client 2.
I then request a token for the envelope so it can be viewed in the iFrame. A screen comes up that says "Chris please give Agent control of the keyboard and mouse" and then that person fills out the document... After that person is done, the iframe forwards to the returnUrl.
I was expecting that after Agent finishes, it would say "Chris please give Client1 control of the keyboard and mouse" - but it does not.
Is there a way to get all roles signing in one flow without regenerating a token?
You need to generate a new, unique signing token for each individual recipient that will be singing in embedded fashion.
When you use DocuSign's Embedding functionality/APIs you are basically telling the DocuSign system that instead of the platform taking care of everything (i.e. generating each signing URL, authenticating the user, email notifications, routing to the next recipient, etc) that your app will manage all of that instead.
Additionally, whenever you generate a signing token that token expires after 5 mins and they also expire after one-use (you need to generate a new one if they close the window, decline to sign, etc).
So having said all that, the only way the system will automatically route to the next recipient in the routing order is if that next recipient does NOT have the clientUserId set (i.e. they are not signing using embedding). If all your recipients are accessing the envelope through Embedding then you'll need to generate a new signing URL for each recipient.
Some additional resources:
Embedding API - aka CreateRecipientView
Corresponding API in the API Explorer Tool
Some comments in addition to Ergin's answer:
Try hard to not use an iFrame. Especially if the app may be used on a tablet or mobile. Why: the DocuSign window really needs the entire screen to give a quality signing experience to the signer.
In your use case, your app could have a screen that includes a button "I am George Smith, Client 1. I am ready to sign." And it is important that your agents be trained that George Smith always pushes the button. (Never the agent.)
Doing so gives you a stronger case that it was George Smith who signed.
When the button is pushed, your app would retrieve the recipientView URL from DocuSign and redirect to it.
When DocuSign redirects back to your app after signing, your app can show a screen "Susan Smith, Client 2 is ready to sign" (If George actually signed. See the event query parameter. Docs.)
Authentication
The most important issue when using embedded signing is authentication. Your app is responsible for guaranteeing the authentication of the signer(s). You need to carefully understand how you will do that.
In the case of an agent and clients in person, will the agent be checking government issued ID? If so, you may want to have the agent, as part of her signing process, attest that they checked the clients' government ID.
Because of the attestation issue, it often makes sense for the agent's signature to be last. That way the attestation can be something like "I affirm that I checked the government ID of the signers George Smith and Susan Smith." (Ask your lawyer for exact wording.)
You can use the "Initial Here" tab type next to the attestation.
Related
We are using the DocuSign REST services and currently passing in the recipients required to sign the document from two People columns in a SharePoint document library. The client would now like to have it that they have secondary signers, e.g. the original users could sign but if they are not available their assistant must do so. What would be the best solution for this?
I noticed mention of something similar here:
Docusign multiple signers for one signature line
They want this to happen at run time though, so the email addresses get sent on the original request to create the envelope and this solution above speaks more to the concept of creating them via the DocuSign interface which is not ideal for them. Has anyone else tried this?
Do the assistants sign as themselves or on behalf of the original signer? I'm making some assumptions here, but most assistants would have access to their boss' emails, so presumably they'd have access to the DocuSign notifications that comes though. In that case, the assistant could simply sign as the original signer by clicking through to the envelope from the email. While this is usually a bit of an eyebrow raising move in terms of security, the reality is that many partners in law firms already delegate their authority to their PAs to sign on their behalf, and today these PAs have copies of all their bosses' signature images to place on documents.
A slightly better move, if the requirement is for the assistant to sign under their own name, is to go into the envelope from their boss' email and reassign the envelope to themselves. Then they will receive an email and they can sign under their own name and all of this will show in the audit trail.
Either way there isn't anything you need to do from an API perspective apart from ensuring the right features are turned on to allow signers to reassign.
The other option is using Signing Groups, but the groups need to be set up beforehand in the DocuSign account and your API call will enter the signing group ID (under the "signingGroupId" parameter) instead of the recipient name and email. This means either the boss or their assistant could sign if they are in the same signing group, but does not enforce one over the other.
I am trying to use DocuSign in my app, it’s really an excellent tool, however, I've met some problems and hope you could help me with
it, thanks.
First of all, let me explain my scenario, let’s say Annie who are using my app, Annie opens a document in the app, she generate a digital
signature of her own on the document, then she shares the document to Tom and invite Tom to sign his name on the document.
I leveraged DocuSign Api with the following step to complete the above scenario:
For each document user opened, create an envelope
Open console/sender view in embedded h5 view
User will sign his/her name and edit it in embedded view
My questions are:
·User needs to have a DocuSign account to use console/sender view, but Annie or Tom don’t have an account and may not would like to register a DocuSign account in the app.
Is it possible for me to create an account for Annie through some kind of Api?
· Even if they already have valid accounts, Annie signs her name on the document, when she wants to invite Tom to sign on the document on a certain place, she have no way to find Tom on the page she edited as DocuSign do not know Tom and I could not add Tom’s information on the page.
Is there any kind of method that I can show Annie’s contacts on the page and let Annie to select any contact on it?
My questions are:
User needs to have a DocuSign account to use console/sender view, but Annie or Tom don’t have an account and may not would like to register a DocuSign account in the app.
The sender of the signing request needs an account. The sender can be either a "system" account (your application) or a human. Often a human's account is used, that way he or she will receive back information about the signing progress, will see the signed document stored in DocuSign, etc.
Is it possible for me to create an account for Annie through some kind of Api?
Yes, your app (and your account) can be enabled to use the API to provision new sender accounts. These accounts cost money, so in this case, your company is reselling DocuSign services to your end customers. DocuSign is happy to work with you to enable this.
Even if they already have valid accounts, Annie signs her name on the document, when she wants to invite Tom to sign on the document on a certain place, she have no way to find Tom on the page she edited as DocuSign do not know Tom and I could not add Tom’s information on the page.
Is there any kind of method that I can show Annie’s contacts on the page and let Annie to select any contact on it?
If your app is creating the envelope via the API, then your app can show Annie a list of recipients and let Annie pick Tom via your app. Then your app creates the envelope/transaction/signing request in DocuSign, including Annie and Tom as signers.
Then, via the Sender View, Annie can see the document before it is sent. Your app can do more than just add Tom as a signer: your app can add the "tabs" that control where Tom will sign, initial, and make other updates to the signed doc.
DocuSign DTM is a large system, so there is often "more than one way to do it." Please ask additional questions by opening new questions on Stack Overflow.
A 3rd party website is offering our service to their members. When they sign up, members have to agree to our contract. Currently this is handled manually, with envelopes being sent through email. We want to streamline this process allowing members to enter their information into the web site, and then immediately be presented with a contract to review and sign.
The 3rd party web site will collect the member information, then use the REST API to create a draft envelope based on a Template and information the the member enters on the website. The application will then display the contract in the web page so that the user can review and sign it. The document workflow will ensure that signed copies are routed to appropriate parties within our company via email for completion.
We want the 3rd party web site to have access to an account to which we can share templates. We want the 3rd party application to have very limited capabilities trhough the API:
Submit requests using a User ID and Integrator Key that we provide. These credentials need be different from other User Ids and Integrator Keys under our account
Create a draft envelope based on the templates we provide
Post a Recipient View allowing the application to display the document for review and siganture (in an IFrame)
Receive the signing status via the return URL provided in the Recipient View post
Possibly request status for an envelope
The external application should not have access to other templates, documents, or unnecessry API calls.
We want to be able to cancel the application's access at any time.
Question: Permissions and API Limitations
Is the above scenario feasible with respect to establishing limited access to the DocuSign REST API? How would we set this up?
Do account user permissions limit API use, if the API is enabled for the user? I found these settings in the user permissions section of the documentation. I can make guesses as to how to set them, but I need guidance on the actual implications of some settings.
Submit DocuSign API Requests: true
Manage Account: false
Send Envelope: true
Manage Templates: Use
DocuSign Desktop Client: false
Transfer Envelopes to User: false
Allow sender to set email language for recipients: false
I assume "Account-Wide Rights" should be false, but under that option in the documentation, it lists RequestStatus as one of calls covered. Will an application embedding the signing process still have sufficient permissions to complete the tasks listed above if "Account-Wide Rights" is false?
Are there other settings or issues I need to consider?
Firstly, thanks for using DocuSign. The answer to your question is in a few different parts. To clarify, I am answering assuming:
1.) You are a current customer (or about to be one) of DocuSign.
2.) You have a plan that is set up to allow integration (IE you aren't trying to do all of this with a personal plan, or something like that).
There are a couple of terms I will use... Sender and Recipient. In this scenario, the THird Party Website is "the sender" and they are Sending the documents through YOUR DocuSign account, using the API. The people who are signing up for your service are going to be Envelope Recipients.
Just like with the post office, someone has to send, and someone gets the envelope.
So far so good.
So what will happen is that the third party website will write some code that knows how to talk to the DocuSign API, and you will need to know:
-DocuSIgn Account ID (this is your DocuSign account)
-The Integrator Key (this is the key that you will need to certify before going live, which identifies all those API calls as coming from them)
-Credentials to access your account (this can be either the actual creds, or a token, etc).
Now, there are two ways to do it. You can either have the third party website make the and send all of the envelopes as if they all came from a single "user" in DocuSign (likely) or if you know that a particular user should send out things, you can do that too.
I am going to assume that all of the sign up packets will be sent as if they came from something like Signup#company.com.
So you will make sure you have a user in your DocuSIgn account with that Email address and name, and make sure that user has the ability to send via the API (there's a setting in DocuSign admin), and all envelopes will be sent as if that "person" sent them.
You will need the settings for that user (the one that will "send" all the envelopes), set as you showed above. You would need the Account Wide access if you wanted to send "on behalf of" a different user. But you aren't doing that, so you should be cool.
The last thing is that you will need to make sure you have an envelope based plan (as opposed to a seat based plan) because otherwise, that one mega-user will look suspicious (sending hundreds of envelopes in an automated fashion).
I hope this answers the question?
-Dan
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