I currently have a working DocuSign integration going using embedded signing. An administrator logs in, provides consent once (auth code grant, extended scope) and the app can generate sign requests in their name to different users without them needing their own DocuSign accounts.
What I'm trying to build now though is for the administrator to sign as well, and preferably only once for the same document which is then sent to different users. So I'd like to make an embedded signing view for the admin to sign once, then use this same half-signed document/template to create multiple embedded signing views for different users. My client would like the DocuSign audit trail to show that the administrator signed each document, so just pre-filling it with an image won't do.
I've been looking at templates, but haven't been able to find examples of or methods for including a sender signature in a template, or embedded template editing. I'm using the eSign package for C# by the way.
So my question is, is this even possible, and if so what's the proper way to achieve it?
If the administrator only needs to sign once and the signed document is then part of many different envelopes/templates, then I would do this:
Have a special/first envelope that the administrator signs with the documents that go in every future signing event.
Have administrator sign and complete envelope.
Download envelope with the signed document with administrator signature.
Use the document from #3 to create templates or new envelopes that then get sent to the different recipients to signature.
This is not the best way to do it, because you are in a way bypassing the signature process. The signer sees the signature of the admin as if they signed the same envelope, but in fact, they didn't.
However, this way solves your problem if you don't want the administrator to have to sign more than once.
DocuSign does not support signature delegation to a software application. So you can't delegate your signature authority to software to sign on your behalf.
In addition to Inbar's answer, your attorney could:
update the language of the contract to not require your company's employee to sign the contract
have the contract refer to a letter signed (via DocuSign) that states that the company is in agreement with the contract. Then include the signed letter and its certificate of completion with the original contract
Related
I'm trying to choose the appropriate authentication flow for my application. I have a portal that users create accounts/login to. When they login for the first time, I want to present them with a "Terms & Conditions" form that requires a valid signature. I want to save the signed form in our database (and link to it from our Admin panel).
I don't necessarily want users to have to create a DocuSign account to sign with. In this previous question: Embedded signers from my application shouldn’t need to login #larry-k says:
If your application makes users (who will become signers) login to the app, that is a form of authentication. You can also turn on authentication options from DocuSign. Eg include KBA (Knowledge Based Authentication) in the signing request.
Here he alludes to making my App Users into Signers, but I'm not sure how this works. I don't want to use Knowledge Based Authentication, I'm more envisioning a SSO process to create a DocuSign User based on the App User information of the user logging in.
The same article suggests PowerForm as a possible solution. What happens after the user signs the form? How can I obtain the signed copies? I gather you cannot mix/match PowerForms with API integrations? I don't want to have to require an admin to login to DocuSign to collect signed forms.
Q: What happens after the user signs the form?
A: just like any other envelope signed with Docusign, it is stored in the DocuSign cloud for the account that created the PowerForm.
A: How can I obtain the signed copies?
Q: You can download them using the eSignature REST API. You can either do this periodically (polling, not recommend) or get webhook notifications using Connect and get the signed PDF this way.
Q: I gather you cannot mix/match PowerForms with API integrations?
A: You can do that! You can have a PowerForm and you can also have separate API integration that downloads the PowerForm signed docs into your website.
For example, let's say I'm building a bulk send workflow with the DocuSign API so that it'll be integrated into a school's website. Teachers want to be able to send out permission slips and such to all the parents through their school portal. There is currently a system already in place that makes use of embedded sending an embedded signing, but of course this only works for single envelopes. Is it possible to have a similar system for bulk?
The bulkSendingCopyRecipient object, defined in the BulkSend:createBulkSendList method page does indeed allow you to set the clientUserId for each bulk send recipient.
So you should be able to create a bulk send of envelopes that include recipients who will use an embedded signing ceremony.
Try it out and let us know if it works! (I haven't tried this myself.)
I'm testing DocuSign integration and I've managed to work out most of the API, but I have one issue I can't resolve.
DESCRIPTION:
- Two documents are added to an envelope
- Each document has one recipient with a SignHere tab for each.
PROBLEM:
When I send the envelope, both recipients see BOTH documents, but I need each recipient to see only the document they have to sign.
STEPS TAKEN:
I read in DS documentation that you need to set the following, which I've done:
eDef.EnforceSignerVisibility = "true";
I also read that you need to enable "Document Visibility" on the account. But when I look at my account properties on the DS site, there is no "Document Visibility" option displayed anywhere.
Does anyone know how to fix this?
The Document Visibility feature is enabled by default on developer sandbox accounts for testing so you should be able to access it. The feature can be found in the Admin section under Sending Settings as seen below.
Can you confirm if you're seeing this option?
I would say that you need to call DocuSign support team and ask them to enable that option for you in your account.
enter image description here
Then, it will be available for your account in admin side.
I hope this help.
It's a little confusing. After contacting support I discovered there are two different ways to sign in to DocuSign, and they use different URL's and have different account numbers.
I was signing in using the standard free account, which apparently has a limited subset of properties available. Once I signed in to the "demo" account, I could see all properties including "Document Visibility."
https://account.docusign.com/#/username
https://account-d.docusign.com/#/username
The first URL is for using a standard account (free or live paid account). The second URL is for signing in using the demo account.
Both accounts have the same email address and password.
When creating a DocuSign package with password protected documents, I realize that when downloading the documents after the signing ceremony, the password protection was removed.
Is that normal ?how does DocuSign do that ? is there a way to provide the password in the API so that the password protections remains the same ?
There are two types of password protection on a PDF document. The first requires a password just to open or access the document. DocuSign doesn't try to circumvent such access protection. To do so would be unethical. If such an access-protected document is uploaded, DocuSign will reject it. It is in this sense that "DocuSign does not support password protected documents."
(The documentation could be clearer and say something like, "DocuSign does not support access-protected documents, i.e. those that require a password to open them.")
The other kind of password controls the ability to change document permissions, e.g. to make a copy of the document, to print the document, or to edit text fields in the document. DocuSign ignores these permissions, on the premise that a copy of the original document has been submitted to DocuSign with the express intention of allowing DocuSign to display it to signers, to digitally sign it and to make other modifications (all ultimately controlled by the user). These permissions are not conveyed to the resulting DocuSign document because they no longer apply.
To respond to the original posted questions:
Depends on which type of password protection you are asking about. Yes, it's normal and expected behavior for DocuSign to remove document permissions. But DocuSign never opens a document which is access-protected by a password.
We do it by simply resetting the permission flags. We already have complete control over the document since it was not password protected against access. (With this level of control, the document permissions password is not needed to change the permission flags.)
If for some reason you want to set password protection or permissions on the resulting signed document, you could do so using any PDF manipulation tool that gives you that capability. The DocuSign API doesn't support setting permissions or the permission password on the resulting document; it generally wouldn't make sense to do so. For example, there are no longer any editable text fields, and the document has been signed; so edit protection would be moot.
is there a way to provide the password in the API so that the password protections remains the same ?
DocuSign does not support this.
From the official Documentation
DocuSign does not support password protected documents.
See this answer for more info.
The scenario is that a signed in user prepares some material and dispatches it to a number of email addresses. In each email, there's a link to the webpage where they visitors can read about something and leave suggestions.
Since I can't request the visitors to register themselves, the pages to be visited are exposed without any authorization. One requires a valid guid to hit the existing page, though.
My question is if there's a good method to provide authorization of users not signed in. Is the guid token sent out to their email accounts the best protection I can offer, given that they can't be bothered to sign in manually themselves?
I rejected the idea of tracking IP numbers since I can't guarantee that they won't be accessing the website from different locations.
You can use the Shared Access Signature approach. Azure uses that for getting the access for the Storage (with the policies like an expiration time, etc), OneDrive uses similar approach for sharing the files, etc.
I think that (you mentioned Azure) you can even use the Azure Storage SAS mechanisms for that. Without expiration and other policies and just a GUID, i believe, is not ideal solution.
I guess user will open the link in the default browser for most. Than there is a js library Fingerprint which allows to identify user unique browser instance. You can inject this library into target webpage which users will visit from their email client(by clicking on the link). So storing guid plus user fingerprint can provide some simple "authorization".
In general store guid and email where this guid was sent is more generic solution. But not so secured as anyone can steal guid and use for impersonation.