Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Current »

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)

    3. SignEnvironmentID (indicates which DocuSign environment will be used)

    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)

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.


  • No labels