Data Validation Rules

Data validation rules enforce data quality at the point of entry in editions. Rules are configured per field in the blueprint and evaluated in real time as contributors type, select, or save values.

---

Validation behaviour modes

Each validation rule has a behaviour setting that controls what happens when a value fails validation:

Behaviour	What happens	Edition submit?
Warn	A yellow warning indicator appears on the field. The contributor can proceed.	Allowed — with a warning count shown
Block	A red error indicator appears. The field is marked incomplete.	Blocked — contributor must fix before submitting

Choose Block for rules that must be enforced (e.g. a cost variance that cannot exceed budget without justification). Choose Warn for soft thresholds that flag unusual values but allow overrides.

---

Validation rule types by field type

Numeric fields (Number, Currency, Percent)

Rule	Configuration	Example
Minimum value	Enter the minimum allowed value	Budget must be ≥ 0
Maximum value	Enter the maximum allowed value	Completion % cannot exceed 1.0 (100%)
Range	Combine min and max	Cost variance between -20% and +20%
Decimal places	Fixed number of decimal places	Currency always 2 decimal places

Configuration steps:

1. Open the blueprint in Design mode.
2. Click the field → open Validation panel (right panel).
3. Enable Minimum and/or Maximum → enter values.
4. Set Behaviour to Warn or Block.
5. Enter a Validation message — shown to contributors when the rule triggers (e.g. "Completion percentage cannot exceed 100%").

---

Text fields (Text, Textarea)

Rule	Configuration	Example
Minimum length	Minimum character count	Executive summary must be at least 50 characters
Maximum length	Maximum character count	Short description cannot exceed 200 characters
Pattern (regex)	Regular expression the value must match	Project reference must match PRJ-\d{4}-\d{3}
Required	Field must not be empty	All required fields

Pattern validation examples:

Use case	Regex pattern
Project reference code	^PRJ-\d{4}-\d{3}$
Positive integers only	^\d+$
Email address	^[^\s@]+@[^\s@]+\.[^\s@]+$
No leading/trailing spaces	^\S.*\S$
Phone number (AU format)	^\+61\s?\d{9}$

tip

Test regex patterns in a tool like regex101.com before entering them. An incorrect pattern will block all values — including valid ones.

---

Date fields (Date, Datetime)

Rule	Configuration	Example
Minimum date	Fixed date or token	Forecast completion cannot be before project start
Maximum date	Fixed date or token	Data date cannot be in the future
Date tokens	Dynamic references	today, edition_start, edition_end

Date token reference:

Token	Resolves to
today	Current calendar date at time of validation
edition_start	The reporting period start date set on the edition
edition_end	The reporting period end date set on the edition
edition_data_date	The data date set on the edition

Example: Forecast finish date must be ≥ today: set Minimum to today with Warn behaviour.

---

Select and Multi-select fields

Select fields enforce valid values implicitly — contributors can only choose from the configured option list. No additional validation rules are needed unless Allow other is enabled.

When Allow other is enabled:

• The free-text value bypasses the option list.
• Use a Pattern rule on the text input to constrain free-text entries if needed.

Multi-select — Min/Max selections:

Rule	Example
Minimum selections	At least one risk category must be selected
Maximum selections	No more than 3 disciplines per action item

---

Required fields

Any field can be marked Required — this is the most basic validation rule.

• A required field blocks section completion (the section cannot be marked complete).
• Required fields are marked with * in form mode and in the section nav.
• Required is independent of Warn/Block behaviour — a required field always blocks submission if empty.

Required vs Block vs Warn:

• Required: Field must have a value. Blocks section completion.
• Block: Value must pass the rule. Blocks section completion.
• Warn: Value should pass the rule. Does not block — only flags.

---

Multi-field cross-validation

Cross-validation rules evaluate a relationship between two or more fields within the same section.

Supported cross-validation patterns:

Pattern	Example
Field A ≤ Field B	Actual cost ≤ Budget at completion
Field A < Field B	Start date < Finish date
Field A = Field B	Reforecast total = Sum of reforecast items
Conditional requirement	If Status = "At Risk", then Mitigation plan is required
Conditional range	If RAG = Red, then Variance must be ≥ 10%

Configuring a cross-validation rule

Cross-validation rules are configured on the section level, not individual fields.

1. Open the section in blueprint design mode.
2. Click Section settings → Validation rules.
3. Click + Add cross-field rule.
4. Configure:
   • Condition field — the field whose value triggers the check
   • Condition — the comparison or value that activates the rule
   • Target field — the field that must satisfy a requirement
   • Target rule — required, minimum, maximum, or pattern
   • Behaviour — Warn or Block
   • Validation message — shown to the contributor

Example: Conditional requirement rule

If the Schedule Status field is set to "Behind", then the Recovery Plan textarea field is required.

Configuration:

• Condition field: Schedule Status
• Condition: equals "Behind"
• Target field: Recovery Plan
• Target rule: Required
• Behaviour: Block
• Message: "A recovery plan is required when schedule status is Behind."

---

Validation panel in the edition

While a contributor is filling in an edition, the Validation panel (right panel in edition view) provides a live summary:

Panel section	Content
Errors	Block-mode rules that are currently failing — must be fixed
Warnings	Warn-mode rules that are flagged — can be ignored with intent
Incomplete required fields	Fields marked required that are still empty

Clicking any item in the validation panel navigates directly to the affected field or row.

Validation at submit time

When a contributor clicks Submit for review, Report Forge runs a full validation pass:

• If any Block rules are failing, the submit is prevented — the validation panel highlights all failures.
• If only Warn rules are failing, submit proceeds but the edition is marked with a warning count visible to reviewers.
• Reviewers can see which warnings are active on the edition and can raise comments asking for clarification.

---

Repeating section rows — row-level validation

In grid mode (repeating sections), validation rules apply per row:

• Each row that violates a rule is flagged with a coloured row indicator.
• Red indicator: one or more Block rules are failing.
• Yellow indicator: one or more Warn rules are flagged.
• The validation panel lists all rows with issues.

The grid header shows the count of rows with errors, so contributors can see at a glance how many rows need attention.

---

Validation message guidelines

Write validation messages that tell contributors exactly what to fix:

Avoid	Use instead
"Invalid value"	"Completion percentage must be between 0 and 100."
"Error"	"Actual cost cannot exceed the Budget at Completion. If costs are over budget, update the EAC."
"Required"	"A mitigation owner is required for all Red-rated risks."

A good validation message is:

• Specific about what value is expected.
• Actionable — tells the contributor what to do, not just what is wrong.
• Professional — it appears to all contributors, not just the person who made the error.

---

Related

• Blueprint Field Types — all field types and their properties
• Blueprint Form Designer — configuring sections and fields
• Field Validation Reference — full table of validation options per field type
• Edition Form Mode — how contributors interact with validated fields