DocuSign

About

DocuSign is a service that allows our clients to sign documents, such as quotes and contracts online.

The extension implements three main components:

Low Code configuration: Follow the Low Code configuration provided in the YAML files to configure your Low Code namespace.
Authentication: The OAuth 2 authentication flow authorizes your application to access DocuSign.
Document signature: A set of automation scripts that allow us to send the document into signing, cancel the pending document and check for the signature status.

DocuSign is strict in terms of when your credentials can be used in production.

Make sure that your application complies with their ToS.

Required token scopes

signature: This scope allows the token to perform most document-related operations, such as sending the document for signing and cancelling the document’s signing.
extended: This scope allows us to request new refresh tokens with a full lifetime of ~30days.

Configuration

Configuring a sink route

DocuSign works with OAuth protocol, and this requires us to define a callback endpoint.

Define a sink signature with --method GET and --signature-in-path as the parameters.

Take note of the generated signature. We will refer to it as $SS in the following subsections.

Obtained credentials

Under administration or demo administration, in the case of testing credentials, add a new application.
Specify a descriptive name.
Under "Authentication", select "Authorization Code Grant".
Under "Authentication", select "+ ADD SECRET KEY" — take note of the value; we will need it later and it will not be visible later on.
Under "Additional settings" > "Redirect URIs", select "+ ADD URI". Enter the URI in the form of {{$BASE_URL}}/system/sink/ext_oauth/callback/__sign={{$SS}} (see below example).
Optionally include a link to Privacy Policy and Terms of Use in the following two boxes.

An example of a redirect URL:

https://www.my-crm.com/system/sink/ext_oauth/callback/__sign=d6df0f3...RydWV9

Low Code configuration

For now, you need to do this manually.

Following the .yaml files provided in the extension, create:

required modules,
required pages,
configure automation blocks.

Configure the extension

Lastly, we use the parts obtained in the previous step to configure our extension.

Create a single record in the ext_docusign_configuration module, and populate the following:

In Production?: The field determines if these credentials are used in production. It’s important to note that DocuSign must approve your implementation.
Redirect URL: The field determines the same redirect URL that was used in the above Obtained credentials section. The URL’s must match.
BaseURL: Under administration or demo administration, in the case of testing credentials, take note of the "Account’s Base URI" value.
Account ID: Under administration or demo administration, in the case of testing credentials, take note of the "API Account ID" value.
Integration Key: Under administration or demo administration, in the case of testing credentials, select the application you wish to use, and take note of the "Integration Key" value.
Integration Secret: Insert the "secret key" value, that was generated in the above Obtained credentials section.

Obtaining Tokens

To obtain the access and a refresh token, you must complete the OAuth flow. Invoke the /client-scripts/compose/docusign/RequestConsent.js:default automation script with the help of a button, and the system takes care of the rest.

Refresh tokens expire after approximately 30days, but this can change at any time. When the refresh token expires, you are required to repeat the OAuth flow.