I am building up an envelope using multiple templates through the API using CreateEnvelopeFromTemplates.
Sometimes the server side templates used to build the envelope contain the same logical fields
e.g. two templates used, both have fields of "Account Number"
How do I make it so when the signer enters data in one account number field, it updates the other account number field with the same data immediately in the signing interface?
It is required to prevent the signer from typing one account number on one document then a different account number on the other document in the same template.
The business logic for the document requires this so removing the duplicate account number fields would not be an option either.
There's an account-level setting that you can configure in DocuSign to force this behavior (i.e., ensure that like-named fields throughout all Documents in an Envelope always contain the same values). Simply login to the DocuSign web console (as a user with Administrator rights), navigate to "Preferences >> Features" and on the Features page, set Data Population Scope to "Envelope". (See page 27 of the DocuSign Admin guide: http://www.docusign.com/sites/default/files/Account%20Administration%20Reference%20Guide.pdf)
Because this is controlled via DocuSign account-level setting, there's nothing special you need to do in your CreateEnvelopeFromTemplates API call -- just configure the account setting and you should be good to go.
Related
I have a template that is configured with a recipient that has read only fields and only a signature control. The read only fields/tabs are populated in the view request my API sends to DocuSign to get the signature url. However I'd like to create a new duplicate template that does not have the signature control and is configured to only require the recipient to view the document. This way the only signature event that is set by DocuSign is "viewing_complete" and not "signing_complete" when they're done viewing the template/document.
Edit: The purpose of this is it gives the user a read only view of the template/document so they can catch any errors in the mapped fields/tabs to give them a chance to correct it before signing a final version.
Not sure if you want to create this template from the API or from the web app.
You can easily do this from the web app and if you want to do from the API, you can get a log of the API calls to see how it was done.
When you create a template from the web app, in the first screen, you can pick recipients and there's a drop down with different types of recipients:
Select the "Needs to View" recipient type for your needs.
It's not possible to configure a template to accept populated tabs for a recipient that is set as Needs to View or to preview an envelope recipient view and have the tabs populated, but not show the Signature control.
We have a problem where individual user are registered to our application but with permission to see a single set of data. These are all setup as local accounts.
At the moment each user is associated with a single set of data.
We now need to be able to link different sets of data to the same user.
After or during login the user would be presented with the options that are linked to their account and it would remember this throughout their session.
We would also need to be able to add new permissions to an account through an API.
What is the best way of achieving this through Azure B2C ideally without using custom policies if possible.
If you want to insert a page during the authentication journey (sign in) which reads the users access ability, and then allow the user to choose one of these options, and then issue that choice in the token, you will need a custom policy. I am assuming that this list could be different for each user ("options that are linked to their account").
If that list of options is stored on the user object, then it needs to be read from the user, and a dynamic radio box selection be presented to the user.
You need to create a comma delimited list and insert it into a claim, if its already stored as comma delimited, or some other delimited list, then you are already good to go. Otherwise youll need to have B2C send the data to a Rest api to build a comma delimited list.
That claim needs to be shown on the page after 'sign in' in a text box via B2C (hidden with CSS), where javascript on your custom HTML page (configured in B2C) builds a radio box from that list in the hidden text box.
Then the javascript needs to record the choice into another B2C rendered text box. You should then verify at B2C or via Rest api whether the submitted value was valid.
Then issue that value into the token.
As mentioned on the link https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-code-grant, there are three access scopes DocuSign allows to fetch user's data : signature, extended and impersonation.
I am looking for a scope which allows me only read access. I need to build a dashboard of various activities/updates (getting the status of all envelopes, etc) of all the users of DocuSign at my company.
As per my understanding, I need 'signature' permissions/scope at-least as described under heading "Admin consent for internal applications" on https://developers.docusign.com/esign-rest-api/guides/authentication/obtaining-consent.
This means I will have access to create and delete the envelopes as well. Couldn't understand the 'extended' scope as well (as per my reading, it is helping to extend the access tokens validity and usage of refresh token any number of times).
Is their any other permission type (read scope only) that I can use based on my criteria?
Re read only scope. Not at this time. And since you want stats for all users' envelopes, you'll need Account Wide Rights. Full Admin is not necessary.
Perhaps an alternative might be to use the connect webhook system, and then track statistics as your app receives each notification message about changes to the users' envelopes.
I have a DocuSign template template-1 with multiple recipient roles say signerrole-1 and signerrole-2.
Template-1 has multiple signature tabs, viz, signtab-1 & signtab-2.
Using REST API, I am trying to create the envelope so signerrole-1 signs signtab-1 and signerrole-2 signs signtab-2.
I am not clear on how to associate signerrole-1 role and signerrole-2 role to signtab-1 and signtab-2 respectively using api java.
The template associates roles with tabs (fields) in the document(s).
When you create the template, you create signature tabs for the specific roles. It is easiest to do this by using the Web interface to DocuSign but you can also do this using the Create Template API call.
Later, when you submit a new envelope using the template, you associate specific people or signing groups with the roles defined by the template. See this recipe for an example.
When you create the envelope to be sent, you do not create or reference the signing tabs. They are defined by the template.
For embedded signing , when a user starts the signing session for the first time, there is a disclaimer that can be shown to him, I know that this can be customized in the preferences.
But where do i show/hide/change the actual buttons that are shown to the user , for example there is a Review, Decline, Finish Later and Sign on paper buttons shown to him. I need to hide last two of those four buttons, How and where can i do this ?
The code i am using is from the api code walkthough for java and there is a template setup for our demo account that we are showing to the user.
Also is there a way to customize the way the button looks or can we upload a button that we already have within our site? .
Thanks in advance...
Generally speaking, there are several mechanisms for controlling things like which buttons (functions/features) are available to Signers:
Account-level settings (controlled by the DocuSign account admin via the web console: Preferences >> Features)
Brand-level settings (controlled by the DocuSign account admin, via customization of "Resource file(s)")
Template-level settings (controlled by anyone with access to edit the Template's settings in the web console)
Envelope-level settings (controlled by the sender of an envelope either via parameters set with the API call, or when manually sending an envelope via the web console)
The visibility of the Decline button can be controlled via the following means:
Brand-level setting (in the Signing Resource File): DocuSign_DeclineAllow boolean setting
The visibility of the Finish Later button can be controlled via the following means:
Brand-level setting (in the Signing Resource File): DocuSign_FinishLaterAllow boolean setting
The visibility of the Sign on Paper button can be controlled via the following means:
account-level setting (Preferences >> Features): Sign on paper checkbox
template-level setting: Allow recipient(s) to sign on paper. checkbox
envelope-level setting (via API): enableWetSign boolean flag
The visibility of the Change Signer button can be controlled via the following means:
account-level setting (preferences >> features): signers can reassign envelopes checkbox
template-level setting: Allow recipient(s) to change signing responsibility.
envelope-level setting (via API): allowReassign boolean flag
The following guides may be helpful to you:
Branding guide:
REST API guide:
Administrator guide:
To hide the Finish Later button, you'll need to edit the Signing Resource file(s) for the Brand you plan to use with your envelopes to set the DocuSign_FinishLaterAllow element value to false -- including especially the "Captive" resource file for the "embedded signer" scenario. See the Branding Guide I've linked to above for information about accessing/modifying the Signing Resource file(s). Then, simply associate that Brand when sending the envelope via API by specifying the brandId property as part of the API request.
To hide the Sign On Paper button, you can use the Account-level setting, or the Template setting (if accessible/visible), or Envelope-level setting (set enableWetSign = false in the API call).
Regarding the question about button style -- while it's technically feasible for you to modify the CSS used for various elements of the DocuSign UI (if the "allow css upload" feature is enabled for your DocuSign account) -- I'd highly recommend against it. Modifying the CSS file can have very unpredicible results, and there's no easy way to "undo" your changes and get back to square one. Save yourself a lot of time and frustration, and live with the existing/default button style :)