Validations

Validations are the rules Grunddata applies whenever a record is saved. They are the difference between a spreadsheet and governed business data.

Validations are expressed using JSON Schema, but you do not have to write JSON — the web app builds the schema from a form.

Rules apply everywhere, always

A validation added here is enforced in the web app, the Excel plugin, the Google Sheets add-on and the API. There is no way to bypass it, and a failing row is rejected with a message rather than silently altered.

Two levels of validation

Level	Attached to	Use when
Attribute	A single attribute	The rule concerns one value on its own
Table	The whole table	The rule compares two attributes with each other

Attribute level rules

Open an attribute and add a validation. The available rules depend on the datatype.

String attributes

Rule	Meaning	Example
Starts with	Value must begin with a prefix	Account numbers must start with 4
Ends with	Value must end with a suffix	Codes must end with -SE
Min length	Minimum number of characters	At least 3 characters
Regex pattern	Value must match a regular expression	^[A-Z]{3}$ for a three-letter code
One of (list)	Value must be one of an explicit list	NOM, MTM, INT

Numeric attributes (integer, decimal)

Rule	Meaning	Example
Number comparison	Greater than / less than a fixed value	Limit must be > 0
Multiple of	Value must be a multiple of a number	Amounts in whole thousands
One of (list)	Value must be one of an explicit list	1, 5, 10

Max length is a property, not a validation

Simple constraints — required, unique, max length, precision and scale — are attribute properties, not validation rules. Set those on the attribute itself and keep validations for genuine business logic.

Prefer a domain table over a long list

One of (list) is fine for three or four fixed values. Beyond that, use a domain table. The business can then maintain the allowed values themselves, without a structure change, and users get a searchable picker with readable labels.

Table level rules: comparing two attributes

Some rules cannot live on a single attribute — they are about the relationship between two. Open the table and use its validation editor to add a comparison.

Each comparison rule has a left attribute, an operator and a right attribute:

Operator	Meaning
>	is greater than
>=	is greater than or equal to
<	is less than
<=	is less than or equal to
!=	is not equal to

The two attributes must be of a compatible family:

Family	Datatypes	Allowed operators
Number	integer, decimal	all
Temporal	date, datetime	all
String	string	!= only

Examples

Rule	Reads as
valid_to > valid_from	The end of a period must be after its start
soft_limit <= hard_limit	A soft limit may not exceed the hard limit
primary_contact != backup_contact	The two contacts must be different people

Note

Domain table attributes cannot be used in comparison rules — there is no meaningful ordering between two references.

Preview before you enforce

The validation editor has a Preview action. It runs the proposed rule against the records already in the table and reports:

• How many records are valid.
• How many would fail.
• A sample of the failing records, with Code, Name and the specific failure messages.

Always preview

Adding a rule to a table with existing data is the moment things break. Preview first: if 400 of 4,000 rows fail, you want to know that before your users find out on their next upload. Fix the data, then add the rule.

What users see when validation fails

A save is all-or-nothing per record. When a record fails:

• The record is not written. No partial save, no truncated value.
• An entry is added to the record audit with status error and a human-readable message.
• In the web app, the message appears directly in the record form.
• In Excel and Google Sheets, the failing rows are reported back after the upload so the user can correct them and try again.

Write rules whose failure message makes sense

A regex of ^[1-9][0-9]{3}$ is precise but cryptic to a user reading a rejection. Where you can, give the attribute a description explaining the expected format so the person fixing the row knows what “good” looks like.

Designing a validation strategy

1. Start with attribute properties. Required, unique and max length cover a surprising amount, and they cost nothing.

2. Replace free text with domain tables wherever a fixed set of values exists. This removes whole classes of error rather than catching them.

3. Add attribute validations for format rules that a lookup cannot express — patterns, ranges, minimum lengths.

4. Add table validations for cross-field business rules.

5. Preview each rule against real data before saving it.

Do not over-constrain

Every rule is one more reason an upload can fail. Rules that reflect real business requirements pay for themselves; rules that encode one person’s preference will just make your users work around the system.