Best Practices for Form Building, Testing, and Deployment

Available on all tiers:

• About
• Creating a Test Environment
• Creating and Testing Forms
• Creating and Testing Data Destinations
• Deploying Forms to Production

About

Best practice for Form Building, Testing, and Deployment for TrueContext is well supported by the tools provided on the TrueContext Portal. Below is the suggested methodology for creating new Forms in a production environment, with suggestions for the most thorough testing, which will ensure that new Forms successfully launch into your production environment.

The first step that a TrueContext Administrator should take is to create a test environment within their Production Team.

Creating a Test Environment

Create a Test FormSpace

While it is not completely necessary to create a separate FormSpace FormSpaces are where forms are stored and organized in the TrueContext Web Portal. A TrueContext Team may have multiple FormSpaces, depending on their needs. Admins can set FormSpace permissions to control which users have access to the forms in that FormSpace. for form development (as access to forms can be managed entirely through form states and permissions), most organizations find it easier to manage their "Test" forms if they are maintained separately, particularly if the team has many forms. Learn how to manage FormSpaces. 

When creating a development FormSpace, it is best to give it a descriptive name -- like "Test FormSpace"-- to avoid confusion. We recommend that you add at least one Problem Contact Email Address with the email of the main developer of the forms. If any-server side problems occur in this FormSpace, this email address will be notified.

Create a Test Group

Creating a "Test Group" with correctly configured permissions allows certain users to access and submit data against your development forms.

Permissions

The permissions you set may vary depending on your exact testing method.  For example, you may want "Test" users to only be able to submit data against "deployed" forms in your Test FormSpace, if "draft" versions are being actively worked on.

• Can Test: Allows users to access and submit data against Draft A draft form is a partially filled-out form saved on a device, or a preliminary version of a form that's been saved but not deployed in the Form Builder. forms in this FormSpace.
• Can Submit: Allows users to access and submit data against Active forms in this FormSpace.

You can also add "Can View" permissions (which allow users to view submitted data records for this FormSpace) and "Can Create" permissions (which allow them to build forms in this FormSpace). Note that these permissions are not consistent with those normally recommended in Production FormSpaces and will allow Groups assigned to the Test FormSpace all the permissions they might require to make and test forms. It is not recommended to add users other than those required for the Built and Test process to Groups with these permissions.

Creating and Testing Forms

Create a Test Form

Depending on the complexity of your form, this step may be quick or time-consuming. Prior to adding any Pages or Questions to your Form, it is best if you have sketched out a rough outline of the Form’s desired layout. When creating this layout consider the: Questions you’d like to ask, order that the Form should follow, segmentation of Questions on Pages, type of Question (or control) you’d like to use, and the type of data that each Question will collect. For complex logic, it might be useful to draw a flow chart to make sure you understand the steps required.

Many different types of input may be desired for the new Form and builder should be aware of the various types of controls that can be used.

Read more about Form Controls and Data Types.

Form Building Tips:

• When setting a Name your new Form, use a prefix which identifies it as a Test Form, for example “test_New Form”. This will make it easier for users who have both test and production forms on their devices, so they do not submit production data against test forms.
• You may find it easier to build your form in stages; for example, if one page employs some tricky logic or calculations, it may be best to test and ensure that everything is working before creating more questions that rely on this page.
• Forms can exist in one of two states: Draft and Active. The Draft State is useful for building forms, and forms can be left in this state while being built to reduce excess form versions. However, only Active forms have incremental versioning; if large errors are made in building, it is easy to revert to an older version of the form. You can also compare versions, and find in which version an error began, in order to pinpoint the cause.

Testing Your Form

• Run through the form as if you are a field user, not the form builder; ensure the workflow makes sense for actual use, and that instructions are clear. It may be wise, once the form is working smoothly, to have a strictly mobile user test the form for this.
• Be sure to test every step of the process, from filling out the form, to submitting data to the TrueContext server.  If the form will be dispatched, test this process.
• Create test data submissions with a variety of inputs. Submit typical, correct data, but also test with incorrect data; users will make mistakes, and it is important that these mistakes do not prevent the form from functioning correctly. Remember that you can set limits on some questions (maximum decimal places, minimum and maximum values) to guide your users; they will receive a detailed error if they enter values not within these limits.
• Submit forms with some questions unanswered, and some pages unanswered. You may find that some questions need to be marked as "Required" for optimal functioning.
• Test calculations with various inputs (including 0's). Do the math yourself and compare to make sure the calculations are correct.
• Test any new or updated Data Destinations A Data Destination specifies where to send data from a submitted form. You can use Data Destinations to automate data sharing and storage, routing data to a specific service (such as email or cloud storage) in several different formats. at this point as well. If filtering is configured, submit tests that meet the filter rules, and other test submissions that don't.
• If the form will use data sources Data sources, also known as "Lookups", are external sources of data that you upload or connect to TrueContext. You can reference this data in a form to populate answers or answer options. Data sources save typing, reduce errors, and make it easy to provide mobile users with only the relevant, most current data., be sure to use them in your tests; incorrect data source Data sources, also known as "Lookups", are external sources of data that you upload or connect to TrueContext. You can reference this data in a form to populate answers or answer options. Data sources save typing, reduce errors, and make it easy to provide mobile users with only the relevant, most current data. configuration can cause error messages or lead to incorrect data.

Creating and Testing Data Destinations

Create a Test Data Destination

It is important to have a test data destination set up in the test FormSpace that mirrors what is in the production FormSpace, but which is configured to uniquely identify records generated from test submissions. However, it is also important to keep the test data destination separate from production data, to ensure forms do not engage with it when not testing.

When creating a development Data Destination A Data Destination specifies where to send data from a submitted form. You can use Data Destinations to automate data sharing and storage, routing data to a specific service (such as email or cloud storage) in several different formats., it is best to give it a descriptive name -- like "Test Data Destination"-- to avoid confusion. When using a cloud storage destination like Dropbox, configure the test submissions to go into a path like: /TrueContext/TEST/form01 while production submissions go into a path like: /TrueContext/form01. Data destinations cannot be copied between FormSpaces, so it is important the test destination mirrors the production destination. 

Testing Your Data Destination

• Ensure that filtering functions correctly, and the destination only executes when you want it to. This is particularly important in the case of Custom Filter rules, which use regular expressions, and a single incorrect character may break the expression. Test filter rules by submitting forms in a test environment, testing all answers referenced in filter rules to determine if the rules behave as expected.
• Run through the form as if you are a field user.
• Create test data submissions with a variety of inputs. Submit typical, correct data, but also test with incorrect data. Create tests that meet the filter rules, and other test submissions that don't.
• Submit a form linked to the data destination, check that the execution has not failed, and check that every document/notification was successfully delivered to the configured locations/recipients.
• Check your test data destination to ensure all documents have been uploaded correctly.

Deploying Forms to Production

Once the Form has been completed, use the Copy Form function to make a copy of the Form into the appropriate production FormSpace. At this time, ensure that you remove the prefix that indicates that the Form is a Test Form. In this way, those users that are in the Test Group will be able to discern Test Forms from Production Forms. Also ensure that you use the Copy as Active Form option, so that the copy that is placed into the production FormSpace will be in the Active State. If this is a test version of an existing form, choose "Copy as New Version."

Copying Forms with Data Sources

Data Sources that are attached to the Test Form will by default also be copied into the production FormSpace. If a Data Source with the same name already exists in the production FormSpace, care needs to be taken to ensure that the correct data source remains linked with the correct form, and that no data is unintentionally overwritten.

Various options are given in the Advanced settings when creating and copying Data sources to ensure no data is lost. For example, to keep the testing data source, Overwriting Target Resources will copy any resources linked to the form into the target FormSpace, replacing any target FormSpace resources that have the same name. Another option is to Repoint Form to Target Resources. This ensures that existing sources will be used, rather than the test ones. It is also possible to Copy and Rename Original Resources, which will use the data source already linked to the form but will rename it.

If you are not sure about how to proceed in copying forms with data sources, please see the article on Moving and Copying Forms for further information, or contact TrueContext Support for advice.