DocuSign

Basic DocuSign Workflow

E-signing a document with DocuSign generally requires three major steps:

  1. Creating an envelope containing documents, recipient information, and sign field locations (performed by Quik!)

  2. Calling DocuSign for the status of the envelope (performed by Customer)

  3. Downloading, processing, archiving, and/or submitting the signed document (performed by Customer)

The first step requires significant processing and set-up including:

  • Creating a flattened, read-only PDF with form data

  • Tagging the form with signature fields with location and role data in XML

  • Setting up recipients to sign and receive forms, including attributes including:

    • Signing order

    • Recipient email addresses

    • Security settings for identity checks

  • Initiating the e-sign process with DocuSign

Due to the complexity of the document, fields, roles, recipients and more, the process to generate the necessary data and final document to send DocuSign must be performed by a Quik! server. To enable this architecture, Quik! provides web service methods that give customers various methods to perform this first step.

The second and third step, to poll for status and download the final document, is the responsibility of the user interface, workflow and archive system that the customer is using. Since Quik! does not provide or manage the user experience beyond filling out the form and kicking off the e-sign process, the customer must call the DocuSign API directly using the EnvelopeID to get the status of the envelope and to download the final document for archival and workflow purposes.

Using DocuSign in Quik! 

Important: All customers and partners must have a valid DocuSign account in order to use Quik! with DocuSign (Quik! is not a re-seller of DocuSign).

All Quik! HTML forms are designed for seamless e-signature integration with DocuSign. While there are three implementation models to integrate DocuSign with Quik!, the user experience of all three begin with the user clicking the "SIGN" button on the form viewer to start the e-sign process. The form will display an pop-up window (called the e-sign pop-up) that asks for signer information required by DocuSign (called "envelope information") including signer name, email, authentication type, etc. The user will complete the data fields and click SEND. Depending on the integration method used, this event will then send the form data to either Quik! servers or customer servers to process and create the envelope with DocuSign so that signers can begin e-signing the form.

Please review the technical requirements below for integrating Quik! with DocuSign regardless of the implementation model used:

  1. Create an OAuth token with DocuSign - In order for users to sign, the Quik! Master Account must be set up with an OAuth token for the user/customer's DocuSign account (partners will need to set up OAuth Tokens for each of their customer accounts). OAuth tokens can be set up on the Quik! Forms Enterprise Manager or via web service (REST or SOAP). Partners who offer Quik! to multiple customers will need to address how each of their customers will set up OAuth tokens on their Quik! accounts. The ideal solution is for the partner to build a user interface that asks the customer to enter their DocuSign credentials which can be passed to our web service to establish the token. Quik! does not store the customer credentials, just the token (which never expires). This enables customers to change their DocuSign password without affecting their integration with Quik!. Note that customers must identify their DocuSign environment (NA1, NA2, Demo, etc.) to establish the token. If customers don't know which environment to select, Quik! recommends contacting their representative at DocuSign, and they will inform. Alternatively, you can check your accounts environment by navigating to Settings > Plan and Billing within your Docusign account.

  2. Set relevant DocuSign properties in the request when generating forms - Once a token is established, customers must include the following properties in their Execute request when generating HTML forms:

    1. ESignTypeDocuSign (establishes DocuSign as the e-signature service used)

    2. AuthUserID (indicates which OAuth token will be used, also known as ‘CustomerUserID’ when using /docusign/oathtokens)

    3. SignEnvironmentID (indicates which DocuSign environment will be used, see Docusign environment table below)

    4. SignCallBackURL or SignURL (indicates which implementation model will be used)

    5. QuikFormID (indicates which forms will be generated, always required in any Execute request)

    6. Any other DocuSign settings (optional - see a complete list of DocuSign properties here)

 

Docusign Environments:


SignEnvironmentID

Environment

SignEnvironmentID

Environment

1

DocuSign Production NA1 (www.docusign.net)

2

DocuSign Demo (demo.docusign.net)

3

DocuSign Production NA2 (na2.docusign.net)

4

DocuSign Production EU1 (eu1.docusign.net)

5

DocuSign Preview (preview.docusign.net)

9

DocuSign Production NA3 (na3.docusign.net)

10

DocuSign Production NA4 (na4.docusign.net)

11

DocuSign Production NA5 (na5.docusign.net)

12

"DocuSign Production NA6 (na6.docusign.net)

13

DocuSign Production NA7 (na7.docusign.net)

14

DocuSign Production NA8 (na8.docusign.net)

15

DocuSign Production NA9 (na9.docusign.net)

16

DocuSign Production NA10 (na10.docusign.net)

Sample REST Execute request

{ "HostFormOnQuik": true, "QuikFormID": "12", "ESignType": { "Type":"Docusign", "AuthUserID":"YourAuthUserID", "SignCallBackURL":"YourSignCallBackURL", "SignEnvironmentID":2 , } }


Lastly, it is important to understand which forms can be e-signed in Quik!. See Enable E-Signatures on Forms for more information on esignability settings.

Now you are ready to build a DocuSign integration. See the following sections on using one of the three implementation models.



For help regarding Quik! Forms and the Quik! API
Email: support@quikforms.com | Phone: (877) 456-QUIK