Test Environment

What are Test Environments

The Test Environment feature enables Program Designers to copy existing program design to evaluate and implement changes without affecting the live program data. This allows users to modify the program design, test the changes with test applications, then commit the changes to be seamlessly incorporated into the live production program.
 

Locating the Test Environment feature

Anyone in a Role with the Create Test Environment privilege can access this feature by opening the ADMIN menu and clicking on Test Environment:

How to Open a Test Environment

As illustrated in Figure 2, the dialog features an option to transfer Roles from the existing program to the new Test Environment, thereby granting them access. Additionally, there is an optional section to specify the purpose of the Test Environment, which will be visible to all authorized users.
 
PowerClerk Communications in a Test Environment can be optionally routed to a specified email address instead of the recipients defined in the communication templates. This is useful for testing purposes. At least one email address must be entered if this option is selected, and multiple addresses can be included if separated by a semicolon.
 
Please note this will not reroute emails sent via DocuSign if requesting signatures in the Test Environment.
 
To open, click the Create Test Environment button:
 

Figure 2: Create Test Environment

Once a new Test Environment is created, a yellow-grey banner will appear at the top of the interface to indicate that the current workspace is within a Test Environment.
 
The Program Changes Overview, located under Admin > Test Environment within the Test Environment, highlights all differences between the Test Environment and the main program. It also flags any duplicate items that could prevent the Test Environment from being successfully committed.
 
To resolve duplicate blockers, the recommended approach depends on whether or not there is project data in the production Data Field:

• If there is NOT data in the production data field, the recommended approach is to rename the Data Field in production to have the prefix “Obsolete” so that the added Data Field in the Test Environment will be retained when committed. Following the commit, all references to the “Obsolete” Data Field will be automatically replaced with the Test Environment data field.
• If there IS data in the production data field, the recommended approach is to rename the Data Field in the Test Environment to have the prefix “Obsolete” so that the added Data Field in production will be retained. Following the commit, replace all references to the “Obsolete” Data Field with the desired Data Field that was created in Production when the Test Environment was open.

After completing all necessary changes and thoroughly testing functionality, a commit request can be submitted through PowerClerk’s Ticket System by selecting the option: “I would like my Test Environment to be committed.” If preferred, the Test Environment can be discarded without submitting a ticket, allowing a fresh Test Environment to be created.
 
Please Note: It is strongly recommended not to make configuration changes in the live program while a Test Environment is active, as committing the Test Environment will overwrite the current configuration. However, normal project activity may continue, and customers can still submit applications during this time.
 

Figure 3: Test Environment dialog

 
Please note: Once a commit request is fulfilled, all edits made within the Test Environment will be applied to the main program. This action is not reversible.
 
Only one Test Environment can be active at a time. To create a new Test Environment, the current one must first be either discarded or committed.
 

Test Environment Behavior

Test Environments in PowerClerk have the potential to overwrite production data. It is strongly recommended to avoid making edits in the live production environment while a Test Environment is active. It is recommended to frequently close and commit Test Environments to ensure the program configuration remains current and accurate.
 
Below are key behaviors and limitations to be aware of when working with a Test Environment:

• Project Limit: A Test Environment can hold up to 2,000 projects in total.
• Program Design Changes in Production
  • Any configuration changes made directly in the production environment will take effect immediately and continue to operate in production until the Test Environment is committed.
  • Once the Test Environment is committed, any program design changes made to existing program design will overwrite the production configuration, including any updates made in production during the time the Test Environment was active. After committing, the Test Environment is automatically deleted.
• Form Handling
  • Only Published Forms are copied into a Test Environment. Draft Forms are not included.
  • When a Test Environment is committed:
    • If a form has been updated and published within the Test Environment, it will replace the Published Form in the production program, and any existing Draft Form in production will be deleted.
    • If a form has not been updated and published in the Test Environment, the existing Published and Draft Forms in production remain unchanged.
• Communication Routing
  • To prevent unintended emails during testing, communications can be restricted by enabling the “Addresses to Send To” setting under Admin > Test Environment.
  • Only the email addresses listed in this section will receive PowerClerk communications related to all test projects.
  • Communications that are sent from a Test Environment will have [PowerClerk TEST] appended to the email subject.
• DocuSign eSignature Requests
  • Pressing the Request Signatures button or having an automation configured to request signatures will prompt DocuSign to send an email to the specified recipient, regardless of whether the address is listed under Admin > Test Environment.

PowerClerk Sandbox Instance

PowerClerk has two main instances. A Sandbox Instance will be denoted with PCITrial in the URL and the Production Instance will contain powerclerk.com in the URL. Please note that Sandbox instances cannot be merged with existing programs in Production.
 

Figure 4: PowerClerk Instances

 
A Sandbox Instance is typically used for building new programs or testing potential features. It allows for experimentation and configuration without impacting live data or incurring immediate costs. Once testing is complete and the program is fully configured, it can be migrated to the Production Instance to establish a new program.
 
Important: Do not store Personally Identifiable Information (PII) or customer data in a Sandbox.
 
CPRAdmins can migrate a Sandbox to PowerClerk.com to establish a new program. Once the migration is complete and the new program is live, the Sandbox is retired. All future updates and changes will then be made directly in PowerClerk.com.
 
The Production instance is intended for live programs that are actively in use and contain customer data, including PII. It represents the operational version of a program.
 
Both Sandbox and Production programs can have their own Test Environment.

FAQs

Have additional questions? Contact us to nominate your FAQ and help others find answers to your own questions concerning this feature.

Create A Support Ticket

Not finding your answer here?  Submit a question to our support team at the PowerClerk Ticket System and leverage the PowerClerk team’s expertise.