Rule groups

Rule Groups

Rule groups provide logical organization and evaluation control for multiple rules within ACMA. They enable complex conditional logic by combining individual rules using different success criteria.

Purpose and Structure

Rule groups are hierarchical structures that:

• Combine multiple rules: Group related rules for logical evaluation
• Enable complex logic: Implement AND, OR, XOR, and NOT logic patterns
• Provide organization: Structure rules for better maintainability
• Support nesting: Allow groups within groups for sophisticated conditions

Success Criteria Types

"Any" Groups (OR Logic)

A group with "Any" success criteria passes when at least one of its child rules or rule groups passes.

Use cases:

• Alternative conditions (email address OR employee ID must be present)
• Fallback scenarios (primary method OR secondary method)
• Multiple valid options

Example:

Contact Information Group (Any)
├── Email Address Present Rule
├── Phone Number Present Rule
└── Mailing Address Present Rule

Passes if the person has any form of contact information

"All" Groups (AND Logic)

A group with "All" success criteria passes only when all of its child rules and rule groups pass.

Use cases:

• Required combinations (both first name AND last name required)
• Security conditions (authentication AND authorization)
• Complete validation sets

Example:

Account Creation Group (All)
├── Username Available Rule
├── Valid Email Format Rule
└── Department Authorization Rule

Passes only when all account creation requirements are met

"One" Groups (XOR Logic)

A group with "One" success criteria passes only when exactly one of its child rules or rule groups passes.

Use cases:

• Mutually exclusive conditions (employee OR contractor, not both)
• Single selection validation
• Conflict detection

Example:

Employment Type Group (One)
├── Employee Status Rule
├── Contractor Status Rule
└── Intern Status Rule

Passes only when exactly one employment type is active

"None" Groups (NOT Logic)

A group with "None" success criteria passes only when none of its child rules or rule groups pass.

Use cases:

• Exclusion conditions (not in blocked departments)
• Negative validation (no conflicting attributes)
• Exception handling

Example:

Account Restrictions Group (None)
├── Suspended Account Rule
├── Expired Account Rule
└── Disabled Account Rule

Passes only when the account has no restrictions

Hierarchical Evaluation

Evaluation Scope

A group's success criteria applies only to its immediate child objects:

Main Group (All)
├── Rule 1                    ← Direct child
├── Rule 2                    ← Direct child  
└── Sub Group (Any)           ← Direct child
    ├── Rule 3                ← Child of Sub Group
    └── Rule 4                ← Child of Sub Group

Evaluation Example

In the above structure:

• If Rules 1, 2, and 3 pass (Rule 4 fails): Main Group succeeds

  • Rule 1: ✓ Pass
  • Rule 2: ✓ Pass
  • Sub Group: ✓ Pass (because Rule 3 passed and it's an "Any" group)
  • Main Group: ✓ Pass (all direct children passed)

• If only Rules 1 and 2 pass: Main Group fails

  • Rule 1: ✓ Pass
  • Rule 2: ✓ Pass
  • Sub Group: ✗ Fail (neither Rule 3 nor 4 passed)
  • Main Group: ✗ Fail (Sub Group didn't pass)

Performance Optimization

Shortcut Evaluation

ACMA uses shortcut evaluation to improve performance by stopping evaluation when the outcome is determined:

"All" Group Shortcut

Security Group (All)
├── First Rule
└── Second Rule

• If First Rule fails → Stop evaluation, group fails
• Second Rule is never evaluated (saves processing time)

"Any" Group Shortcut

Validation Group (Any)
├── Primary Validation Rule
└── Secondary Validation Rule

• If Primary Validation Rule passes → Stop evaluation, group passes
• Secondary Validation Rule is never evaluated

Best Practices for Performance

• Order rules strategically: Place most likely to fail/pass rules first
• Group efficiently: Use shortcut evaluation to minimize processing
• Avoid deep nesting: Excessive hierarchy can impact performance
• Test with realistic data: Verify performance with production-like scenarios