My project requirement is as below:
With out any user interaction in browser we need to generate unique URL for each user to sign the uploaded document.
Assume we have a backend java class running in backend and we have to achieve this without any customer interaction.
Problems:
We are not able to follow the steps given by docusign to agree for consent via administrator. We dont see the organization Tab in our demo account.
It says to contact admin - who is the admin for a demo account ?
You don't need User Consent or Admin Consent to sign the uploaded document. Signing is part of workflow, and signing can be done either remote or embedded. Remote Signing means DocuSign will send an email to the recipient (Signers) of the envelope and they have to complete the Signing process from the DocuSign email only. Whereas, embedded Signing is, signers have to come to your App and your App will be hosting the Signing ceremony inside your App, and generating the Signing URL using DS APIs, example of embedded Signing is available here or sample example. In no case, you need User or Admin consent, User/Admin Consent is needed for Sender's authentication normally, where your App want to do something for them on the user's behalf, for instance send an envelope for a user, then you need the User or Admin Consent.
Admin Consent can be achieved by Organization module in DocuSign, in which you have to claim the email domains of the user in DocuSign, these users should have email (DS Username) in the claimed email domain. Using Admin Consent you cannot generate Access token for them if they belong to email domain like GMail, Yahoo, as you cannot claim their domain in DocuSign. To enable Organization in your DS Account, I would assume you would have purchased DocuSign subscription for PROD DS Account, you need to contact your PROD DS Account's Account Manager, and DS AM can enable Organization from backend for your Demo Account for your Dev purpose (Org Admin comes with extra price, so you need to check with your AM if its included in your subscription).
Related
I am trying to integrate Docusign within my web app where users will be able to generate the documents to sign with some information from the web app integrated into Docusign document.
For JWT or Auth Code Grant workflows, Docusign needs the user to sign in to Docusign account to be able to generate an access token.
Now each user cannot really sign into Docusign to generate a document. What's he best way to create Docusign envelops without the end user logging into Docusign account?
If your app's users have DocuSign user accounts, then use Authorization Code grant flow: the user authenticates with DocuSign and then your app uses the user's access_token.
If your app's users do not have DocuSign user accounts (eg the users are your end customers), then:
Create a "system user" in your DocuSign account such as "finance#yourcompany.com"
Authenticate to DocuSign as the system user and grant consent to the application. See this blog post for more.
The above steps are one time only!
Then, when your app is used in production:
When a user starts to use your application, your application uses the JWT grant flow to impersonate the system user.
Via the JWT grant flow, your app now has an access_token that it can use with the DocuSign APIs. Your app can use the access_token to create an envelope, then create a recipient view (embedded signing ceremony)
The app's user can sign via the embedded signing ceremony.
Remember to cache the access_token for the system user. Continue to re-use the access_token until it is about to expire.
See this SO answer for info on caching the access_token
For context, we are currently developing a DocuSign integration on our DMS web app product. So far what we have done is that the web app's admin (we assume this would be someone like our customer's IT) can set up the integration by entering API Account ID, Integration Key, Secret Key, Access Token & Refresh Token. All these information was taken/generated using a DocuSign admin account. With this, we see that any user using the DMS can send out signing requests (via API) without logging in to their own DocuSign account.
However, we realised this means that all signing requests will be sent using the common DocuSign admin account, i.e. the envelopes originate from the admin account and all signed documents also stored in the DocuSign admin account. This is not what we want as the DocuSign admin can see confidential signed documents.
I'm quite confused and would like to seek advise on how should we go about this? Ideally, it is that User A of the DMS can associate his DocuSign account with his DMS account. So that when User A sends out the signing request from our DMS, the signer receives the email from DocuSign showing it is from that user instead of the common admin account.
Also, it looks like the go-live process would have to take place for each customer that is using our DMS? Does it mean like each customer need to have their DocuSign developer account so that the integration key can get promoted to production environment? Or am I in the wrong direction & should look at Partner Integration as ISV?
If your DMS system is a SAAS system, then you can have 1 integration key (client id) for your integration with DocuSign. In other words, your individual customers would NOT have their own integration keys, secrets, etc.
One integration key is the best, if your application's architecture can support it. To do so, you'll want to have one or just a few Redirect URIs to enable your users (who also have DocuSign accounts) to authenticate with DocuSign.
Your app then stores the resulting access token, refresh token, and expiration date for each of your users who have authenticated with DocuSign.
This way, as you say, when your users send out an envelope for signing, it will belong to their own DocuSign account, and will show them as the sender.
When your customer wants to send via DocuSign, your app checks the expiration date for the person's access token. If the access token has expired, then use the refresh token to get a new access token and a new refresh token.
The refresh token is stored in your app's non-volatile storage (encrypted is best) so you can use it days or weeks later for the user. That way they don't have to re-authenticate with DocuSign. For this case, use scopes signature%20extended
For the account_id info, use the user's default account and enable them to switch to another account if they wish.
More information:
Getting started for ISVs
API integration guidelines
Error are coming on live integration key of docusign
Error while requesting server, received a non successful HTTP code [400] with response Body: O:8:"stdClass":1:{s:5:"error";s:16:"consent_required";}
I was faced issue on demo docusign then i was enable SSO for my DocuSign organization on demo Docusign
Then solved this issue(Error) and working properly on demo docusign .
Because there was Docusign Admin to enable SSO.
But Docusign Admin not available on live docusign account.
How to solved this Error on live Docusign
Error s:5:"error";s:16:"consent_required";
I have done already contact with support team
In order to grant consent, you'll either need to do an Individual Consent workflow for each user, or contact the Sales team to purchase the Admin module.
A more in-depth look at the JWT Consent options is available on the DocuSign blog - https://www.docusign.com/blog/developers/oauth-jwt-granting-consent
The short answer is that Individual Consent is always available, but requires action by each individual user (Access the consent URL, authenticate, grant consent). Admin Consent is only available if you have the Admin module and a claimed domain, but allows an Organization Admin to grant consent on behalf of everyone under that claimed domain.
Is it perhaps because the DocuSign user you use to log into the live system is not (yet) an administrator.
I've developed an invokable Apex method that leverages the DocuSign Apex Toolkit for preparing and sending an envelope via a Salesforce flow.
The only issue I'm having is when it is invoked by a Salesforce user, that has been added as a DocuSign user, but has not yet gone through the OAuth flow to connect Salesforce to DocuSign for their user account.
A workaround is that I have that new user click a standard "Send with DocuSign" button an any record, which then shows the "Before you can use DocuSign, you must grant consent for this application to make requests on your behalf." message and a button to start and complete the OAuth flow. Once this is done I can go back to my flow and it will successfully complete as that user.
Any ideas how I can "pre-authorize" users, or check for authorization as part of the flow (is this data stored in Salesforce), or at least find a way to get to this "Authorize" screen in Salesforce without needing to begin the process of sending an envelope?
Thanks
Matt
Yes, the administrator for the account can grant "blanket" consent, known as administrative consent, for the relevant integration key (client id) and scope(s) needed by your application.
To do so:
The account needs the Admin feature Access Management with SSO You can have this feature enabled for your developer sandbox account by email request to go-live#docusign.com. Contact your DocuSign account manager for adding the feature to a production account.
You need to claim the email domain for your users.
Use the Admin tool's Connected Apps tile to grant administrative consent to your users in the claimed to domain to the application.
The above assumes that you are supplying the integration key to your Apex application.
If you're using an integration key supplied by DocuSign, then you also need to use the Admin consent for external applications API.
If you're using an integration key supplied by DocuSign as part of a DocuSign for Salesforce product, then I would first ensure that the product is enabled for everyone in your account; that may take care of your app's consent issue.
Re: detecting if consent is required
DocuSign responds with a specific consent_required error if consent is needed. So check the error response of your call. See APIError
I implemented Authorisation Code Grant like the example code provided using passport and it is working fine.
One thing that is confusing me is that when obtaining a new token, passport required authentication.
Are these supposed to be the credentials of our admin account? or, once we go live, is it the credentials of our user who is trying to sign a document (using embedded signing).
Thanks!
When you say
our user who is trying to sign a document (using embedded signing)
note that signers do not need a DocuSign account. They can have one, but they don't need one.
If you want to use embedded signing for a signer who does not have a DocuSign account, use a system account (and JWT Grant) to obtain the Signing Ceremony URL. (A system account can also be used to create the envelope, if necessary.)
Added
A "system account" is a user account in your DocuSign account that represents a generic, system, sender. For example, create a user account "Sales department." Then use JWT Grant (on your backend web server) to impersonate the Sales department user. The result is an access token that your application can use to create envelopes and then have them signed by your website visitors.
The "Sales department" user will be created and controlled by your system administrator. But there is no need for the system administrator to login every morning -- once the system administrator gives consent for the application to impersonate the Sales department user, your application can create new access tokens as needed that impersonate the Sales Department user.
The latter. When using Auth Code Grant, every user of your application will have to log into DocuSign and their credentials will be used.
Read more over here - https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-code-grant