We are currently implementing Docusign within an application. We send contracts to our customer, and set the Signer to our contact person. We want the customer to be able to sign using a different name as we originally supplied in the signer, if some other person within the company does the actual signing.
So we want the signer to change the signer name and initials in the 'Adopt your signature' dialog if needed, but these fields are greyed out and disabled for editing. According to the docs this should be possible: https://support.docusign.com/en/guides/signer-guide-signing-adopt-new
Example: We have a contact named Alice with email address info#example.com. We send the Signing request, and colleague Bob will read the request from the info# mailbox, and sign it. I want Bob to be able to enter his name in the 'Adopt your signature' dialog. I have no knowledge of the existence of Bob within the company.
What I've tried sofar:
In the Docusign admin settings (Settings -> Signing Settings -> Signature Adoption Configuration), the 'Lock recipient name' checkbox is disabled, but this does not result in any changes.
I've also tried to set the agentCanEditName flag on the signer (https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/enveloperecipients/#core-recipient-parameters/) in the API, also without results.
So I have no idea how to allow the signer to change his/her own name, apart from using 'Other actions-> Assign to someone else' from the top menu. Any suggestions?
After sending the question to Docusign support, the conclusion was that they don;t support this. The only way to implement this is by:
Instruct the signer to use the reassign the signing responsibility (https://support.docusign.com/en/guides/signer-guide-signing-change-signer)
Use in-person signing, where the host can opt to change the signer (https://support.docusign.com/en/guides/ndse-user-guide-in-person-signing).
Unfortunately, both methods require prior knowledge about the signing process from the signer. Simply editing a form field during the signer process is not possible.
Thank you for reaching out. Signing groups maybe what you're looking for: https://support.docusign.com/en/guides/ndse-user-guide-signing-groups
It allows one person from a group to sign the documents vs a specific person.
Have you tried to use allowReassign: "true" in the envelopeDefinition. This offer the ability for a signer to forward the envelope to someone else and seems to be close to what you are looking for: https://support.docusign.com/en/guides/signer-guide-signing-change-signer
That being said, back to your problem, I'm not sure what is the real problem but several features are incompatible with Allowing recipient to change their name that might be the case with your call/Account. Do you have anything special enabled?
Related
In our Docusign process - using the REST API - we have one company but two organization names, call them Org A and Org B. Org B uses the API with the authoritative copy flag = 1, so at the end of the packets they're printing, a "Certificate of Completion" and two pages of legal boilerplate are appended to the envelope. Org A doesn't use the flag, their documents don't get the certificate and boilerplate.
Question #1: The certificate and boilerplate are not in the document Org B is sending for signature, so can I assume that's part of the authoritative copy process?
The legal boilerplate has the parent company's name - and my email - throughout the text. Org B would like their own information in that space.
Question #2: They have their own credentials on the Docusign account, so is that sort of customization possible?
So, there are two things you are refering to here and there's some confusion.
Certificate of Completion. This one is generated by DocuSign for every transaction (every envelope). It doesn't have to be visible or downloaded by customers, but it's always there. If you ask for it in your code, you get it. This is not a document to be signed or be acted on. It's just a summary of everything that happened and it's used for legal purposes.
The second thing you refer to as "boilerplate" is called the Electronic Record and Signature Disclosure and is something that recipients have to agree to once and forever (unless they retract or change their information like email or name). This one is controlled by DocuSign, if DocuSign determine you are a new signer that didn't yet consent to the ERSD - then you're asked to do so. As a developer you have no control over this process.
I need to disable the "Decline to Sign" option in the other actions drop down to restrict the user to decline. Is there any option in DocuSign to do that?
I don't believe it's possible to remove the "Decline" button at the envelope level or recipient level. But you can control the visibility of the Decline button via the Brand-level setting DocuSign_DeclineAllow (set to a boolean value) in the Signing Resource File.
See this answer for more information.
https://support.docusign.com/en/guides/docusign-signing-resource-file-v2-0 might help.
DocuSign_DeclineAllow
is the field name
Note that the signer can simply close the signing ceremony's browser tab...so they can always, effectively, "decline to sign."
The usual way to handle this is to not allow the user to proceed until after they've signed. Hiding the Decline to Sign button is security through obscurity (which is no security at all).
I am using DocuSign with my web application. Whenever I try to sign in the document, the first time I am asked for adopting a signature. From next time onwards, docusign uses the same saved signatire every time even if I need to sign a new document. I need a feature where the recipient should be asked to adopt and sign everytime he visits a new document. But this is not happening. Is there any way we can do it? If not, do we have an option in DocuSign recipient view where the recipient can select a new signature at his will?
The querstion in DocuSign remembers signature. Want to turn that feature off
is similar to mine. I tried the answers mentioned in the post but it did not help.
It sounds like you are using captive recipients and embedded signing. In this scenario, the signer is captive to your application. So, if you define a recipient a 2nd time using the same name, email and client user ID, DocuSign will use the signature the recipient adopted the first time around.
Two ways around this.
First, make the client user ID random. This way, the recipient is always unique and will always adopt a new signature.
Second, delete the signers signature from your account after the envelope is completed. This way, they would have to adopt again even if you use the same client user id.
There's definitely an option for this. Unfortunately I don't know which one it is.
Plus it might be one of the account options that is set by DocuSign Customer Service.
If you're working with a salesrep, ask him or her to have the setting updated for your developer account.
If you simply want to ensure (for your demos and development) that the signer will always be asked to adopt a signature, you can do that by always using a new {name, email} tuple.
Eg if you send a doc to {Joe Signer, joe#signer.com} the first time, send to {Joe A. Signer, joe#signer.com} the second time.
I use this technique during demos to ensure that the demonstration will include the signature adoption step.
I am using the Embedded Signing API. The prototype is working great !!
Thanks for the examples.
My question is - Is it necessary to have a unique clientUserId property for every request that is made ? Does it have to stored in the database? I have read the api documents and they all mention something along these lines :
if the clientUserId is present and it's value is not null then the recipient is an embedded recipient, and they can access the envelope through a URL token instead of a hyperlink in an email.
In my code 'clientUserId' is hardcoded to 1 while creating an envelope and has the same value when getting an url for launching the embedded signing view (aka recipient view).
Is that okay or do I have to generate a unique clientUserId for every request and store it in a database ?
Thanks
Posting Luis' comment as it should be an answer...
If you provide the same (email, name, clientUserID) triplet, then the signer does not have to re-adopt their signature - DocuSign will be able to identify the signer and leverage their previously adopted signature. Otherwise, the signer will have to draw in their signature at every signature/initial here tab assigned to them in the envelope.
Generally speaking the clientUserID should be something meaningful and unique within your organization to identify the signer/customer; however it's still ok to use simple values as you have mentioned if your specific use-case does not call for further granulation/definition of signers, and you don't mind having them to explicitly sign each time.
On a standard web signup form, users are required to have a unique email for the site.
if the email is already in use, a new user cannot be created with that email - but this opens op for exploiting this to find out, what emails are members of the site (at least check if a specific email is in use).
Making sure a bot cannot mass-query is fairly straightforward - but is there a way to avoid it entirely?
The best thing I can come up with is letting the user create process fail with an unknown error and shooting an email to the address in the background, explaining password reset procedures.
Am I missing a better option?
Update:
I want to avoid taking the new user out of the registration process for the 99.9% of the time, when the email is actually unique. So halting the registration process to wait for the user to click a link in an email is not a perfect solution, although maybe viable in some use cases.
Let the registration continue as normal, but in the confirmation email you should say:
"You allready have an accout bla, click here to cancel this registration, or continue with new registration and delete your current account"
That way, the spammers never know the better, and its very user friendly.
You could print on the web-page something along this:
An email is sent to you to verify the email address. Check your mail and click the included (shared-secret) link.
I.e. you probably have to verify the users email anyway, s.t. you can do it at this location of dialog ...
Many sites send a mail to the specified email address containing a randomly generated verification code and only accept the user registration once the user has confirmed they were able to read that mail and obtain the verification code. Usually the mail contains an URL that the user can simply click to confirm.
If you do that, all you need to do is make the confirmation email instead tell the user that they've already registered and explain the password reset procedure.
Whatever web development framework probably has a package that handles confirmation mails.
Note that you have to think about the case where a user had an email address and used it to register to your site, then they vanished without changing the address and stopped using the address, and another user now has the address and wants to register. There's no easy answer here.
ADDED: You add that you don't want a confirmation email so that the registration proceeds immediately. This requirement is contradictory with unique email addresses, because you don't know that the email address supplied by the user is legitimate until it's been confirmed, and there's no point in enforcing the uniqueness of a user-chosen string that just happens to be formatted like an email address (if you want a unique user name, it doesn't need to be formatted like an email address).
If you want to keep instant registration, you'll have to treat email addresses as just an untrusted text field until confirmed. That means that every action that requires your site to send a mail must bomb out if the user hasn't confirm his email address. The confirmation process remains pretty much the same, but now, if the address is a duplicate, the user must either be given the option to merge the two accounts (which sound difficult), or told that he must close one of the two accounts or change the email address associated with one of the two accounts.