Overview

There are two ways you can test your forms/workflows. Both methods display the test mode popup which includes the Test Mode Views discussed below.

Method 1: Click the save and test icon from within the designer to save the changes to your form and automatically display the test popup window. Complete the form in the popup window to test it. When your testing is completed and the test mode screen is closed you will be returned to the form/workflow designer. This makes it easy to make additional changes.

Method 2: Click the save and close icon on the Form/Workflow Designer toolbar to save your changes and exit the designer. Then click the Test icon for the form/workflow on the Forms and Workflows Home Page to enter Test Mode. Complete the form in the popup window to test it.

The Save and Test feature is not available for frevvo customers integrating with Confluence. The icon can be hidden with a configuration parameter.

Method 1 - Save And Test

The save and test feature reduces form/workflow development time by allowing designers to test forms/workflows, business rules and mapped PDFs without leaving the designer. Modifications needed after testing can be quickly addressed since you will still be in the form/workflow designer once you close the popup window. This is particularly helpful when building, troubleshooting, and testing forms, business rules and mapped PDFs.

When the save and test is clicked, the form/workflow is saved in the background, and the Test popup window displays reflecting the newly saved version of your form/workflow. The form/workflow will behave exactly as it will when users access it. To test the form/workflow, just complete it as your users would and click Submit. Refer to Test Mode Views for information about the features that are available when the test popup displays.

When you close the Test popup, you will be on whatever designer page you were on when the save and test icon was clicked. This allows the designer to go right back to making changes after closing the Test popup.

An informational processing message as shown in the image is displayed after the icon is clicked until the test window opens.
If form/field validation errors are detected, closing the test popup returns you to the designer where you can quickly make corrections and retest.
Save and Test checks for Rule and PDF mapping errors before the test popup displays. This gives the designer the option to correct first before saving and testing.
- If rule validation errors are detected, the designer is notified and given the option to correct before the Test popup is displayed.
- If PDF mapping errors are detected, a warning message with information about the error displays.
The form/workflow version (visible in the upper right area of the designer) increases by 1 every time you click on the save and test icon.

If you use the Save and Test feature to save the latest versions when developing your form, simply click the Cancel icon when you are ready to leave the designer.

Browser Popup Blocker Message

If your browser is configured to block popups, you may see a pop-up blocker message the first time you click the save and test icon. If so, clock ok to open the test window then check your browser settings to allow pop-ups.

Method 2 - Save then Test

Of course, you can always click the save and close icon to save the changes to your form but you will be returned to the Forms and Workflows home page after the changes are stored. The test popup is accessed by clicking the Test icon. To continue making modifications to your form you must click the form name or select Edit from the Action Menu to return to the form designer for subsequent modifications.

Refer to Test Mode Views for information about the features that are available when the test popup displays.

Test Mode Views

There are three icons in Test mode that you can use to see what your form will look like and how it will work on an iPhone or an iPad. Theses icons appear at the top of the screen - desktop, tablet and smart phone. The default view is desktop.

Clicking on the the tablet and smart phone icons gives you an approximate view of the form on the tablet or phone. You can enter data in the Phone and Tablet views just like you can in the Desktop view to test your form. This is very helpful when designing forms for mobile devices.

Tablet and Phone views are not precise and there may be slight differences when rendered on the actual device. It is highly recommended that you test the form/workflow on the actual device to be certain.

Testing Form/Workflow Customizations

Before you share your new form or workflow with users you'll want to test it to make sure it looks and works the way you want. You will want to test that the form is properly validating data entered into each control, that all your rules are correctly causing the behaviors such as show/hide and calculations that you want.

Control Validation

Each time you supply a value in a control, sends an asynchronous request to the server to validate the data. This means users will get immediate feedback while they are using your form. They do not have to wait until they click the submit button to discover, for example, that a zip code is missing a digit or that they neglected to fill in a required phone number field. Try to type letters in a number control and you’ll immediately see an error message. You'll want to test your form to make sure that you are using the correct control based on the validation you want. For example if you used a Text control for a phone number field, you won't see the correct error occur if you enter an incorrect phone number. Go back and edit your form to change the control type for that field from Text to Phone.

Your form cannot be submitted until valid data is entered into all required fields. If data is entered into an optional field that data also must be valid. Test your form to verify that all the fields that you want to require the user to fill are indeed set to required in the form. If the user does not enter data into all your form's required fields or enters invalid data into an optional field, the invalid fields will be highlighted with an orange background color when the Submit button is clicked. For example, enter abcde into a Money control. An error will appear to alert the user that the entered data is invalid. Even if all required form fields are filled the form cannot be submitted until the error is corrected. For example, replace abcde with 89.25,click Submit and the form will be submitted.

The designer can also display a message instructing the user what to do. This method is very helpful to users when trying to determine why a form does not submit. Refer to this topic for the details.

Business Rules

Test your form to verify that all your business rules are working as expected. For instance, if you have a radio field "Billing address same as Shipping?" and select "no", you would expect the hidden Shipping Address section to become visible and required. Test each form field that has dynamic business rules to verify that they are working as you want. Remember to test the negative cases; for example, if you then click "yes" to the billing address question, make sure the Shipping Address section control becomes hidden and optional again. It is very important that hidden controls are not required as discussed below.

Form and Document Actions

Test your form to verify that the final form and doc actions are working as expected. Make sure your final submissions are reaching their desired endpoint. For example, if your form Doc Action is configured to send an email or post to another system or to save to Google Drive or Sheets, you'll want to verify that this is working. Submissions errors have many possible causes. Maybe your form is configured to send an email and you used a control template in the email wizard To field. If the email address control was filled with a bad email, that will cause a submission error. Errors can also occur if you are posting to a web service and the web service fails.

One way to debug submission errors is to set your Error Actions to {_frevvo_root_cause_msg}. A second way to debug submission errors is to use the submission repository. The submission repository has an error indicator on any submission that had an issue. See Submission Errors.

Step Assignments for Testing (Workflows)

Usually, as the designer, you want to test the workflow's behavior, including Task Notification emails and business rules that execute on each step. However, you may be hesitant to test your workflow with real User and Role assignments, which will notify these users with each test. One idea is to set up dynamic user and role assignments that will assign each step to test user(s)/role(s) when the workflow is started under a testing condition, such as initiated by the designer user and otherwise will use the as-designed step assignments. This pattern will allow you to test workflows fully in development or production without notifying and cluttering the task list of real users.

First, add a test role and one or more test users, whose emails are set to your own email(s) so you will be able to view Task Notification and Doc Action emails.

Let's say you have a workflow with three steps. Step 1 is performed by any user, Step 2 is assigned to the user's manager, and Step 3 is assigned to the role "HR". Instead of hard coding these assignments, use controls in your form to set the Manager user and HR role values. Set the step assignments to the template for those controls, i.e. Step 2: {Manager} and Step 3: {Role}

Then add a business rule that checks the initial user's id - if it happens to be "designer", then set the control Manager to your test manager user (mgrTest) and set the control Role to your test role (HRtest). The else action sets these controls to the initial user's manager and the real role "HR".

Test the workflow from your designer user account. You will receive the Task Notifications via your test user's email, and you can log in as the test user(s) to perform the tasks.

When you're ready, start the workflow from some real account. Now it should route through the real-world assignments as expected.

Internationalization

Forms can be translated to multiple languages using the internationalization feature which enables you to easily localize your forms for target audiences that vary in culture, region and language. supports localization from the browser's locale setting.

You can test the translation files you create and uploaded into by clicking the test icon on the Internationalization screen or you can use the &locale URL parameter to initialize the form with other languages. See Multi Language Support for details on creating translations and testing locale translations.

When you are done testing and are ready to roll out your form, see the Share Forms and Workflows documentation for steps to make your form/workflow public and share it.

Troubleshooting Hidden Required Fields

Sometimes you'll test your form and see that the form will not submit even when all required fields appear to be filled with valid data. The cause is always a hidden required field with no data or a hidden field with invalid data. Since the field is hidden your users won't be able to enter a value into that required field nor to correct an invalid value in that field and will therefore never be able to submit your form. In a simple form it won't be hard for you to open it in the form designer, find the hidden required field and fix the problem. In a large form or one that has dynamic business logic that makes fields hidden/visible or required/optional or sets values in business rules, you'll need to debug this problem while testing the form.

Step 1

The first step to solving this issue is to understand which control(s) are causing this issue. There are two ways to find the invalid controls, both of which involve using your browser's developer tool. This tool is a great way to find hidden controls which are invalid or required and empty. You can access it by right-clicking on a page and selecting Inspect, or by using the keyboard shortcuts indicated for your OS/Browser. The following links point to documentation on developer tools for several supported browsers.

Chrome
Firefox
Edge
Safari (Web Inspector)

Method 1

Test your form and enable the developer tool.
Open the developer tool's HTML tab and search for all instances of s-invalid in the elements tab. One way to search is to click in the Elements tab and use the Ctrl-F search shortcut. This will take you to the HTML of each control in the invalid state. The control's name can be found in that HTML, indicated by cname. Each browser may be slightly different, but here is an example in the Chrome browser:
Now you can edit your form in the designer, find that control, and fix the issue.

If a required control is inside a hidden section, then that section will also be invalid and you will also see s-invalid in the section control's HTML. This s-invalid is not the root cause of your bug. You will have to continue searching with developer tools further to get to the actual control inside the section control that is the root cause.

Method 2

Test your form and enable the developer tool.
Click on the Console tab.
Execute this JavaScript function _frevvo.api.forms.controls.getControlErrors(); Calling this function returns a collection of objects that describe any invalid controls including the control id, control label, and the error description. In the image, you can see the reported errors for an Email, Money, and Date field that contain invalid data. The controls are inside of a hidden section and are not visible to the user who is trying to Submit/Continue the form/workflow.

This JavaScript function will only work in test mode. To execute on a step mid-workflow or even after submission, copy and paste the task or submission URL into a new browser tab, and append the URL parameter ?_test=true to the end of the URL. Now follow the steps above to see the list of controls that are invalid.

Step 2

Once you know which control(s) are causing the problem, you can resolve it.

Check your business rules to make sure they are setting those controls' required property correctly. Use the View All feature to quickly search for business rules affecting the control(s) you identified above.
Test the form and use the Debug Console to determine what value is being set that might cause a control to become invalid. Pay particular attention to leading or trailing spaces. Certain controls that require a pattern (email, phone, etc.) must be set to null (not an empty string such as '') in order to be valid when their value is cleared via a business rule. The Visual Rule Builder will handle this correctly.
Check the control's default settings. For example, a required section that contains a default value in one control will set all other required controls inside the section to "required" at run-time. Uncheck the section's required property by default, or set your default values at run-time using a business rule.

Re-test the form to determine if your changes resolved the issue.

Purging form/workflow test data

Refer to this article for a quick easy way to purge your test data (tasks and submissions).

Browser not supported