When working with forms in ActivityInfo, records in the interactive table are marked as valid or invalid. While validation rules play an important role in this process, they are only one part of how ActivityInfo determines whether a record is valid.
This article explains what determines the overall validity of a record.
What is record validity?
A record is considered valid when it satisfies all constraints and validation rules defined in the form at any moment in time.
As a result:
- A record that was valid when it was created can become invalid later
- Validation errors may appear even if no one has edited the data
This behavior is always present in ActivityInfo, but it becomes visible in the interactive table, where many records are displayed at once and invalid cells are highlighted immediately.
Factors that affect form validity
Record validity in ActivityInfo is determined by multiple form properties, including:
- Validation rules
- Required fields
- Key and unique fields
- Relevance rules
- Input masks
- Default values
Validation rules
Validation rules using date and time
When validation rules depend on the current date or time.
Functions such as:
These functions return different values as time passes. Validation rules that use these functions will therefore change their outcome over time.
Example
SESSION_DATE >= ADDDATE(TODAY(), -7) &&
SESSION_DATE < ADDDATE(TODAY(), 7)
This rule requires the session date to be within seven days of today. The rule may be satisfied when the record is first added, but weeks later the same record may fall outside this range and become invalid.
When viewing data in the interactive table, this can result in many records showing validation errors at the same time.
Review each validation rule and determine whether it is intended to:
- Always be true for the lifetime of the record.
- Apply only when the data is first entered.
- Logical relationships between fields (for example, a start date before an end date)
- Numeric limits that should never be exceeded
Rules that should apply only when data is entered
These rules are well suited to continuous validation and behave the same in forms and in the interactive table.
If a rule is intended to validate data only at the moment it is entered, this must be made explicit in the formula.
A common approach is to apply the validation rule only while the record is new.
IF(ISBLANK(_lastEditTime), START_DATE < TODAY(), TRUE)
With this rule:
- New records must satisfy the date requirement
- Existing records remain valid as time passes
This prevents historical data from becoming invalid when viewed in the interactive table.
Required fields
Required fields must contain a value before the record can be considered valid.
If a required field is empty:
- The record is marked invalid in the interactive table
- The missing field is highlighted
- The record cannot be submitted until the field is completed
It is important to note that required status is evaluated in combination with relevance rules. A field that is not relevant (hidden due to a relevance condition) is not required. However, if the field becomes relevant and remains empty, the record becomes invalid.
If required fields are introduced after records already exist in the form, those records may become invalid if they do not contain values that satisfy the new requirements.
Key and unique fields
Fields marked as key or unique enforce form level uniqueness.
A key field identifies a record. Two records in the same form cannot share the same key value.
A unique field ensures that no two records contain the same value in that field.
If a duplicate value is entered:
- The record is immediately marked invalid
- The duplicate conflict must be resolved before the record becomes valid
Uniqueness is checked across all records in the form, not just within the current page of the interactive table.
These constraints are commonly used for identifiers such as:
- Registration numbers
- Household IDs
- National ID numbers
- Facility codes
Because uniqueness is enforced at the database level, it directly affects overall record validity.
Relevance rules
Relevance rules determine whether a field is applicable in a given context.
When a relevance condition evaluates to false:
- The field is hidden
- The field is not required
- Its value does not affect record validity
However, when the relevance condition evaluates to true:
- The field becomes visible
- If marked as required, it must be completed
- Its value is evaluated against other constraints
For example:
- A “Pregnancy status” field may only be relevant if Gender = Female
If a field becomes relevant and is required but remains empty, the record becomes invalid.
Relevance rules therefore influence validity indirectly by controlling which constraints apply at a given time.
Input masks
Input masks enforce formatting rules for text fields.
An input mask defines the required structure of a value, such as:
- Phone numbers
- National ID formats
- Postal codes
- Structured codes or identifiers
If a value does not match the defined format:
- The field is flagged
- The record is marked invalid
- The value must be corrected before the record becomes valid
Input masks ensure consistent formatting across records, which improves data quality and downstream analysis.
Unlike validation rules, input masks focus strictly on format rather than logical relationships between fields.
Default values
Default values automatically populate a field when a new record is created. They are designed to improve efficiency by prefilling commonly used values, such as a status, reporting period, or zero for numeric fields.
Default values are applied only once, at the time of record creation. They are not continuously re evaluated after the record is saved.
Default values can use expressions such as TODAY() or NOW(). When used, these functions capture the current date or time at the moment the record is created. The value does not update afterward.
Default values do not directly determine record validity. However, they can influence it indirectly. For example:
- A default value can help satisfy a required field
- A default value may violate a validation rule
- A default value in a Unique field may create a duplicate
Overall record validity is still determined by all applicable constraints in the form.
Summary
In ActivityInfo, a record is valid only when it meets all constraints defined in the form. The validity indicator in the interactive table reflects the overall status of the record, not just the outcome of validation rules.
Record validity may be affected by required fields, Key and Unique constraints, relevance rules, input masks, validation rules, and default values that interact with other constraints.
Validation rules are only one part of this broader framework. An invalid record does not necessarily mean that a validation rule has failed.
The interactive table does not change how record validity works. It simply makes records that infringe constraints, including validation rules, more visible.
Understanding how these elements work together helps users diagnose and resolve invalid records more effectively.