Form Builder Rules Guide

Introduction
What Are Form Rules?
Accessing the Rules Builder
Rule Components
Creating Your First Rule
Conditions Explained
Actions Explained
Conditional Logic (AND vs. OR)
Rule Examples by Use Case
Advanced Rule Patterns
Testing and Debugging Rules
Best Practices
Common Pitfalls
Troubleshooting Guide

Introduction

The Rules Builder is a powerful feature within the RegScale Form Builder that allows you to create conditional logic for module forms. With rules, you can make forms dynamic and intelligent, showing or hiding fields, requiring specific data, and automatically populating values based on user input or system state.

Who Should Use This Guide

Administrators configuring RegScale modules
Business Analysts designing compliance workflows
Security Managers customizing assessment forms
Anyone needing to create conditional form behavior

What You'll Learn

By the end of this guide, you'll be able to:

Create rules that show/hide fields based on conditions
Set up automatic field population based on user input
Configure conditional field requirements
Build complex multi-condition rules
Test and troubleshoot your rules

What Are Form Rules?

Form rules are if-then statements that control form behavior dynamically. They follow this simple pattern:

IF [certain conditions are true]
THEN [perform specific actions]

Real-World Example

Without Rules: Every vulnerability form shows all fields all the time, even if they're not relevant.

With Rules:

When severity is "Critical", automatically show and require "Executive Approval" fields
When status changes to "Closed", automatically set "Closed Date" to today
When a vulnerability has no parent record (is new), hide the "Resolution" section

Why Use Rules?

Better User Experience: Users only see relevant fields
Data Quality: Enforce business requirements conditionally
Automation: Reduce manual data entry
Consistency: Ensure policies are followed automatically
Flexibility: Adapt forms to different scenarios without creating multiple form templates

Accessing the Rules Builder

Step-by-Step Access

Log into RegScale with Administrator credentials
Navigate to Admin → Form Builder
Select a module from the dropdown (e.g., Vulnerabilities, Risks, Issues)
Scroll down to the Rules section at the bottom of the page
You'll see existing rules listed, with an [+ Add Rule] button

Rules Section Layout

┌─────────────────────────────────────────────────────────┐
│  RULES                                                   │
│  ┌─────────────────────────────────────────────────┐   │
│  │  [+ Add Rule]                                    │   │
│  └─────────────────────────────────────────────────┘   │
│                                                          │
│  ┌─────────────────────────────────────────────────┐   │
│  │  Rule: Show CVE Fields for Critical              │   │
│  │  Conditional Logic: AND                          │   │
│  │                                                   │   │
│  │  CONDITIONS:                                      │   │
│  │  • Severity equals "Critical"                    │   │
│  │                                                   │   │
│  │  ACTIONS:                                         │   │
│  │  • SHOW field "CVE Number"                       │   │
│  │  • REQUIRE field "CVE Number"                    │   │
│  │                                                   │   │
│  │  [Edit] [Duplicate] [Delete]                     │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

Rule Components

Every rule consists of three essential components:

1. Rule Name

A descriptive label for the rule.

Examples:

"Show HIPAA Fields for Healthcare"
"Require Mitigation for High Risk"
"Auto-Set Closed Date"

Best Practice: Use clear, action-oriented names that describe what the rule does.

2. Conditions

The IF part—what must be true for the rule to activate.

Components of a Condition:

Condition Type: What kind of condition (Field, System, Tenant Feature, Module)
Target: What to check (which field, which feature, etc.)
Operator: How to compare (equals, greater than, etc.)
Value: What to compare against

Example:

Type: Field
Target: "Status"
Operator: EQUALS
Value: "Critical"

3. Actions

The THEN part—what happens when conditions are met.

Components of an Action:

Action Type: What to do (SHOW, HIDE, REQUIRE, SET_VALUE, etc.)
Target: What field or tab to affect
Additional Settings: Varies by action type

Example:

Type: SHOW
Target: Field "Mitigation Plan"

4. Conditional Logic (Optional for Multiple Conditions)

How multiple conditions are combined:

AND: All conditions must be true
OR: At least one condition must be true

Creating Your First Rule

Let's create a simple rule step-by-step.

Scenario

Goal: Show and require "Mitigation Plan" field when vulnerability severity is "Critical".

Step 1: Add a New Rule

In the Rules section, click [+ Add Rule]
A new rule panel appears
Enter a Rule Name: "Require Mitigation for Critical Vulnerabilities"

Step 2: Add a Condition

Click [+ Add Condition]
A condition form appears
Configure:
- Condition Type: Select "Field"
- Field: Select "Severity" from dropdown
- Operator: Select "EQUALS"
- Value: Type "Critical" or select from dropdown
Click Save or Done

Your condition now reads: "When Severity equals Critical"

Step 3: Add an Action

Click [+ Add Action]
An action form appears
Configure:
- Action Type: Select "SHOW"
- Target Type: Select "Field"
- Field: Select "Mitigation Plan"
Click Save or Done

Step 4: Add Another Action

To also make the field required:

Click [+ Add Action] again
Configure:
- Action Type: Select "REQUIRE"
- Target Type: Select "Field"
- Field: Select "Mitigation Plan"
Click Save

Step 5: Save the Rule

Review your rule configuration:
- Name: "Require Mitigation for Critical Vulnerabilities"
- Condition: Severity equals "Critical"
- Actions: SHOW "Mitigation Plan", REQUIRE "Mitigation Plan"
Click [Save Rule] or just click the overall [Save Changes] button at the bottom of the Form Builder

Step 6: Test Your Rule

Navigate to the Vulnerabilities module
Create or edit a vulnerability
Change Severity to "Critical"
Observe:
- "Mitigation Plan" field becomes visible
- "Mitigation Plan" field is marked as required
Change Severity to "Low"
Observe:
- "Mitigation Plan" field disappears (or becomes optional if it was always visible)

Congratulations! You've created your first form rule.

Conditions Explained

Conditions are the triggers that determine when a rule activates.

Condition Types

1. Field Conditions

Check the value of any field in the form.

When to Use:

Show additional fields based on selections
Require data based on risk level
Auto-populate based on status changes

Configuration:

Field: Which field to check
Operator: How to compare (see Operators table below)
Value: What to compare against

Examples:

Status equals "Closed"
Severity not equals "Low"
Score greater than 75
Due Date before "2024-12-31"
Description has value (is not empty)

2. System Conditions

Special conditions about the record state.

NO_PARENT:

When True: Creating a new record (no parent entity)
Use Case: Hide advanced fields for new records
Example: "When creating a new vulnerability, hide the Resolution section"

NO_CONDITION:

When True: Always (this condition is always true)
Use Case: Rules that should always apply
Example: "Always show the Help Text field"

3. Tenant Feature Conditions

Check if a specific RegScale feature is enabled for your tenant.

When to Use:

Show advanced features only if licensed
Enable integrations based on subscription
Gate premium functionality

Configuration:

Feature: Select from available tenant features
Operator: ENABLED or DISABLED

Examples:

AI Tools feature is ENABLED → Show "AI Risk Analysis" field
Advanced Reporting feature is DISABLED → Hide custom report fields

4. Module Conditions

Check if a specific RegScale module is enabled.

When to Use:

Cross-module integration
Show fields that link to other modules
Conditional features based on licensed modules

Configuration:

Module: Select from available modules
Operator: ENABLED or DISABLED

Examples:

Compliance module is ENABLED → Show "Control Mapping" field
Risk module is ENABLED → Show "Link to Risk" field

Operators Reference

The operator determines how the condition value is compared.

For Text Fields

Operator	Description	Example
EQUALS	Exact match	Status EQUALS "Open"
NOT_EQUALS	Not an exact match	Status NOT_EQUALS "Closed"
HAS_VALUE	Field is not empty	Description HAS_VALUE
NO_VALUE	Field is empty	Notes NO_VALUE

For Numeric Fields

Operator	Description	Example
EQUALS	Exact number	Priority EQUALS 1
NOT_EQUALS	Different number	Score NOT_EQUALS 0
GREATER_THAN	Larger number	Score GREATER_THAN 75
LESS_THAN	Smaller number	Cost LESS_THAN 10000
HAS_VALUE	Field is not empty	Score HAS_VALUE
NO_VALUE	Field is empty	Estimate NO_VALUE

For Date Fields

Operator	Description	Example
EQUALS	Exact date	DueDate EQUALS "2024-12-31"
NOT_EQUALS	Different date	CreatedDate NOT_EQUALS "2024-01-01"
BEFORE	Earlier than	DueDate BEFORE "2024-12-31"
AFTER	Later than	StartDate AFTER "2024-01-01"
WITHIN_LAST	Within past X days	LastReview WITHIN_LAST 30
WITHIN_NEXT	Within next X days	DueDate WITHIN_NEXT 7
HAS_VALUE	Field is not empty	ReviewDate HAS_VALUE
NO_VALUE	Field is empty	CompletionDate NO_VALUE

For Dropdown/Select Fields

Operator	Description	Example
EQUALS	Selected option matches	Category EQUALS "Network Security"
NOT_EQUALS	Selected option doesn't match	Type NOT_EQUALS "False Positive"
HAS_VALUE	An option is selected	AssignedTo HAS_VALUE
NO_VALUE	No option selected	Reviewer NO_VALUE

For Boolean Fields (Checkbox/Toggle)

Operator	Description	Example
EQUALS	Matches true/false	Approved EQUALS true
NOT_EQUALS	Doesn't match	ExternalVendor NOT_EQUALS true
HAS_VALUE	Has been set (true or false)	Verified HAS_VALUE
NO_VALUE	Not yet set	Reviewed NO_VALUE

For Feature/Module Conditions

Operator	Description	Example
ENABLED	Feature/module is active	AI Tools ENABLED
DISABLED	Feature/module is inactive	Advanced Reporting DISABLED

Condition Value Sources

Values in conditions can come from two sources:

1. Constant Values

You manually type or select a specific value.

Examples:

"Critical"
"Closed"
100
"2024-12-31"
true

2. Field References (Advanced)

You can reference another field's value dynamically.

Syntax: Select the field from a dropdown (if supported)

Examples:

End Date must be AFTER Start Date (comparing two date fields)
Estimated Cost must be LESS_THAN Approved Budget (comparing two numeric fields)

Note: Field reference support varies by field type and may not be available for all operators.

Multiple Conditions

You can add multiple conditions to a single rule. How they're combined depends on the Conditional Logic setting.

AND Logic

All conditions must be true for actions to execute.

Example:

Rule: "Show Executive Approval for Critical External Risks"

Conditions (AND):
  • Severity equals "Critical"
  • External Vendor equals true
  • Status equals "Open"

Actions:
  • SHOW field "Executive Approver"
  • REQUIRE field "Executive Approval Date"

Result: Executive approval fields only show when ALL THREE conditions are true.

OR Logic

At least one condition must be true for actions to execute.

Example:

Rule: "Require Mitigation for High Impact"

Conditions (OR):
  • Severity equals "Critical"
  • Severity equals "High"
  • Financial Impact GREATER_THAN 100000

Actions:
  • REQUIRE field "Mitigation Plan"
  • SHOW field "Mitigation Owner"

Result: Mitigation is required if severity is Critical OR High OR financial impact exceeds $100,000.

Actions Explained

Actions define what happens when rule conditions are met.

Action Types Overview

Action Type	Purpose	Example
SHOW	Make field/tab visible	Show "CVE Number"
HIDE	Make field/tab invisible	Hide "Advanced Options"
REQUIRE	Make field mandatory	Require "Approval Date"
NOT_REQUIRE	Make field optional	Make "Notes" optional
ENABLE	Make field editable	Enable "Override Score"
DISABLE	Make field read-only	Disable "Auto-Calculated Field"
SET_VALUE	Auto-populate field	Set "Closed Date" to TODAY
VALIDATE	Apply validation rule	Validate "End Date" AFTER "Start Date"

SHOW Action

Makes a field or entire tab visible to users.

When to Use:

Progressive disclosure (show more fields as needed)
Conditional sections based on user selections
Context-specific fields

Configuration:

Target Type: Field or Tab
Target: Select which field or tab to show

Examples:

Example 1: Show CVE fields for vulnerabilities

Action: SHOW
Target: Field "CVE Number"

Example 2: Show entire resolution section

Action: SHOW
Target: Tab "Resolution Details"

Behavior:

Field/tab becomes visible immediately when conditions are met
If conditions become false, field/tab may hide again (unless another rule keeps it visible)
If field was previously filled, data is preserved when shown again

HIDE Action

Makes a field or tab invisible to users.

When to Use:

Simplify forms by hiding irrelevant fields
Hide advanced options from basic users
Conditional form sections

Configuration:

Target Type: Field or Tab
Target: Select which field or tab to hide

Examples:

Example 1: Hide advanced options for new records

Condition: System NO_PARENT
Action: HIDE
Target: Tab "Advanced Configuration"

Example 2: Hide false positive fields when not applicable

Condition: Type NOT_EQUALS "False Positive"
Action: HIDE
Target: Field "False Positive Justification"

Behavior:

Field/tab becomes invisible
Hidden fields are not required (even if marked required in field settings)
Data in hidden fields is preserved (not deleted)

Important: If multiple rules affect the same field, the last rule evaluated wins.

REQUIRE Action

Makes a field mandatory—users must fill it in before saving.

When to Use:

Conditional data requirements
Enforce business rules (e.g., require mitigation for high risks)
Compliance mandates

Configuration:

Target Type: Field
Target: Select which field to require

Examples:

Example 1: Require mitigation for critical vulnerabilities

Condition: Severity EQUALS "Critical"
Action: REQUIRE
Target: Field "Mitigation Plan"

Example 2: Require approval for high-cost items

Condition: Estimated Cost GREATER_THAN 50000
Action: REQUIRE
Target: Field "Executive Approver"

Behavior:

Field is marked with asterisk (*) or other required indicator
Form validation prevents saving if field is empty
User receives error message if they attempt to save without filling the field

Note: Field must also be visible (either via SHOW action or by default) for requirement to take effect.

NOT_REQUIRE Action

Makes a field optional (removes mandatory requirement).

When to Use:

Conditional optional fields
Reduce data entry burden for low-priority items
Override default required status

Configuration:

Target Type: Field
Target: Select which field to make optional

Examples:

Example 1: Make justification optional for low severity

Condition: Severity EQUALS "Low"
Action: NOT_REQUIRE
Target: Field "Business Justification"

Example 2: Waive requirements for closed items

Condition: Status EQUALS "Closed"
Action: NOT_REQUIRE
Target: Field "Follow-up Actions"

Behavior:

Required indicator (*) is removed
User can save form without filling the field
Data quality checks may still apply

ENABLE Action

Makes a field editable by users.

When to Use:

Conditional editing permissions
Unlock fields after certain conditions
Allow overrides in specific scenarios

Configuration:

Target Type: Field
Target: Select which field to enable

Examples:

Example 1: Allow score override for admins

Condition: User Role EQUALS "Administrator" (if supported)
Action: ENABLE
Target: Field "Manual Score Override"

Example 2: Enable editing after approval

Condition: Approval Status EQUALS "Approved"
Action: ENABLE
Target: Field "Implementation Notes"

Behavior:

Field becomes editable (input enabled)
User can modify the field value
Validation rules still apply

DISABLE Action

Makes a field read-only—users can see it but cannot edit.

When to Use:

Lock fields after certain stages
Prevent changes to calculated/system values
Display-only information

Configuration:

Target Type: Field
Target: Select which field to disable

Examples:

Example 1: Lock fields after approval

Condition: Status EQUALS "Approved"
Action: DISABLE
Target: Field "Risk Assessment"

Example 2: Prevent editing of auto-calculated scores

Condition: Score Type EQUALS "Automatic"
Action: DISABLE
Target: Field "Score"

Behavior:

Field appears grayed out or with read-only styling
User cannot modify the value
Data is visible but not editable

SET_VALUE Action

Automatically populates a field with a specific value.

When to Use:

Auto-fill dates based on status changes
Set default values based on selections
Copy values between fields
Calculate derived values

Configuration:

Target Type: Field
Target: Select which field to populate
Operator: How to set the value (usually EQUALS)
Value: What to set it to (constant or field reference)
Bypass Existing Value: Whether to overwrite if field already has data
Allow External Value: Whether API/integrations can override

Examples:

Example 1: Set closed date when status changes

Condition: Status EQUALS "Closed"
Action: SET_VALUE
Target: Field "Closed Date"
Value: TODAY
Bypass Existing: No (don't overwrite if already set)

Example 2: Auto-set risk level based on score

Condition: Risk Score GREATER_THAN 80
Action: SET_VALUE
Target: Field "Risk Level"
Value: "High"
Bypass Existing: Yes

Example 3: Copy value from another field

Condition: Use Primary Contact EQUALS true
Action: SET_VALUE
Target: Field "Reviewer Email"
Value: @PrimaryContact.Email (field reference)

Special Values:

TODAY: Current date
NOW: Current date and time
@FieldName: Reference to another field (if supported)

Behavior:

Field is automatically populated when conditions are met
If "Bypass Existing Value" is unchecked, existing data is preserved
If "Bypass Existing Value" is checked, value is always overwritten
User can manually change the value (unless field is also disabled)

VALIDATE Action

Applies a validation rule to a field based on conditions.

When to Use:

Conditional validation requirements
Business rule enforcement
Cross-field validation

Configuration:

Target Type: Field
Target: Select which field to validate
Operator: Validation type (GREATER_THAN, BEFORE, etc.)
Value: Validation constraint

Examples:

Example 1: Due date must be within 30 days for high priority

Condition: Priority EQUALS "High"
Action: VALIDATE
Target: Field "Due Date"
Operator: WITHIN_NEXT
Value: 30

Example 2: Cost must not exceed budget for non-approved items

Condition: Approval Status NOT_EQUALS "Approved"
Action: VALIDATE
Target: Field "Estimated Cost"
Operator: LESS_THAN
Value: @Budget.Amount (field reference)

Behavior:

Validation is applied when user attempts to save
If validation fails, user receives error message
Form cannot be saved until validation passes
Different from field-level validations (which are always active)

Conditional Logic (AND vs. OR)

When you have multiple conditions, you must specify how they're combined.

AND Logic

Definition: ALL conditions must be true for actions to execute.

Visual Representation:

Condition 1 ✓ TRUE
    AND
Condition 2 ✓ TRUE
    AND
Condition 3 ✓ TRUE
    ↓
Actions Execute

Use Cases:

Narrow, specific scenarios
Multiple requirements must be met
Strict business rules

Example Scenario:
"Show executive approval fields ONLY when:

Severity is Critical AND
Cost exceeds $100,000 AND
External vendor is involved"

Conditions (AND):
  • Severity EQUALS "Critical"
  • Estimated Cost GREATER_THAN 100000
  • External Vendor EQUALS true

Actions:
  • SHOW field "Executive Approver"
  • REQUIRE field "Approval Date"

Result: All three conditions must be true. If ANY condition is false, actions don't execute.

OR Logic

Definition: AT LEAST ONE condition must be true for actions to execute.

Visual Representation:

Condition 1 ✓ TRUE
    OR
Condition 2 ✗ FALSE
    OR
Condition 3 ✗ FALSE
    ↓
Actions Execute (because at least one is true)

Use Cases:

Multiple paths to the same outcome
Broad applicability
Alternative triggers

Example Scenario:
"Require mitigation plan when ANY of these are true:

Severity is Critical OR
Severity is High OR
Financial Impact exceeds $50,000"

Conditions (OR):
  • Severity EQUALS "Critical"
  • Severity EQUALS "High"
  • Financial Impact GREATER_THAN 50000

Actions:
  • REQUIRE field "Mitigation Plan"
  • SHOW field "Mitigation Owner"

Result: If ANY condition is true, actions execute. Only if ALL are false do actions not execute.

Choosing Between AND and OR

Use AND when:

All criteria must be met
Narrow, specific scenarios
Strict requirements

Use OR when:

Any of several criteria triggers the action
Broad applicability
Alternative paths

Complex Logic:
For complex scenarios like "(A AND B) OR (C AND D)", you'll need multiple rules:

Rule 1:
Conditions (AND): A, B
Actions: X, Y

Rule 2:
Conditions (AND): C, D
Actions: X, Y

Rule Examples by Use Case

Use Case 1: Progressive Disclosure

Scenario: Hide advanced fields from new users, show after they become familiar.

Rule: "Hide Advanced Options for New Records"

Conditions:
  • System: NO_PARENT (new record)

Actions:
  • HIDE tab "Advanced Configuration"
  • HIDE tab "Integration Settings"

Result: When creating a new vulnerability, advanced tabs are hidden. When editing existing vulnerabilities, they appear.

Use Case 2: Status-Based Field Requirements

Scenario: Require different fields based on vulnerability status.

Rule 1: "Require Closure Information"

Conditions:
  • Status EQUALS "Closed"

Actions:
  • REQUIRE field "Closed Date"
  • REQUIRE field "Resolution Notes"
  • REQUIRE field "Closed By"

Rule 2: "Require Mitigation for In Progress"

Conditions:
  • Status EQUALS "In Progress"

Actions:
  • REQUIRE field "Mitigation Plan"
  • REQUIRE field "Assigned To"
  • REQUIRE field "Target Date"

Use Case 3: Automatic Date Population

Scenario: Auto-set dates based on status changes.

Rule: "Set Closed Date on Closure"

Conditions:
  • Status EQUALS "Closed"

Actions:
  • SET_VALUE on "Closed Date"
    - Value: TODAY
    - Bypass Existing: No

Result: When status changes to "Closed", if Closed Date is empty, it's set to today. If already set, it's preserved.

Use Case 4: Risk-Based Requirements

Scenario: Higher risk items require more documentation.

Rule: "High Risk Requirements"

Conditions (OR):
  • Severity EQUALS "Critical"
  • Severity EQUALS "High"

Actions:
  • REQUIRE field "Business Impact"
  • REQUIRE field "Mitigation Plan"
  • REQUIRE field "Executive Sponsor"
  • SHOW field "Risk Acceptance Form"

Use Case 5: Conditional Visibility Based on Type

Scenario: Show different fields based on vulnerability type.

Rule: "Show Network Fields"

Conditions:
  • Vulnerability Type EQUALS "Network"

Actions:
  • SHOW field "IP Address"
  • SHOW field "Port"
  • SHOW field "Protocol"

Rule: "Show Application Fields"

Conditions:
  • Vulnerability Type EQUALS "Application"

Actions:
  • SHOW field "Application Name"
  • SHOW field "Application URL"
  • SHOW field "Affected Module"

Use Case 6: Compliance Framework Specific Fields

Scenario: Show framework-specific fields when that framework is selected.

Rule: "Show HIPAA Fields"

Conditions:
  • Compliance Framework EQUALS "HIPAA"

Actions:
  • SHOW field "PHI Involved"
  • SHOW field "BAA Required"
  • SHOW field "Covered Entity"
  • REQUIRE field "Privacy Impact"

Rule: "Show PCI-DSS Fields"

Conditions:
  • Compliance Framework EQUALS "PCI-DSS"

Actions:
  • SHOW field "Cardholder Data Involved"
  • SHOW field "PCI DSS Requirement"
  • REQUIRE field "Card Data Environment"

Use Case 7: Feature-Based Field Display

Scenario: Show AI-generated fields only if AI feature is enabled.

Rule: "Show AI Features"

Conditions:
  • Tenant Feature "AI Tools" ENABLED

Actions:
  • SHOW field "AI Risk Score"
  • SHOW field "AI Recommendations"
  • SHOW field "ML Confidence Level"
  • ENABLE field "Use AI Analysis"

Use Case 8: Cross-Field Validation

Scenario: Ensure end date is after start date.

Rule: "Validate Date Range"

Conditions:
  • Start Date HAS_VALUE
  • End Date HAS_VALUE

Actions:
  • VALIDATE field "End Date"
    - Operator: AFTER
    - Value: @StartDate (field reference)

Result: User gets validation error if they set End Date before Start Date.

Use Case 9: Conditional Field Locking

Scenario: Lock fields after approval to prevent changes.

Rule: "Lock After Approval"

Conditions:
  • Approval Status EQUALS "Approved"

Actions:
  • DISABLE field "Risk Assessment"
  • DISABLE field "Severity"
  • DISABLE field "Impact Analysis"
  • DISABLE field "Mitigation Strategy"

Use Case 10: Multi-Condition Business Logic

Scenario: Executive approval required for critical external vendor issues.

Rule: "Executive Approval Required"

Conditions (AND):
  • Severity EQUALS "Critical"
  • External Vendor EQUALS true
  • Status NOT_EQUALS "Closed"
  • Financial Impact GREATER_THAN 50000

Actions:
  • SHOW tab "Executive Review"
  • REQUIRE field "Executive Approver"
  • REQUIRE field "Executive Approval Date"
  • REQUIRE field "Business Justification"
  • SET_VALUE on "Requires Executive Review"
    - Value: true

Advanced Rule Patterns

Pattern 1: Cascading Rules

Create sequences where one rule's action triggers another rule's condition.

Example:

Rule 1: "Set High Risk Flag"
Condition: Score GREATER_THAN 80
Action: SET_VALUE on "Risk Level" = "High"

Rule 2: "Show Mitigation for High Risk"
Condition: Risk Level EQUALS "High"
Actions:
  • SHOW field "Mitigation Plan"
  • REQUIRE field "Mitigation Owner"

Result: Score > 80 → Risk Level = High → Mitigation fields shown

Pattern 2: Mutual Exclusivity

Ensure only one of several options is active.

Example:

Rule 1: "Show Manual Entry"
Condition: Entry Type EQUALS "Manual"
Actions:
  • SHOW field "Manual Input"
  • HIDE field "Import File"

Rule 2: "Show Import"
Condition: Entry Type EQUALS "Import"
Actions:
  • HIDE field "Manual Input"
  • SHOW field "Import File"

Pattern 3: Default Values with Overrides

Set default values but allow manual override.

Example:

Rule: "Default Due Date"
Conditions:
  • Priority EQUALS "High"
  • Due Date NO_VALUE

Actions:
  • SET_VALUE on "Due Date"
    - Value: @Created Date + 7 days (if supported)
    - Bypass Existing: No

Result: Sets due date for high priority only if not already set, allowing manual override.

Pattern 4: Conditional Show with Progressive Requirements

Show fields progressively, requiring more as risk increases.

Example:

Rule 1: "Show Basic Mitigation (Medium+)"
Conditions (OR):
  • Severity EQUALS "Medium"
  • Severity EQUALS "High"
  • Severity EQUALS "Critical"

Actions:
  • SHOW field "Mitigation Plan"

Rule 2: "Require Mitigation (High+)"
Conditions (OR):
  • Severity EQUALS "High"
  • Severity EQUALS "Critical"

Actions:
  • REQUIRE field "Mitigation Plan"
  • SHOW field "Mitigation Owner"

Rule 3: "Require Executive Review (Critical)"
Conditions:
  • Severity EQUALS "Critical"

Actions:
  • REQUIRE field "Mitigation Owner"
  • REQUIRE field "Executive Approval"
  • SHOW tab "Executive Review"

Result:

Medium: Mitigation plan shown but optional
High: Mitigation plan required, owner shown
Critical: All fields required, executive review tab shown

Pattern 5: Time-Based Rules

Rules based on date comparisons (if date operations supported).

Example:

Rule: "Flag Overdue Items"
Conditions:
  • Status NOT_EQUALS "Closed"
  • Due Date BEFORE TODAY

Actions:
  • SET_VALUE on "Overdue Flag" = true
  • REQUIRE field "Overdue Justification"

Testing and Debugging Rules

Test Your Rules

Method 1: Real-Time Testing

Save your rules
Navigate to the module (e.g., Vulnerabilities)
Create or edit a record
Manually trigger conditions by changing field values
Observe if expected actions occur

Method 2: Create Test Records

Create dedicated test records
Run through all scenarios
Verify each rule behaves as expected
Delete test records when done

Method 3: Use Multiple Scenarios
Test these scenarios:

✓ New record creation
✓ Editing existing records
✓ All possible condition values
✓ Edge cases (empty fields, extreme values)
✓ Multiple rules affecting same field

Debugging Techniques

Problem: Rule Not Firing

Debugging Steps:

Check Rule Active: Ensure rule isn't accidentally disabled
Verify Conditions:
- Are field names spelled correctly?
- Is the comparison value exactly right (case-sensitive)?
- Are all AND conditions true?
Check Field Visibility: Is the condition field visible and editable?
Review Rule Order: Earlier rules might prevent this rule from executing
Test Conditions Individually: Create a simple rule with just one condition to isolate the issue

Problem: Wrong Action Executing

Debugging Steps:

Check for Conflicting Rules: Multiple rules affecting the same field
Review Rule Order: Later rules override earlier ones
Verify Action Configuration: Target field/tab selected correctly?
Check Conditional Logic: Is AND/OR set correctly?

Problem: Field Not Showing/Hiding

Debugging Steps:

Check Multiple Rules: Other rules might be showing/hiding the same field
Verify Target: Is the correct field selected?
Check Default State: What's the field's default visibility in form settings?
Test Isolation: Disable other rules to isolate the issue

Problem: SET_VALUE Not Working

Debugging Steps:

Check "Bypass Existing Value": If unchecked, existing values won't be overwritten
Verify Value Format: Dates, numbers, booleans must be in correct format
Check Field Type: Can the target field accept the value type you're setting?
Verify Field Editability: Field must not be disabled by another rule

Rule Validation Errors

When saving, the Form Builder validates rules. Common errors:

"Rule must have a name"

Solution: Add a descriptive name to the rule

"Rule must have at least one condition"

Solution: Add at least one condition

"Rule must have at least one action"

Solution: Add at least one action

"Condition field not found"

Solution: The field referenced in the condition doesn't exist or was deleted

"Action target not found"

Solution: The field/tab targeted by the action doesn't exist

"Invalid operator for field type"

Solution: You selected an operator incompatible with the field type (e.g., BEFORE on a text field)

Best Practices

1. Start Simple

Begin with basic show/hide rules
Add complexity gradually
Test each rule before adding more

2. Use Descriptive Names

Good Names:

"Show CVE Fields for Critical Vulnerabilities"
"Require Executive Approval for High-Cost Items"
"Auto-Set Closed Date on Status Change"

Bad Names:

"Rule 1"
"Show Fields"
"Test"

3. Document Complex Rules

For complex business logic:

Add comments in the rule name or description (if available)
Keep external documentation of rule purposes
Note dependencies between rules

4. Test Thoroughly

Test Checklist:

✓ Rule fires when expected
✓ Rule doesn't fire when it shouldn't
✓ All actions execute correctly
✓ No unintended side effects
✓ Works with existing data
✓ Works with new records
✓ Performance is acceptable

5. Avoid Over-Complication

Keep rules as simple as possible
Break complex logic into multiple rules
Don't create rules that conflict with each other

6. Consider Performance

Too many rules can slow form loading
Minimize condition complexity
Remove unused rules

7. Plan Rule Order

Rules execute in the order they appear
Later rules can override earlier rules
Order matters when multiple rules affect the same field

8. Handle Edge Cases

Consider:

What if field is empty?
What if user changes their mind (changes selection back)?
What if multiple conditions trigger simultaneously?
What happens on form load vs. during editing?

9. Use System Conditions Wisely

NO_PARENT: Great for new vs. existing record behavior
NO_CONDITION: Use sparingly, only for always-active rules

10. Maintenance

Regularly review rules
Remove obsolete rules
Update rules when business requirements change
Test after making modifications

Common Pitfalls

Pitfall 1: Circular Logic

Problem: Rules that trigger each other infinitely.

Example:

Rule A: When Field X = "Yes", set Field Y = "No"
Rule B: When Field Y = "No", set Field X = "Yes"

Result: Infinite loop, form may freeze or behave erratically.

Solution: Avoid rules that set values triggering other rules that set the original value.

Pitfall 2: Conflicting Rules

Problem: Multiple rules with contradictory actions.

Example:

Rule A: When Status = "Open", SHOW field "Mitigation"
Rule B: When Priority = "Low", HIDE field "Mitigation"

Result: If Status = "Open" AND Priority = "Low", behavior is unpredictable (last rule wins).

Solution:

Use more specific conditions
Combine into a single rule with complex logic
Ensure rules don't contradict

Pitfall 3: Case Sensitivity

Problem: Condition values are case-sensitive but you didn't match exactly.

Example:

Rule: When Status EQUALS "closed"  (lowercase)
Actual field value: "Closed"  (capitalized)

Result: Rule never fires because "closed" ≠ "Closed".

Solution: Match exact capitalization, or use dropdown values which are consistent.

Pitfall 4: Hidden Required Fields

Problem: Making a field both required and hidden.

Example:

Rule: When Priority = "Low"
  • HIDE field "Justification"
  • REQUIRE field "Justification" (from field settings)

Result: User can't save (required field is missing) but can't see the field to fill it.

Solution: Use HIDE + NOT_REQUIRE together, or don't hide required fields.

Pitfall 5: Forgetting to Save

Problem: Creating rules but forgetting to click "Save Changes" at the bottom.

Result: Rules aren't persisted and disappear when you navigate away.

Solution: Always click "Save Changes" after creating/modifying rules.

Pitfall 6: Over-Engineering

Problem: Creating overly complex rule systems for simple requirements.

Example: 50 rules to handle what could be 5 well-designed rules.

Result: Hard to maintain, debug, and understand. Performance issues.

Solution: Keep it simple. Combine related logic. Remove unnecessary rules.

Pitfall 7: Not Testing Edge Cases

Problem: Only testing the "happy path."

Result: Rules break when users do unexpected things.

Solution: Test with:

Empty fields
Extreme values
Unusual combinations
Data from older records

Pitfall 8: Assuming Field References Work Everywhere

Problem: Trying to use field references (@FieldName) where they're not supported.

Result: Rule fails or behaves unexpectedly.

Solution: Check if field references are supported for your specific action/operator combination. Test thoroughly.

Troubleshooting Guide

Issue: Rule Doesn't Fire

Symptom: Conditions seem true but actions don't execute.

Checklist:

Is rule marked as "Active"?
Are condition field names spelled exactly right?
Are condition values matching exactly (case-sensitive)?
Is it AND logic when it should be OR (or vice versa)?
Are all condition fields visible and editable?
Is another rule overriding this one?
Did you save changes after creating the rule?

Debugging:

Create a simpler version of the rule with just one condition
Test if that fires
Add complexity incrementally

Issue: Field Shows When It Shouldn't

Symptom: Field is visible even when conditions aren't met.

Checklist:

Is another rule showing the field?
Is the field set to visible by default in form settings?
Are there conflicting rules?
Is the condition logic correct?

Debugging:

Disable all other rules
Test if field still shows
Re-enable rules one at a time to identify conflict

Issue: Required Field Won't Accept Data

Symptom: User fills in required field but still gets error.

Checklist:

Is field actually visible?
Is there a VALIDATE rule rejecting the value?
Is field format correct (date format, number format)?
Is another field actually the one that's required?

Debugging:

Check browser console for error messages
Try different values
Check validation rules

Issue: SET_VALUE Not Populating Field

Symptom: SET_VALUE action doesn't fill the field.

Checklist:

Is "Bypass Existing Value" checked (if field already has data)?
Is value format correct for field type?
Is another rule overriding the value?
Is field disabled (can't set value on disabled fields in some cases)?
Is the special value keyword correct (TODAY, NOW)?

Debugging:

Try setting a simple constant value first
Check if value appears briefly then disappears (indicates override)
Remove other rules affecting same field

Issue: Performance Problems

Symptom: Form loads slowly or becomes unresponsive.

Checklist:

Do you have a very large number of rules (50+)?
Are there circular logic issues?
Are conditions very complex?
Are there rules that trigger constantly?

Solutions:

Reduce number of rules (consolidate where possible)
Simplify condition logic
Remove debugging/test rules
Check for circular dependencies

Issue: Rules Work Inconsistently

Symptom: Sometimes rules work, sometimes they don't.

Checklist:

Are rules dependent on timing (form load order)?
Do rules depend on other rules' actions?
Are there race conditions with async operations?
Is browser caching affecting behavior?

Solutions:

Order rules to avoid dependencies
Hard refresh browser (Ctrl+F5)
Test in different browsers
Simplify rule dependencies

Issue: Can't Delete Rule

Symptom: Delete button doesn't work or rule comes back.

Checklist:

Is it a system-required rule (can't be deleted)?
Did you save changes after deleting?
Are you in edit mode vs. view mode?

Solutions:

If system-required, you can't delete it (deactivate instead)
Always save after deleting
Refresh page and try again

Getting Help

If problems persist:

Export Module Configuration: Backup before troubleshooting
Simplify: Remove all rules, add back one at a time
Document Issue:
- What you're trying to achieve
- What you've configured
- What's actually happening
- Screenshots
Contact Support: Provide all documentation to RegScale support

Quick Reference

Rule Creation Checklist

Condition Types

Field: Check field value
System - NO_PARENT: New record
System - NO_CONDITION: Always true
Tenant Feature: Feature enabled/disabled
Module: Module enabled/disabled

Action Types

SHOW: Make visible
HIDE: Make invisible
REQUIRE: Make mandatory
NOT_REQUIRE: Make optional
ENABLE: Make editable
DISABLE: Make read-only
SET_VALUE: Auto-populate
VALIDATE: Apply validation

Common Operators

EQUALS / NOT_EQUALS
GREATER_THAN / LESS_THAN
HAS_VALUE / NO_VALUE
BEFORE / AFTER (dates)
WITHIN_LAST / WITHIN_NEXT (dates)
ENABLED / DISABLED (features/modules)

Conclusion

The Form Builder Rules system is a powerful tool for creating dynamic, intelligent forms that adapt to your business needs. By mastering rules, you can:

Improve User Experience: Show only relevant fields
Enforce Business Logic: Automate compliance with policies
Reduce Errors: Guide users to provide correct information
Save Time: Auto-populate fields and reduce manual entry

Next Steps

Practice: Start with simple rules and build confidence
Experiment: Try different combinations of conditions and actions
Document: Keep track of your rules and their purposes
Iterate: Gather feedback and refine your rules over time

Additional Resources

Form Builder User Guide: Comprehensive guide to the entire Form Builder (includes field management, sections, import/export)
RegScale Documentation: Official documentation at docs.regscale.com
RegScale Support: Contact support for complex rule scenarios
RegScale Community: Share tips and tricks with other administrators

Remember: The best rules are simple, well-tested, and clearly serve a business purpose. Start simple, test thoroughly, and iterate based on feedback.

Document Version: 1.0
Last Updated: 2024
Applies to: RegScale Form Builder Rules System

Form Builder Rules Guide

Table of Contents

Introduction

Who Should Use This Guide

What You'll Learn

What Are Form Rules?

Real-World Example

Why Use Rules?

Accessing the Rules Builder

Step-by-Step Access

Rules Section Layout

Rule Components

1. Rule Name

2. Conditions

3. Actions

4. Conditional Logic (Optional for Multiple Conditions)

Creating Your First Rule

Scenario

Step 1: Add a New Rule

Step 2: Add a Condition

Step 3: Add an Action

Step 4: Add Another Action

Step 5: Save the Rule

Step 6: Test Your Rule

Conditions Explained

Condition Types

1. Field Conditions

2. System Conditions

3. Tenant Feature Conditions

4. Module Conditions

Operators Reference

For Text Fields

For Numeric Fields

For Date Fields

For Dropdown/Select Fields

For Boolean Fields (Checkbox/Toggle)

For Feature/Module Conditions

Condition Value Sources

1. Constant Values

2. Field References (Advanced)

Multiple Conditions

AND Logic

OR Logic

Actions Explained

Action Types Overview

SHOW Action

HIDE Action

REQUIRE Action

NOT_REQUIRE Action

ENABLE Action

DISABLE Action

SET_VALUE Action

VALIDATE Action

Conditional Logic (AND vs. OR)

AND Logic

OR Logic

Choosing Between AND and OR

Rule Examples by Use Case

Use Case 1: Progressive Disclosure

Use Case 2: Status-Based Field Requirements

Use Case 3: Automatic Date Population

Use Case 4: Risk-Based Requirements

Use Case 5: Conditional Visibility Based on Type

Use Case 6: Compliance Framework Specific Fields

Use Case 7: Feature-Based Field Display

Use Case 8: Cross-Field Validation

Use Case 9: Conditional Field Locking

Use Case 10: Multi-Condition Business Logic

Advanced Rule Patterns

Pattern 1: Cascading Rules

Pattern 2: Mutual Exclusivity

Pattern 3: Default Values with Overrides

Pattern 4: Conditional Show with Progressive Requirements

Pattern 5: Time-Based Rules

Testing and Debugging Rules

Test Your Rules

Debugging Techniques

Problem: Rule Not Firing

Problem: Wrong Action Executing

Problem: Field Not Showing/Hiding