Answer Exceptions


This feature is available on the following tiers: Enterprise, Advanced.


Exceptions are used to categorize problems identified during the course of a field technician's work as the user completes a form.

  • They provide colour-coded visual feedback to identify the severity of each problem, helping mobile users spot which items are the most important or problematic.
  • They make it easy to total up how many answers fall under each category, which can then be used to drive conditional logic in the form.

For example, during an inspection, an answer of "Unacceptable" indicates a Critical issue, while "Poor" indicates a Major issue. If Critical issues exceed 5, or Major issues exceed 10, the entire inspection could be marked as having Failed, and drive the user to collect additional information as a result.


[ top ]


Exceptions on a Mobile Device

In-Form View


Exceptions trigger when certain answers are chosen on questions. They provide more information by color-coding the question based on that answer. They may also show an optional custom message beneath the question to provide more detail.

Sometimes, exceptions will also require mobile users to fill out a comments field. Additional Comments are useful for explaining why an exception may have triggered. For more information: Additional Comments.

Page Listing

Exceptions are based on the answers chosen for the question. Not only does the exception highlight the question, but mobile users can open the page listing for the form and see which pages have exceptions. 

Pages with exceptions are marked with a triangular caution icon. It will be colored based on the highest-priority exception triggered on that page.

[ top ]


How to set up an Exception Category in the Form Builder

In the Form Builder's Settings Menu

Exception categories are defined at the form level. You can set them up in the Settings tab, under Exception Categories.


You can use the same Exception sets across multiple questions in the same form, saving time in configuration and improving consistency through the form.



  1. Navigate to the Exception Categories section under Settings.
  2. Define your Exception Categories in broad strokes, as in the example below: Critical Failure, Minor Issue, and Acceptable. Please note that Exception Categories are displayed in a priority order that reflects this list's order.
  3. Select the colors to use as highlights on the mobile device when the exception is triggered. This example uses Red:

Priority of Exceptions

Exceptions are ranked in priority from top to bottom in the form-level list. When setting up your Exceptions, please keep in mind the following:

  1. Questions with exceptions may have overlapping ranges -- i.e., two exceptions may trigger on one question. ProntoForms will show the highest priority exception on that question. We advise against overlapping ranges in general.
  2. On the page navigation, the highest priority exception will be shown if multiple exceptions have been triggered on the page.

[ top ]


Setting up Exceptions on Individual Questions 

Once you've set up your exception categories, you can use them on any of the following question types:

  • Numeric Text Fields
  • Steppers
  • Sliders
  • Calculations
  • Options-based questions, such as: Button Group, Dropdown, or Radiobutton Questions.


To add an exception to a question:

  1. Set up the question as normal
  2. Select the Properties tab and Enable Custom Exceptions.
  3. Select the correct exception from the dropdown.
  4. Set the conditions for the exception to trigger. Shown below is a Numeric Text Question's trigger conditions:

    • For numeric questions (Numeric text fields, steppers, sliders, and calculations), set the numeric range between which the exception will trigger.
      • You must provide at least one number
      • Each provided number must be inside the question's allowed min/max range, if set.
      • You may set multiple conditions using AND / OR rules.
      • Note: Ranges are not inclusive, i.e., they do not include the end-point number in the range. In mathematical terms, it is 1 < X < 10, rather than 1 ≤ X ≤ 10.
    • For Options-based questions (dropdown, button group, or radiobutton), you can select which option (i.e., which button/entry is selected in the question) will trigger the exception.
      • The option to use Exceptions will not appear for questions using data sources.
  5. Optionally, set up Exception Text (max 255 characters) to provide information to your mobile users on what to do next, or why the exception triggered.
  6. Add any other exceptions to the question.
  7. Continue to set up the question up as normal.

Mobile users can also be made to fill out a comment box when an exception triggers. For more information, please read: Additional Comments.

[ top ]


Use Case: Setting Up Exceptions on Ranges

Inspections often have ranges of acceptable numbers, and need exceptions to trigger when numbers are outside that range. Configuring exceptions to trigger when answers lie outside a range like 400 < Acceptable Range < 600 can be done with a single custom exception on a question.

Note: When setting up numerical ranges, please be aware that the ranges are exclusive. They do not include the end-point numbers, meaning it is < instead of ≤.


More complex ranges can be set up with multiple exceptions. Inspection forms often have ranges that look like this:



Sample configuration:

This would create a Minor Issue exception if the value was less than 400 or more than 600. This is done in the Show exception when answer is between... section, using an OR rule.


  • In order for '400' as a value to trigger the exception, you must use '399.99' or a similar decimal unit. Setting the second Minimum to 600.01 allows '600' as a value to trigger the exception.
  • Leaving the first Minimum blank means that it is open-ended: the value can be anything below 400.
  • Leaving the second Maximum blank means that it is also open-ended: the exception will trigger on any number from 601 to infinity.

 To create a range that includes a Critical Exception with a range that would work like this:


  1. Add appropriate Minimums and Maximums to the Minor Issue exception
    • In this case, our exception triggers would become 199.99-400.01, or 600.01-800.01.
    • Note: Exceptions function on < logic, not ≤, thereby requiring us to use decimal places to make 200 and 400 acceptable values for the exception's logic.
  2. Add a second Exception for the Critical Issue Exception where it will trigger if the value is under 200, or over 800:

Common Errors

Exclusive, not Inclusive: As the Exception logic is exclusive, it's easy to forget to set a range that will include the endpoint numbers. The examples above give a way to ensure that the endpoints are included.



Using Exception Recaps in Forms

Exception Recaps are a count of how many exceptions of a certain type have come before it. This is useful as a way to score an inspection form, or base conditional logic off of the number of exceptions of a certain type. For example, if an inspection has two "severe" issues, or five "moderate" issues, you might build conditional logic rules around that, or create a score based upon the output of the recap question.

For more information on Exception Recap questions, please read: Exception Recap

[ top ]

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request