admin_consent_scope & prod vs dev separation

admin_consent_scope & prod vs dev separation

Problem Description:

I almost finished an end-to-end integration with DocuSign within our web application.
Here are the high level features:

1 – We allow a user to connect his DocuSign account in our user settings using the JWT Authorization Flow.

• We craft the consent url if user never connected (state in our
  database).
• The user consent and then we create the JWT token using his ‘sub’
  user guid value and obtain an access token.

2 – The user can create a signature request (from file or template) for clients in our app (not having a DocuSign account)

• We use the previously obtained access token from JWT
• We create the envelope, add recipients and set their clientUserId
  prop from our database

3 – Clients see the signature request in our app and click to sign the document(s).

• The signature object is stored in our db with the envelope_id and an
  association to the envelope’s sender access token data so we can
  retrieve the original access token to call the create recipient view
  API
• Using this token, we get the DocuSign signature view url

4 – After the envelope creation, all the signature states are driven by the Connect(Webhook) that matches events with the envelope_id and recipients clientUserId to update our database and send notifications.

Questions:

1. About Step 1 above, I have read the documentation and it seems I can
   pass an extra ‘admin_consent_scope’ attribute. I am not using it
   right now and I can obtain a valid token, should I use it ?
2. How should we approach the dev/qa/stg/prod isolation ? Should I
   create a complete separate DocuSign account for each ? I can create
   different apps/integration keys in a single account but the Connect
   endpoints does not seem to be linkable to those apps

Solution – 1

1. To obtain admin consent you need to set up an organization
2. Then you can obtain administrative consent for the entire organization. It is done separately in production from the developer account.
3. For dev and prod you have everything separate except the IK (Integration Key) which is promoted to prod after you go live. But you have to have separate accounts, consent, keys and any other configuration element in production.

Solution – 2

About Step 1 above, I have read the documentation and it seems I can pass an extra ‘admin_consent_scope’ attribute. I am not using it right now and I can obtain a valid token, should I use it ?

I recommend that you implement a smooth individual consent flow (it sounds like you did) rather then using Admin Consent:

In order for an ISV’s application to use Admin Consent, your customer needs:

1. Organization feature, and set up an org (join accounts to the org)
2. Claim the DNS email domain used in the email addresses of the org users
3. Implement the Admin Consent flow in your ISV application

Note that if there are users who have a different email address root domain (eg @bigcompany.com plus @bigcompanyfinance.com) then either the additional domain needs to be claimed (more than one can be claimed) or those users must use individual consent.

Bottom line on Admin Consent

• Most customers don’t have Orgs
• You don’t want to require your customers to implement all of the above in order to use your application’s integration with DocuSign.
• Recommended: implement a smooth individual consent flow if you’re using JWT OAuth

How should we approach the dev/qa/stg/prod isolation ? Should I create a complete separate DocuSign account for each ? I can create different apps/integration keys in a single account but the Connect endpoints does not seem to be linkable to those apps

I don’t understand what you mean by "Connect endpoints does not seem to be linkable to those apps"

You can create separate demo accounts for your team’s different roles.

Also, as Inbar noted, the demo version of your client ID (integration key) is completely different (different set of settings, etc) from the production version. Except, both the demo and production client IDs share the same guid.