Testing in UAT

Quik! gives you two non-production-impacting ways to validate forms and integrations before changes reach your end users: the UAT environment for upcoming Quik! platform features, and in-production test modes (TestFinalFormsMode / TestDataMode) for validating your own forms and data. This page explains when to use each and how to plan around the UAT data refresh schedule.

What it is

UAT (User Acceptance Testing) is a separate, non-production Quik! environment. When possible, the Quik! development team deploys upcoming product updates to UAT before a production release so you can test new or updated platform functionality before it ships to Production.

UAT is intended for testing upcoming Quik! features only. It is not the right tool for everyday form testing. Recently built or revised forms and Field Rules should be tested in Production using the test modes described below, not in UAT.

Do not use test modes in your Production environment for end-user traffic. Test modes are for validation only.

Using the UAT environment

All Quik! web services are available in UAT. Two things change versus Production: your username and the service URL. Your Customer ID and password stay the same.

Credentials

When calling UAT, modify the username only by prefixing your production username with uat. Apply this username format to all API calls made against UAT.

Production username:  johnsmith
UAT username:         uatjohnsmith

Calling Quik! APIs in UAT

Access UAT endpoints by either prefixing the host with uat or replacing www with uat. Apply the same pattern to all Quik! service URLs.

# Production
https://websvcs.quikforms.com/rest/QuikFormsEngine/qfe/execute/html

# UAT
https://uatwebsvcs.quikforms.com/rest/QuikFormsEngine/qfe/execute/html

If your security policy uses an allowlist, make sure the UAT hosts are reachable:

uat.quikforms.com
uatwebsvcs.quikforms.com

UAT also resolves to its own IP addresses, which may be in use when communicating with the UAT APIs:

34.193.105.241
34.224.135.79

Testing a form in final (production-equivalent) mode

Quik! moves every form through a structured build cycle: Original Build -> Test -> Revise -> Review -> Publish. The FINAL status sits at the end of this cycle, just before a form goes live. Testing in FINAL status lets you review a form exactly as it will appear in Production, confirm fields map correctly to your data, and validate updates, without impacting end users.

Test in FINAL status when you need to:

• Verify field mappings are correct before the form reaches Production
• Test data population into a newly updated form
• Run a quality-control checkpoint before end users see the form

Form testing in FINAL status is intended only for the owner of the form.

Plan ahead with the Forms Team. If you need to test forms before they're released to Production, notify the Forms Team at forms@quikforms.com when submitting your initial forms request. They will keep the form in FINAL status until your testing is complete so it isn't pushed straight to Production. For full control over when a form goes live, manage it directly in Quik! Forms Manager (QFM).

Standard build turnaround (new and updated forms) is within 10 business days. A rush build option is available with an estimated 2 to 4 business day turnaround; rush fees apply unless stated otherwise.

To be notified when a form reaches FINAL status and is ready for testing, sign up for a Quik! Forms Manager (QFM) account, which can email you when forms in your library are available for review in FINAL status. After signing up, contact forms@quikforms.com to activate your account.

TestFinalFormsMode

To pull a form from FINAL status instead of the published version, set:

"TestFinalFormsMode": true

For forms that have already been published, the FINAL version will be identical to the live version. Both the Execute HTML and Execute PDF endpoints support TestFinalFormsMode; you can set it to true regardless of which endpoint you use.

TestDataMode (HTML forms only)

To test a form with automatically generated test data, set:

"TestDataMode": true

When enabled, the Quik! Forms Engine inserts test data into each text field. The test data is the Quik! Field Name itself — for example, 1own.FName will appear in the Owner 1 First Name field. This is a quick way to identify which fields appear on a form.

Exceptions:

• Checkboxes are not populated automatically, but can be tested by manually selecting them.
• Formatted fields (such as SSN) do not prefill test data.

TestDataMode is available only when generating HTML forms (Execute HTML). It is not supported on the Execute PDF endpoint.

REST example (Execute HTML)

Testing a form in FINAL status with optional test data enabled:

{
  "HostFormOnQuik": true,
  "QuikFormID": "12",
  "TestFinalFormsMode": true,
  "TestDataMode": true,
  "FormFields": [
    { "FieldName": "1own.FName", "FieldValue": "John" },
    { "FieldName": "1own.LName", "FieldValue": "Smith" }
  ]
}

Testing with Execute PDF

When testing forms using the Execute PDF endpoint:

• TestFinalFormsMode is supported and pulls forms from FINAL status.
• TestDataMode is not available.
• Supply any test data explicitly using FormFields.

Testing how forms affect your application

If your application includes custom logic or rules tied to specific forms, set up a non-production environment (such as a demo or staging environment) with TestFinalFormsMode enabled. This lets you test both the form and your application's integration before the form is published — especially important when form designs change significantly.

Testing Field Rules

Field Rules should also be tested in Production, not UAT. Use the FieldAttributesManagerOff property to control whether rules are enforced or ignored at runtime.

UAT refresh policy

UAT is a shared environment supporting multiple stakeholders, and refreshing it is resource-intensive. Plan your testing around the refresh cadence below.

• Refreshes occur once per month unless otherwise communicated.
• Refreshes are scheduled and announced in advance of a pending software release for customer testing.
• No UAT refreshes are performed during production release blackout windows or critical development periods.

What a refresh does to your data

On refresh, UAT data is erased and replaced with scrubbed data from Production. Anything you create directly in UAT is overwritten.

Example: An account you create in Production will be copied to UAT. An account you create in UAT will be overwritten on the next refresh.

Requesting an off-schedule refresh

Customers and partners requesting a UAT refresh must:

• Submit the request at least 7 business days in advance, including the business purpose for the refresh (e.g., form validation, testing integrations).
• Quik! will confirm the scheduled date within 2 business days of receiving the request.
• Quik! will confirm the refresh date/time at least 24 hours in advance, and you'll receive a post-refresh notification once the environment is available.

Fees may apply to perform an off-schedule refresh and will be communicated in advance. Refreshes cannot be guaranteed during high-priority release windows, and UAT is not designed for frequent ad-hoc use.

Alternatives to UAT (API customers)

Because UAT refreshes are limited, prefer these production-safe features when they fit your need:

• DraftMode — test new form configurations without impacting Production.
• TestFinalFormsMode — test forms waiting in FINAL status (pre-PUBLISH), as described above.
• Parent + Child account — create a child account in Production with separate credentials, configured as a test account (e.g., DraftMode enabled, test-only e-sign accounts, or its own mTLS certificate). It can mirror the parent account's settings (form subscriptions, bundles, etc.) while staying a distinct account.

If you're unsure which feature to use, reach out and the Quik! team can help you find the right approach.

Related articles

• Authentication
• Launch a Form
• Quik! Forms Engine Property List
• Field Rules