Overview
Form templates now support a dedicated, rule-based way to mark a submission as Failed — instead of failure being a side effect of an inspector typing any text into a Reason for Failure field. Any question in a template can have a "Fail form when…" rule, built with the same AND/OR condition builder already used for question visibility rules.
IMPORTANT — read before updating existing templates: Previously, typing any text into a Reason for Failure field automatically marked the submission Failed. That is no longer the case. A typed reason by itself does not fail the form anymore. If you have templates relying on "if the inspector typed a reason, the form should show as Failed," you must add an explicit Fail Form rule to that question, or those submissions will no longer be marked Failed. There is no in-app warning about this — review your templates before this change reaches your account.
Accessing the Fail Form Rule
Open a form template in the Form Builder.
Select the question you want to configure.
In the question's business-rules icon strip, click the flag icon (separate from the eye icon used for visibility rules) to open the Fail form when… panel.
How to Set Up a Fail Form Rule
Click the flag icon on the question you want to drive form failure.
Build your condition using When / Always / Never, the same way you would for a visibility rule.
Choose the target question — this can be the same question or any other question in the template (except Information, Photo, and Signature components, which can't be targeted).
Add additional AND/OR condition groups if needed.
Click Done to save the rule, or Clear to remove it.
NOTE: Fail Form rules don't include the "For" (employee/role) condition type that visibility rules have — they're evaluated purely on question answers, not on who's filling out the form.
How It Behaves at Submission
The rule is evaluated server-side when the form is submitted — the same rule applies whether the form was filled out on web or mobile.
When the rule resolves true, the question is marked Failed and the overall submission is marked Failed, regardless of whether a reason for failure was typed.
When the rule resolves false, the submission is not marked Failed, even if a reason for failure was typed. Reason for Failure and Failed status are now fully independent.
Marking a submission Failed this way is reporting-only — it does not create a task, work order, or notification on its own. Any work order or notification behavior still comes from that question's existing work-order/event-trigger configuration.
The PDF output is unaffected: it still only shows a Reason for Failure if one was typed. A submission failed purely by rule, with no typed reason, shows no reason text in the PDF.
Use Cases / Examples
Use Case 1: Failing based on a numeric reading
A template has a numeric "Pressure Reading" question. An admin adds a Fail Form rule: fail when Pressure Reading is less than 20. Any submission with a reading under 20 is automatically marked Failed — no typed reason required.
Use Case 2: Failing based on another question's answer
A "Safety Checklist" question asks "Any hazards observed?" An admin sets a Fail Form rule on the final summary question that fails the form when the hazards question equals "Yes," even though the two questions are unrelated in the form's layout.
Use Case 3: Preserving old behavior after the update
A template previously relied on inspectors typing a reason to mark forms Failed. After this update, the admin adds a Fail Form rule to the relevant question (e.g., fail when a "Pass/Fail" question equals "Fail") so the template continues to behave as before.
Best Practices
Audit templates that relied on typed reasons before this ships: Since reasons no longer drive Failed status, review any template where that behavior mattered and add explicit Fail Form rules.
Use numeric operators for measurement-based questions: Numeric questions support =, >, <, ≥, ≤, and Between — use these instead of trying to replicate numeric logic with text matching.
Combine conditions with AND/OR groups for complex failure logic: Just like visibility rules, you can nest condition groups to require multiple criteria before a submission fails.
Troubleshooting
Issue: A submission with a typed reason for failure isn't showing as Failed anymore
Solution:
This is expected — Reason for Failure text no longer drives Failed status on its own
Add a Fail Form rule to the relevant question(s) to restore the intended behavior
Issue: I don't see an option to target a specific employee or role in the Fail Form rule
Solution:
Fail Form rules only support question-answer-based conditions (When/Always/Never), not employee/role targeting
Employee/role targeting ("For") is only available on visibility rules
Issue: I can't find numeric operators when setting up a visibility rule
Solution:
Numeric operators (>, <, Between, etc.) are only available on Fail Form rules, not visibility rules
Visibility rules for numeric questions still use the existing any/specific/none matching
Summary
Form templates now support a "Fail form when…" rule on any question, using the same AND/OR condition builder as visibility rules, plus numeric operators (=, >, <, ≥, ≤, Between) that are exclusive to fail rules. The rule is evaluated server-side at submission for both web and mobile, and is fully decoupled from the Reason for Failure field — typing a reason no longer fails a form on its own. Marking a submission Failed this way is reporting-only and never creates tasks, work orders, or notifications by itself. Review existing templates that relied on typed reasons and add explicit rules where needed.