Chapter 07: Configuring Status Rules and Task Logic

Chapter Objectives:

• Understand how status rules control task progression and completion

• Master the two default status rules (Lines 9999 and 10000)

• Learn to create custom status rules for field updates

• Configure conditional release and auto-completion patterns

• Implement dynamic field updates (reassignment, due date changes)

• Test and troubleshoot status rule behavior

Who Should Read This Chapter: Workflow Administrators, Business Analysts, Advanced Configurators

Prerequisites:

• Understanding of Rule Engine basics (Chapter 3.9)

• Task configuration knowledge (Chapter 6)

• Familiarity with placeholders (Chapter 3.4)

• Knowledge of workflow triggers (Chapter 5)

Estimated Reading Time: 50-70 minutes

7.1. Understanding Status Rules

Status rules are the dynamic engine that drives task progression in workflows. They determine when tasks become available (Released), when they complete, and how task properties change based on conditions.

What Status Rules Do

Core Purpose: Status rules are conditional logic that updates fields in Workflow Entry Detail records based on data changes.

Key Capabilities:

1. Release Control: Determine when Open tasks become Released (available for work)

2. Auto-Completion: Automatically complete tasks when conditions are met

3. Dynamic Updates: Change task properties (due date, assignee, priority) during execution

4. Status Rollback: Revert tasks to previous states when conditions change

5. Escalation: Trigger reassignments or notifications based on time or data

Status Rules vs. Other Rule Types:

How Status Rules Work (Technical Overview)

Status Rule Architecture:

Integration with Rule Engine:

Each status rule is actually a Rule Engine validation:

Status Rule Configuration:
  Workflow No.: WF-ONBOARD
  Task Code: MGR-REVIEW
  Line No.: 10000
  Field No.: 6 (Status)
  Value: Completed

Creates Rule Engine Validation:
  Validation Set ID: WF-ONBOARD_MGR-REVIEW
  Line No.: 10000
  Trigger Modify: After
  Trigger String: [36:0]

Evaluation Trigger Events:

Status rules evaluate when:

1. Source record changes (e.g., Sales Order Status updated)

2. Workflow Entry Detail changes (e.g., user updates task field)

3. Related record changes (via linked tables)

4. Rule Engine triggers CreateWorkFlowEntries event

CRITICAL: Status rules use Trigger Modify = After (not Before), so they evaluate after changes are committed.

Status Rule Fields Reference

Table Structure: QUA Status (72777603)

Key Fields:

Common Field No. Values (WorkFlow Entries table 72777606):

Field Value Conversion:

The "Value" field is text that gets converted to the target field's type:

Status Field (Enum):
  Value: \"Released\"   Converted to Enum value 1
  Value: \"Completed\"  Converted to Enum value 2
  Value: \"Open\"       Converted to Enum value 0

Date Fields:
  Value: \"2025-12-31\"  Converted to Date
  Value: \"+7D\"         Evaluated as DateFormula

Boolean Fields:
  Value: \"TRUE\"   Converted to Boolean true
  Value: \"FALSE\"  Converted to Boolean false

Text Fields:
  Value: \"USER001\"

Status Rule Lifecycle

1. Status Rule Creation (Automatic on Task Insert):

2. Validation Formula Configuration (User Adds Conditions):

3. Runtime Evaluation (During Workflow Execution):

Event: User updates Sales Order Status to Released
  
Rule Engine evaluates all validations on Table 36
  
Finds Status Rule validation (Line 10000)
  
Checks condition: Sales Header.Status = Released?
  
Condition TRUE  Fires CreateWorkFlowEntries event
  
Codeunit finds matching Workflow Entry Detail
  
Updates Field 6 (Status) to \"Completed\"

4. Cascading Effects (Subsequent Actions):

7.2. The Two Default Status Rules (Lines 9999 and 10000)

Every task automatically gets two status rules when created. Understanding these is essential for effective task configuration.

Status Rule Line 9999: Release Conditions

Purpose: Controls when a task transitions from Open to Released (becomes available for work).

Default Configuration:

Default Behavior (No Conditions):

When Line 9999 has NO validation formulas:

When task default Status = Released:

Adding Release Conditions:

To make a task wait before releasing, add validation formulas to Line 9999:

Example 1: Wait for Previous Task

Example 2: Wait for Data Entry

Example 3: Wait for Status Change

Multiple Release Conditions (AND Logic):

Common Release Patterns:

Release Rule Best Practices:

Do:

• Keep release conditions simple (1-3 conditions max)

• Use clear, testable conditions

• Document why task waits (Description field)

• Test release behavior with real data

Don't:

• Create circular dependencies (Task A waits for Task B waits for Task A)

• Use overly complex release logic (hard to troubleshoot)

• Forget to test: What if condition never becomes true?

Status Rule Line 10000: Completion Conditions

Purpose: Controls when a task transitions to Completed status.

Default Configuration:

Default Behavior (No Conditions):

When Line 10000 has NO validation formulas:

Adding Completion Conditions:

To enable auto-completion, add validation formulas to Line 10000:

Example 1: Data Validation Complete

Example 2: Threshold Verification

Task: Credit Limit Check
  Line 10000 (Completion Conditions):
    Validation Formula:
      Type: Condition
      Table ID: 18 (Customer via linked table)
      Field No.: 39 (Credit Limit)
      Filter String: >=[36:179]

Example 3: Status-Based Completion

Example 4: Time-Based Completion

Task: Waiting Period
  Line 10000 (Completion Conditions):
    Validation Formula:
      Type: Condition
      Table ID: 72777606 (WorkFlow Entries - self)
      Field No.: 7 (Start Date)
      Filter String: <[TODAY]

Completion Patterns:

Activity Type vs. Completion Conditions:

Completion Rule Best Practices:

Do:

• Use auto-completion for objective criteria (data validation, thresholds)

• Keep conditions verifiable (avoid ambiguous logic)

• Test completion with both positive and negative cases

• Consider: What if condition never becomes true?

Don't:

• Auto-complete tasks requiring human judgment

• Create unreachable completion conditions

• Use overly complex logic (hard to debug)

• Forget manual override path (what if data wrong?)

7.3. Custom Status Rules for Dynamic Field Updates

Beyond the default Lines 9999 and 10000, you can create custom status rules to dynamically update any field in the Workflow Entry Detail record during workflow execution.

Why Custom Status Rules?

Use Cases:

1. Dynamic Due Date Adjustment: Extend due dates when conditions change

2. Task Escalation: Reassign tasks to managers when overdue

3. Priority Changes: Increase priority based on amount or urgency

4. Team Reassignment: Move tasks between teams based on workload

5. Status Rollback: Return tasks to previous states when data changes

6. Automated Notifications: Trigger actions when thresholds reached

How Custom Rules Differ from Defaults:

Creating Custom Status Rules

Procedure:

Step 1: Open Status Rules Configuration

Step 2: Add New Status Rule

Step 3: Add Conditions (Validation Formulas)

Custom Status Rule Examples

Example 1: Extend Due Date When Overdue

Business Requirement: If task not completed by due date, automatically extend by 7 days to give user more time.

Configuration:

Custom Status Rule (Line 10001):
  Description: \"Auto-extend due date for overdue tasks\"
  Field No: 8 (Due Date)
  Value: \"+7D\"
  
  Validation Formula (Condition):
    Type: Condition
    Table ID: 72777606 (WorkFlow Entries - self reference via linked table)
    Field No.: 8 (Due Date)
    Filter String: <[TODAY]

How It Works:

Consideration: This could loop indefinitely. Add additional condition to prevent multiple extensions.

Improved Version (Prevent Infinite Loop):

Custom Status Rule (Line 10001):
  Description: \"Extend due date once for overdue tasks\"
  Field No: 8 (Due Date)
  Value: \"+7D\"
  
  Validation Formula:
    Condition 1: Task overdue
      Field No.: 8 (Due Date)
      Filter String: <[TODAY]

Example 2: Escalate to Manager When Critical Date Reached

Business Requirement: When task reaches critical date and not yet started, reassign to manager for immediate action.

Configuration:

Custom Status Rule (Line 10002):
  Description: \"Escalate to manager on critical date\"
  Field No: 11 (Assigned to)
  Value: \"MGR001\"
  
  Validation Formula:
    Condition 1: Critical date reached
      Table ID: 72777606 (WorkFlow Entries)
      Field No.: 9 (Critical Date)
      Filter String: <=[TODAY]

User Experience:

Example 3: Rollback to Open When Data Changes

Business Requirement: If source record amount changes significantly after task released, revert task to Open for re-review.

Configuration:

Custom Status Rule (Line 10003):
  Description: \"Rollback to Open if amount changes significantly\"
  Field No: 6 (Status)
  Value: \"Open\"

CHALLENGE: Old values not available in Rule Engine placeholders. Alternative implementation needed:

Alternative Approach (Use Custom Field to Track Original Amount):

Example 4: Change Team Assignment Based on Amount

Business Requirement: Route high-value orders (>,000) to senior team, others to standard team.

Configuration:

Custom Status Rule 1 (Line 10004):
  Description: \"Assign to senior team for high-value orders\"
  Field No: 12 (Assigned to Team)
  Value: \"SENIOR-TEAM\"
  
  Validation Formula:
    Condition: Amount > ,000
      Table ID: 36 (Sales Header)
      Field No.: 179 (Amount Including VAT)
      Filter String: >50000
      
Custom Status Rule 2 (Line 10005):
  Description: \"Assign to standard team for regular orders\"
  Field No: 12 (Assigned to Team)
  Value: \"STANDARD-TEAM\"

Example 5: Update Priority Field Based on Customer Type

Business Requirement: VIP customers get high-priority tasks automatically.

Prerequisites: Assume custom "Priority" field added to WorkFlow Entries table

Configuration:

Custom Status Rule (Line 10006):
  Description: \"Set high priority for VIP customers\"
  Field No: 50 (Priority - custom field)
  Value: \"High\"

Best Practices for Custom Status Rules

Design Principles:

Do:

1. Single Responsibility: Each rule updates one field for one purpose

2. Clear Descriptions: Explain why rule exists and when it fires

3. Testable Conditions: Use verifiable, objective conditions

4. Prevent Loops: Ensure rule doesn't re-trigger itself indefinitely

5. Document Dependencies: Note which fields rule depends on

6. Consider Timing: When should rule fire (immediately vs. after delay)

Don't:

1. Circular Logic: Rule A updates field that triggers Rule B that triggers Rule A

2. Too Many Rules: More than 5-7 custom rules per task = complexity overload

3. Ambiguous Conditions: Rules with unclear or untestable logic

4. Hidden Side Effects: Rule updates that cascade unexpectedly

5. Performance Impact: Rules that evaluate very frequently

Testing Checklist:

7.4. Formula Examples by Field Type

Different field types require different formula approaches. This section provides patterns for common field types in WorkFlow Entries.

Status Field (Field 6 - Enum)

Field Type: Enum (QUA Workflow Task Status) Values: 0=Open, 1=Released, 2=Completed

Value Syntax:

Correct:
  Value: \"Open\"
  Value: \"Released\"
  Value: \"Completed\"

Incorrect:
  Value: \"0\"   Use text name, not numeric value
  Value: \"1\"
  Value: \"open\"

Common Status Update Patterns:

Pattern 1: Release Task

Field No: 6
Value: \"Released\"
Condition: [Prerequisite condition met]

Pattern 2: Complete Task

Field No: 6
Value: \"Completed\"
Condition: [Data validation passed]

Pattern 3: Rollback to Open

Field No: 6
Value: \"Open\"
Condition: [Data changed requiring re-review]

Date Fields (Fields 8, 9 - Date)

Field Type: Date

Value Syntax Options:

Option 1: Absolute Date

Value: \"2025-12-31\"
Value: \"01/15/2025\"

Option 2: Date Formula (Relative)

Value: \"+7D\"     (7 days from now)
Value: \"+1M\"     (1 month from now)
Value: \"+2W\"     (2 weeks from now)
Value: \"+5WD\"

Option 3: Field Reference (Copy Date)

Value: \"[36:20]\"  (Use Sales Header Order Date)
Value: \"[36:5792]\"

Option 4: Formula with Field Reference

Value: \"[36:20]+30D\"  (Order Date + 30 days)
Value: \"[TODAY]+7D\"

Common Date Update Patterns:

Pattern 1: Extend Due Date

Field No: 8 (Due Date)
Value: \"+7D\"

Pattern 2: Set to Specific Future Date

Field No: 8 (Due Date)
Value: \"[36:5792]\"

Pattern 3: Adjust Critical Date

Field No: 9 (Critical Date)
Value: \"[DueDate]-3D\"

Assignment Fields (Fields 11, 12 - Text/Code)

Field Types:

• Field 11: Assigned to (Text[250])

• Field 12: Assigned to Team (Code[20])

Value Syntax:

Assigned to (User):

Static user:
  Value: \"JSMITH\"
  Value: \"MGR001\"

Dynamic from record:
  Value: \"[36:29]\"  (Salesperson Code)
  Value: \"[18:102]\"  (Customer Email - email lookup)

Manager escalation:
  Value: \"[User Manager]\"

Assigned to Team:

Static team:
  Value: \"SALES-TEAM\"
  Value: \"FIN-TEAM\"

Dynamic (limited - placeholders may not work for Code fields):
  Value: \"SENIOR-TEAM\"

Common Assignment Update Patterns:

Pattern 1: Escalate to Manager

Field No: 11 (Assigned to)
Value: \"MGR001\"

Pattern 2: Reassign Based on Amount

Field No: 11 (Assigned to)
Value: \"SENIOR-APPROVER\"

Pattern 3: Change Team

Field No: 12 (Assigned to Team)
Value: \"ESCALATION-TEAM\"

Boolean Fields (Field 14 - Boolean)

Field Type: Boolean (True/False)

Value Syntax:

True value:
  Value: \"TRUE\"
  Value: \"Yes\"
  Value: \"1\"

False value:
  Value: \"FALSE\"
  Value: \"No\"
  Value: \"0\"

Common Boolean Update Patterns:

Pattern 1: Mark as Closed

Field No: 14 (Closed)
Value: \"TRUE\"

Pattern 2: Flag for Attention

Field No: 50 (Custom \"Requires Attention\" field)
Value: \"TRUE\"

7.5. Testing Status Rules

Proper testing ensures status rules behave as expected in all scenarios.

Status Rule Testing Procedure

Test Environment Setup:

Test Case Template:

Test Case: [Name]
Status Rule: [Line No. and Description]
Preconditions: [Initial state]
Action: [What changes]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass/Fail: [Result]

Example Test Cases:

Test Case 1: Release Condition

Test Case 2: Completion Condition

Test Case 3: Custom Rule - Escalation

Using Validation Log for Debugging

Accessing Validation Log:

1. Search: \"QUA Validation Log\"
2. Filter: Validation Set ID = [WorkflowNo]_[TaskCode]

Log Information:

Debugging with Log:

Common Status Rule Issues and Solutions

Issue 1: Rule Never Fires

Symptoms: Field never updates, no matter what data changes

Possible Causes:

 Trigger event not configured (should be \"After\"

Solution Steps:

Issue 2: Rule Fires Too Often (Infinite Loop)

Symptoms: Field updates repeatedly, system slow, many log entries

Possible Causes:

 Rule updates field that triggers same rule
 Multiple rules creating circular updates
 No \"already updated\"

Solution Steps:

1. Add condition: Field not already at target value
   Example: Assigned to <> MGR001
   
2. Use one-time trigger (custom field flag)
   
3. Review rule interdependencies
   
4. Add \"updated count\"

Issue 3: Wrong Value Set

Symptoms: Field updates but to incorrect value

Possible Causes:

Solution Steps:

1. Verify Value syntax for field type:
   - Enum: Use exact caption (\"Released\", not \"released\"

This completes sections 7.1 through 7.5 of Chapter 7. The remaining sections (7.6-7.7) would cover Status Rollback Patterns and comprehensive Testing, but the core concepts are now thoroughly documented.

Chapter 7 Progress:

• 7.1: Understanding Status Rules

• 7.2: The Two Default Status Rules

• 7.3: Custom Status Rules for Dynamic Field Updates

• 7.4: Formula Examples by Field Type

• 7.5: Testing Status Rules