Show the right questions with setup rules

Version and workspace

Configure company setup on the web, then synchronize the same company account in the Apple app. The native fixes described in this guide are prepared for the next app release; older installed versions may not include them yet.

Example: ask roofing details only on roofing jobs

Create a single-choice question named “Project type”, with stable key project_type. Add Roofing with saved value roofing, and Bathroom with saved value bathroom.

Create your “Roof pitch” question with key roof_pitch.

Add a rule at priority 10 with no conditions and action Hide roof_pitch. No conditions means always active.

Add a rule at priority 20: project_type equals roofing, then Show roof_pitch.

Start a fictional estimate. Bathroom should hide roof pitch; Roofing should show it. Test switching back and forth, saving and reopening.

Questions are visible by default. A conditional “Show” action alone does not hide the question when its condition fails. The unconditional Hide baseline is what makes this example work.

Conditions and order

Lower priority numbers run first. For conflicting show/hide actions, the last matching action wins. Use distinct priorities when order matters.

On the web, every condition in a rule must match (ALL / AND).

The native app also supports multiple groups and ANY / OR. Any passing group activates the rule. These advanced rules are preserved on the web and marked for editing in the native app; saving another web rule does not flatten them.

Equals and does-not-equal compare saved values exactly, including case. Use the option’s saved value, which may differ from its visible label.

Contains checks text containment. Do not use ambiguous substrings for multi-choice answers: paint can also match exterior_paint. Prefer distinct values and test the exact choices.

Greater-than and less-than compare valid numbers. Equality at the boundary does not match either.

A missing answer does not satisfy a condition, even “does not equal”. An explicit empty text answer is different from a missing answer. There is no dedicated “is empty” operator.

Yes/no answers use true and false, rather than the displayed words Yes and No.

Empty ALL groups pass; empty ANY groups fail. Remove an unused group or add its actual conditions.

Set-answer actions (native app)

Set-answer actions fill a question with a typed value. Text and choices use their saved value, numbers use a plain number, multi-select uses comma-separated saved values, and yes/no accepts true, yes or 1 for true. The native editor rejects circular dependencies, including a rule which assigns its own condition answer. Existing cyclic set-answer actions are ignored at runtime so they cannot cause the form to oscillate. Do not rely on one forced answer to repeatedly activate another rule; use the original project answer as the condition. A rule is not a workflow scheduler.

Hiding a question is not the same as deleting its answer. Existing answers may be retained when a question disappears. Therefore do not assume hiding a question cancels a pricing rule referencing it: test the pricing conditions separately and include the relevant project type condition there too.

Before using rules with customers

Check a matching answer, a nonmatching answer, an unanswered question, number boundaries and conflicting priorities. Verify visible required questions can be completed and hidden questions do not block continuation. Save/reopen the test estimate and sync the app before checking the same configuration on another device. Only owners and administrators manage company rules.

Web saves reject missing actions, unknown question references and invalid numeric comparisons. If saved rules cannot load, the editor stops instead of replacing them with an empty list. Deleted rules are excluded from the editor. Advanced native logic is preserved unchanged, with a warning if it changed remotely while the page was open.

Deleting a native rule queues its exact identity for deletion on the next successful sync, including when it was the last rule. Pending removals survive reopening and account switches; an unsuccessful upload keeps them queued. Other rules omitted from a partial sync are preserved. Re-adding the same rule before upload cancels its pending deletion.