Submission Conditions
A submission condition decides whether the form accepts a submission. Use one to reject entries that fail a check, such as a ticket number that does not exist or a secret key that does not match your PSA.
The check runs on the server after the visitor submits and before any of the form's Actions run. A visitor cannot bypass it by editing the page.
Turn On a Submission Condition
- Click Apps in the top bar, then click Forms.
- Open the form and select the Advanced tab.
- Select Restrict submission with a condition.
- Choose a Submission behavior.
- Build the condition in the expression builder below the dropdown.
- Save the form.
Submission Behavior
| Option | The form rejects the submission when |
|---|---|
| Block when condition matches | The condition is true. Use it to describe what you want to reject. |
| Allow only if condition matches | The condition is false. Use it to describe what you want to accept. |
Pick whichever direction is easier to read. "Allow only if condition matches" is usually clearer for validation checks, because the condition then describes a valid submission.
What the Condition Can Compare
The field list in the expression builder offers two kinds of terms:
- Form fields, by name.
- Pre-Submission Workflow properties, shown as
Workflow: {workflow name} / {property}.
Workflow properties let the condition compare the visitor's entry against data the workflow fetched. For example, compare a secret_key field against a custom field on the ticket the workflow looked up.
The expression builder combines rules with All conditions (AND) and Any condition (OR) groups, the same way conditional visibility does. See Expression Builder.
If a condition reads a workflow property, that workflow must produce a successful result before the form accepts the submission. Give the workflow a Form submit trigger, or watch the fields it depends on with Field change, so the result is ready when the visitor submits.
What the Visitor Sees
A blocked visitor stays on the form and sees:
This form cannot be submitted with the current values.
The message is fixed and does not change per form. Use field labels, field descriptions, and calculated fields to tell the visitor what a valid entry looks like before they get that far. A calculated field that shows the matched ticket title, for example, makes a mismatch obvious while the visitor is still filling in the form.
Nothing runs when a submission is blocked. The form's Actions do not execute, and no submission history entry is created.
Checks That Fail Closed
The form rejects the submission, rather than accepting it, whenever it cannot prove the condition passed:
- A workflow the condition reads has no successful result.
- A workflow the condition reads has a result from an older version of the form.
- You enabled a condition but left the behavior unset.
- The visitor's calculation session expired before they submitted.
Validation When You Save
The form editor blocks a save that would leave a condition in an unusable state:
| Message | What to do |
|---|---|
| "Configure a submission condition or disable submission restrictions." | Build the condition, or clear the Restrict submission with a condition checkbox. |
| "Update or remove unavailable Pre-Submission Workflow outputs from the submission condition." | The condition points at a property the workflow no longer produces. Pick a current property or remove the rule. |
| "Finish the open Pre-Submission Workflow before saving." | Select Save Workflow on the open workflow editor first. |
Related Topics
- Pre-Submission Workflows: fetch the data a condition compares against
- Calculated Fields: show the visitor what the workflow found
- Password Protection: restrict who can open the form at all
- Expression Builder: build the condition rules