Every customer’s implementation of the Quik! APIs to generate forms is different. However, most implementations follow a common set of objectives and typical milestones.

This guide assumes the customer has done sufficient planning, analysis, research with users and has defined a user experience with appropriate outcomes to achieve adoption with their users. The design phase is ignored in this implementation plan and should be a critical part of a succesful implementation.

Phase 0 - POC - Proof of Concept

We find that most customers want to perform a POC to verify that Quik! can accomplish their objectives. Because the API to generate a form has approximately 250 different configuration options, there’s a lot of possibilities that are a little overwhelming to figure out without trying the software. Our team is happy to set up prospective customers with a sandbox account in order to start playing around and developing the basics of their implementation.

POC Components

Most POCs consist of validating the ability to do one or more of the following actions, in the order listed:

1. Authenticate and use APIs

2. Generate forms

3. E-sign forms

4. Map fields

5. Search for forms

6. Bundle forms together

7. Complete complex form workflows

These implementation items will be explored further in the next section.

Phase 1 - Implement Core Functionality

The core functions needed to use the Quik! APIs include:

1. Authentication

2. Generate Forms

3. E-Sign Forms

4. Map Fields

Authentication

Authentication with Quik! APIs can ONLY be done using Master Credentials. It’s important that you receive these special credentials from our team and only use them with the APIs. Do not let any user have the master credentials for logging in as a user might change the password and cause your API integration to stop working.

API authentication uses secure OAuth methodology as explained here: REST Authentication

Generate Forms

Generating forms with Quik! is rather simple - provide your authentication token and at least one FormID (the unique identifier for a form you want to view) to the Execute HTML or PDF method and a form will be generated.

For a POC, generating a form via Postman can take just a few minutes.

For your implementation, form generation can support approximately 250 parameters that can tailor the user experience to your specific needs. The types of configurations range from:

• Form Viewer Settings - how forms look to the user

• E-Sign Settings - settings specific to DocuSign and SIGNiX to control the e-sign experience

• Field Data and Attributes - setting field data and field-level attributes to control how fields work

• Form Buttons and Events - controlling how buttons on the form work or appear

• Custom Javascripts - adding in custom javascripts to do more than the average form

A full list of properties, methods and configuration use cases can be found in our Implementation guide page: Implementation

E-Sign Forms

In order to e-sign forms with Quik! you must have an account with either DocuSign or SIGNiX and then configure the form request with the appropriate settings. There are also implementation options for e-signature, but the fastest and easiest approach is called the Callback method (Callback Model).

While SIGNiX is perhaps an easier implementation than DocuSign, DocuSign does offer more capabilities and options. For example, many customers are looking to use these DocuSign features:

• Draft Mode - sending forms to DocuSign and creating envelopes in draft mode so users can make changes before sending to their clients.

• Document Visibility - setting which e-sign recipients can view which documents

• Editable Fields - setting which fields are editable, read-only or flattened in the e-sign solution

• Send on Behalf Of - setting who the sender is when the Quik! user is not the sender

• Recipient Authentication - setting how to authenticate the recipient before allowing them to sign

• Branding - setting the BrandID for the sender so recipients know who is sending the e-sign email

Map Fields

Every Quik! form is built using the same field naming definition called the Quik! Field Definition (The Quik! Field Definition Guide).

By using a standardized definition of fields, you can map your data source elements to the Quik! Field Definition instead of the specific form. For example, a person’s first name never changes, so why must they enter it every time the first name field is repeated?

With Quik!, the field name is always the same (e.g. “FName”) across all forms which eliminates the need to retype the data over and over again. From a field mapping perspective this means you can map your field once to the Quik! field and know that your data will reliably flow to any form your user picks.

Of course there are always exceptions to the rules, but the high majority of fields can be mapped generically and appear on all forms. There are some form-specific fields that you’ll want to handle separately and this level of mapping is usually done as a latter step in the implementation.

For full details, please see the field definition guide and related field spreadsheets The Quik! Field Definition Guide .

Phase 2 - Implement User Interface Components

With the core functionality in place, the next phase is to implement and refine the user experience related to forms. This is the point in which most customer implementations vary as their user experiences are specific to their needs and systems. For the purpose of this guide, we will make some basic assumptions about the user experience and expect the reader to imagine and plan their own scenario.

The steps in this phase include:

1. Searching and selecting for forms

2. Using form bundles

3. Configure complex form generation features

4. Configure complex e-sign features

5. Configure complex workflow

Form Searches

When it comes to finding and selecting forms, there are generally two approaches:

• Users search for forms

• Forms are chosen for the user

Search

If your firm is accessing hundreds or thousands of forms in the Quik! library you’ll want to give users the ability to search for forms. This requires that you set up a user interface to perform the form search. The typical steps include:

1. Choose one or more companies to search, enter any search keywords, choose a state, and other search criteria.

2. Display results to the user to select the forms they want to generate

A search should allow the user to select one or more forms to bundle together in a single form package. Additionally, consider letting the user add duplicate forms to the form package (e.g. two account transfer forms).

Your user interface should contemplate the following elements:

• A form search screen

• A form results screen

• A “shopping-cart” to hold the forms that a user selects

Preselect Forms

If you have a small set of forms (say under 500) and want your process to determine which forms a user needs (e.g. a wizard that asks questions), then you either need to build your own method for choosing forms or consider using Form Bundles (aka Form Groups).

If your process will determine which forms the user needs, then your system will need to contemplate the following elements:

• The wizard or set of questions that leads to a particular set of forms

• How to manage the Quik! FormID you want to generate for each possible outcome

  • Form Bundles is a great way to group a set of form results together

• Whether or not to let the user add or remove forms from the predetermined set of forms (e.g. optional forms)

Form Bundles

For most API implementations, Form Bundles (or they may be called Form Groups in the APIs) are often used behind the scenes to deliver a set of forms based on the outcome of some set of questions that users answered. In other words, the Form Bundle ID simplifies programmatically picking the result instead of trying to maintain a list of FormIDs in code. Since Form Bundles can be built and managed within the Quik! account admin feature (or via API) it is easier for a business analyst to build the form bundle and for the programmer to refer to the form bundle instead of having to maintain the list of forms via code.

Form Bundles are also useful to individual users who want to create their own bundles. However, enabling this requires a lot more user interface building (e.g. build a form bundle, edit the bundle, delete the bundle, add forms to the bundle, etc.) and most API customers do not build such UIs.

Complex Form Generation Features

As previously mentioned in Phase 1, there are a lot of ways in which forms can be generated to create the desired effects. Most customers will do the basic setup of forms generation in phase 1 and in phase 2 refine their approach to carry out more complex features. Some of these complexities include:

• CSS Styles - changing the style of the HTML form viewer to reflect their style needs

• Enabling Buttons - turning on additional buttons, like the Save or Email buttons

• Javascripts - adding custom javascripts to perform validations or advanced UI capabilities

• E-Sign UI Changes - building a custom e-sign screen to capture data before generating the form and suppressing the e-sign popup in the HTML form viewer

There are many more advanced ways in which forms can be used and shown to users. Customers constantly surprise us with what they accomplish. Ask us how to accomplish what you’re trying to do and we can make suggestions of how best to use Quik! to do it.

Configure Complex E-sign Features

While e-signing can be done right out of the box with Quik!, many customers need more configuration and control over the e-sign experience.

Implementation Models

There are a few different implementation models to consider - the Callback method is fast and easy to use, while the Self Service model gives you full control over calling the e-sign APIs. See the models here: Implementation Models

Common Configurations

Customers can do a lot of different things with their e-sign configuration. The most common scenarios are listed here: Docusign Configurations

Whether you want to not display the e-sign popup in the Quik! HTML form viewer, pass meta data through the e-sign process, lock down the e-sign authentication type or just modify the user experience, all of this can be done with the right configurations.

Configure Complex Workflows

One common question that is asked of Quik! is whether or not Quik! supports complex workflows. To be clear, Quik! does not perform any kind of workflow management. However, forms play an integral part in workflows and Quik! does provide various capabilities to support the various stages of a workflow.

Consider some of these parameters to help control what a user can and cannot do at a given stage in your workflow:

• Reuse Form UNIDs - In order to display the same form package multiple times within your workflow WITHOUT increasing the usage count (which is used for billing), call the execute/html command with the same UNID that was previously used. In real world terms, the first time a form is generated a UNID is created and when that form is submitted or saved, that UNID is present in the form data. Capture that UNID and use it with each subsequent form request for the same package or transaction. Do not reuse UNIDs for new transactions. Quik! Forms Engine Property List | :~:text=files are created. ,UNID, string
  
  

• PreviewMode - When TRUE, this property causes the form to be generated in preview mode overriding other settings. Preview mode hides all the buttons in the form viewer, makes the form read-only, and users cannot fill, print, sign or anything. Forms generated when TRUE will not count as a billable transaction in the Quik! system.
  
  

• SetFormReadOnly - When TRUE, this property locks all fields on the form, making them "read-only". Use this if you want to display a form to a user to review but not edit.Quik! Forms Engine Property List | :~:text=for more information. ,SetFormReadOnly, bool
  
  

• SignSubmitCombined - When TRUE, makes the Sign button event first invoke the Submit event and Submit URL before starting the signature process. Use this if you want a form to be electronically submitted to your system for validation or processing BEFORE the form is sent to e-sign. This feature will cause required fields to be completed before the data is submitted. Quik! Forms Engine Property List | :~:text=large text fields. ,SignSubmitCombined, bool
  

• ESignSuccessBehavior - Set the type of behavior you want to display in the form once the form has been submitted for e-signature. Quik! Forms Engine Property List | :~:text=ESignSuccessBehavior
  
  

• Four Methods to Set Properties - Use these methods to set field properties like required fields and read only fields, for each stage in your workflow when generating the form package again.

  • SetFieldPropertyByFieldName Method

  • SetFieldPropertyByRole Method

  • SetFieldTypeByFieldName Method

  • SetFieldTypeByRole Method

Phase 3 - Testing

Customers will generally perform testing with the Quik! APIs in their own non-production environments to ensure the quality of their implementation meets their expectations. Once ready to go-live, customers typically go through a beta test phase or pilot phase with a small set of real users.

Quik! supports testing in a variety of ways.

1. Production System Testing

2. Forms Testing

3. New Quik! Feature Testing in Non-Production

Production System Testing

Your Quik! account is created in our production environment and we expect your testing to take place in our production environment, even if you’re not in your own production environment. It’s important to test in the Quik! production environment because that is where your account settings have been established.

The only time we ask that you test in a non-production Quik! environment (UAT) is to test new features or changes to features in the Quik! APIs prior to rolling them out to production.

How to Test

When testing form generation, we recommend using the DraftMode = TRUE setting in the Execute/HTML method. This parameter will generate the forms with a watermark in the PDF or when e-signing. The advantage to using the parameter is that these transactions are not counted for billing and users are made aware that the transaction is for testing purposes.

When testing any other APIs, there are no special settings required for testing. Simply run the APIs as needed to test.

Forms Testing

Testing your field mapping to forms is a critical step to ensure your data is flowing onto documents the way you expect. There are a few ways to test forms.

• Field Mapping Tests - test to make sure values you send to the form appear where you expect them

• Form Update Tests - test to make sure changes to forms work as expected before publishing them

Field Mapping Tests

Testing your field mapping requires that you send known values from your data source to fill out on the form. Manually reviewing these fields takes time and care.

To aid in this process, we recommend either creating a data record in your system with values that equal the field name in your system OR just send your field name as the value to the form. By doing this, your field name will appear in the field on the form making it easier to identify if your expected value is appearing in the right place. This process works well for text fields only - checkboxes only work if the correct value (called the Export Value) is sent to the checkbox.

Another option is to set the TestDataMode property to TRUE. This will cause Quik! to set the Quik! Field Names as the value to display in the text fields on the form (instead of your own value). This will help you identify the fields on the form that are expected.

Form Update Tests

When form content is updated you have the option to test the form prior to publishing it to ensure the form works as expected. This can be done by setting the TestFinalFormsMode flag to TRUE when generating a form. When set to true the version of the form you’ll see is the one that is sitting in FINAL status within the Quik! build cycle waiting to be published. Once published, the FINAL version will be the same as the PUBLISH version.

CAUTION! DO NOT USE this parameter in your production system as you may get the wrong versions of other forms in our library.

New Quik! Feature Testing in Non-Production

If you receive an announcement that we have a new feature being rolled out, then you have the opportunity to test it in our UAT (user acceptance testing) environment prior to our rollout date. You may connect to our UAT environment by following instructions on the page below.

Testing Quik! Updates in a UAT Environment

Phase 4 - Go Live

Please communicate your expected go-live date to our team to ensure we’re prepared for any issues or immediate help you may need upon go-live.

From Quik!'s perspective, generally there’s nothing you or we need to do for your go-live event. Going live is really about making your implementation available to your end users and running transactions in the system. Our systems are designed to scale and meet demand.

If you feel there are ways we can help you go live, please ask and we’ll be happy to help.