Use column constraints

Column constraints should be considered UI features rather than security features and should not be relied on to securely allow or prevent data access. They affect the behavior and presentation of the app for legitimate users, but they do not prevent malicious users from tampering with data sent from the app to the server in ways that could bypass column constraints. For information about securing your data, see Security: The Essentials.

Every column definition has a type that specifies what values are allowed in the column, as well as flags that specify if the column is hidden, if it's required for input, and so on. This is adequate for many apps, but sometimes a more dynamic or data-driven mechanism is needed. This is what column constraints provide. 

A column constraint is an expression that is dynamically computed to determine the behavior of a specific column when the user tries to enter or change its value.

Three column constraints govern the validity of input values for that column:

Two further constraints are related to the presentation of the column:

An additional constraint can help influence how records are updated:

  • Reset on edit?: Clear the value whenever that record is edited by a user

To add a column constraint, click the Data > Columns tab and click the Edit icon at the left of the corresponding column definition.

New to expressions and formulas? See also Expressions: The Essentials.

Get started

Watch this video to learn more about using column constraints in your app.

Quick Tip Friday - Conditional Attributes

Best practices

Column constraints give you the power to define very subtle or complex conditions, but users will only see the resulting behavior. As an app creator, it's important to provide adequate explanations for the columns affected by these expressions--particularly for Valid_If conditions--so users will know how to proceed if they provide an invalid column value. The best way to do so is by providing meaningful column descriptions.

When these expressions reference other fields in the row (not just [_THIS]), it's best to ensure they're always "backward" references to fields the user has already seen (meaning columns that come before the column being considered in the spreadsheet and appear above the column being considered in the Columns tab). Conditions containing "forward" references may be confusing to users and may cause problems with multi-page forms.

Was this helpful?

How can we improve it?

Need more help?

Try these next steps:

Search
Clear search
Close search
Google apps
Main menu
87327728219947845
true
Search Help Center
true
true
true
false
false