Forms
Part of No-code forms and interfaces
Adding validation before saving a record
Define form rules, show useful errors and check which save paths enforce validation in a no-code app.
Define the values that make a record unusable or misleading, then place checks before the save and show people how to correct failures. Keep form feedback distinct from server-side validation: a screen check alone may not cover every way a record can be written.
The practical sequence is to name each rule, configure it at the field or form level, decide what the save action does when it fails, and confirm the outcome to the user.
Turn record needs into clear rules
For a hypothetical stock discrepancy, the reporter identifies an item and location, enters a counted quantity and describes what they observed. State what makes each value usable before configuring the app:
| Input | Rule at this step | Helpful feedback |
|---|---|---|
| Item and location | Each must identify an available choice | Name the missing choice. |
| Counted quantity | Must be a number within the organisation's agreed range | State the permitted range once it has been set. |
| Description | Must be present if needed for review | Ask what differed; a person may still need to judge whether the detail is useful. |
| Review decision | Supplied later by a reviewer | Do not require it from the reporter. |
Use named rule types where the builder offers them: required, number or range, date or time, and pattern or format. In web forms, HTML input types include email, URL, number, range, date and time; the pattern attribute uses regular expressions for formats such as postcodes or serial numbers.
Set numeric boundaries from the organisation’s agreed rule rather than guessing a universal range. Treat a known zero differently from a blank; if a record can be incomplete, identify its status and who must resolve the missing value.
For a condition that applies only in specified circumstances, use a conditional rule if the builder provides one. Zoho Payroll calls its feature Validation Rules; it supports multiple criteria and subrules for criteria-based rules.
Check each write route
For an individual value, look for a field-level setting such as required, a value constraint or a format rule. For conditions involving the form as a whole, check how the builder combines field validity before allowing the save.
In AppSheet, the named feature for checking form input validity is Valid_If; column properties are also a named configuration area. Look for Valid_If when setting up an input check, then confirm how your app applies it when saving.
In Zoho Payroll, open Settings, choose the module, go to Validation Rules and select + Create New. Add the condition and an Alert Message, then save; if a value violates the rule, the alert appears and the record is not created. The feature is available for Employees, Pay Runs, Loans and Custom Modules.
In a Power Apps canvas form, put SubmitForm in the save button’s OnSelect formula. Before submitting, it checks required fields, field constraints and the form’s Valid property, which aggregates the Valid properties of its cards; a validation problem stops that submission.
OnSuccess runs after a successful submission to the data source, while OnFailure runs if submission is unsuccessful. The form’s Error and ErrorKind properties report the outcome; SubmitForm behaviour does not describe every way a Power Apps app can write data.
List the routes that can create or change the record, such as a form, edit screen, action, import or integration. Check where each rule applies; where it must cover every route, add server-side validation at the receiving system as well.
Client-side validation can be bypassed, so it does not replace server-side validation. Check the actual behaviour of the receiving system rather than assuming a screen rule blocks every write.
Client-Side vs Server-Side Validation in Australian No-Code Platforms
- PlatformPower Apps
- Client-Side CheckUses `Valid_If` and form-level `Valid` property to block save if rules fail.
- Server-Side CheckRequired for full compliance; must be implemented in the data source (e.g., SharePoint, Dataverse).
- PlatformAppSheet
- Client-Side CheckUses `Valid_If` column property to validate inputs before submission.
- Server-Side CheckMust be enforced at the backend (e.g., Google Sheets or Cloud SQL) to prevent bypassing.
Show a useful outcome
Make each error concise and clear: name the affected field, explain what is wrong and say how to correct it, including any format requirement. Put a summary before the form and link each error to its field; show specific feedback near the affected control as well.
For a required web-form field, the browser can block submission when the value is missing and display a message it generates. Mark the field as “(required)” too, so the requirement is clear beyond the browser’s validation message.
Tell users whether submission succeeded or errors occurred. In Power Apps, use OnSuccess for confirmation after a successful data-source submission and OnFailure for a failed one; keep entered values where the configured app permits it.
Some apps queue changes before syncing them. Distinguish a pending change from one confirmed at the relevant data source, and offer a way to check the result if the outcome is uncertain before another submission.
Before release, check validation with fictional cases: a blank required field, a known zero, a value outside the agreed range, a hidden conditional input and a write through another permitted route. Set the expected result first, then compare the displayed feedback with the resulting record.
