Chapter 03: Core Concepts and Terminology

Before diving into workflow configuration, it's essential to understand the fundamental concepts, terminology, and architecture that power QUALIA Workflow. This chapter explains how workflows work "under the hood" and introduces the key terms you'll encounter throughout this manual.

What You'll Learn:

• How QUALIA Workflow integrates with the Rule Engine

• Essential workflow terminology in business-friendly language

• The complete workflow lifecycle from configuration to completion

• How placeholders enable dynamic behavior

• Different activity types and when to use each

• Status transitions and task progression logic

• Team-based assignment strategies

• Date calculation patterns

Time Required: 30-40 minutes reading

Who Should Read This:

• Everyone should read sections 3.1-3.3 (architecture, terminology, lifecycle)

• Administrators should read all sections

• End users can skim sections 3.4-3.9 and refer back when needed

• Power users should read thoroughly for advanced configuration

3.1. Workflow Architecture Overview

QUALIA Workflow is not a standalone system - it's built as an extension layer on top of the QUALIA Rule Engine. Understanding this architectural relationship is crucial for effective workflow design and troubleshooting.

🏗️ The Foundation: Rule Engine

The QUALIA Rule Engine provides:

• Event subscription system: Monitors Business Central table changes (Insert, Modify, Delete, Rename)

• Validation framework: Evaluates business rules when events occur

• Scenario filtering: Determines which records should trigger rules (inclusion filters)

• Action execution: Performs actions when validation conditions met

• Formula engine: Evaluates complex expressions and calculations

🔗 For complete Rule Engine architecture details, see Rule Engine Technical Design Document Section 2.

📦 The Extension: Workflow Layer

QUALIA Workflow extends the Rule Engine by adding:

• Task management: Creates multi-step processes with defined sequences

• Assignment logic: Routes work to specific users or teams

• Status tracking: Manages task lifecycle (Open → Released → Completed)

• Activity types: Provides specialized behaviors (Manual, Interaction, Conditional, Approval)

• Team collaboration: Enables shared workload distribution

• Date management: Calculates due dates and critical dates

• UI enhancements: Provides Role Center cues, FactBoxes, and task lists

🔄 How They Work Together

🎯 Key Architectural Principle: Every Workflow Component Creates Rule Engine Objects

This is the most important concept to understand:

Workflow Setup creates Rule Engine Validation Set

• Workflow No. "SO-APPROVAL-001" creates Validation Set "SO-APPROVAL-001"

• Workflow Setup fields map to Validation Set fields

Initiated By links to Rule Engine Validation Set

• Each "Initiated By" rule points to a Validation Set

• That Validation Set contains Scenarios (trigger conditions)

• Scenarios use inclusion filter logic (must ALL match)

Workflow Tasks create Rule Engine Validations

• Each task creates a Validation within the Validation Set

• Task Code becomes Validation Code

• Task formula configuration uses Rule Engine formula syntax

Status Rules create Rule Engine Validation Lines

• Line 9999 (Release condition) = Validation Line with Status field formula

• Line 10000 (Completion condition) = Validation Line with Status field formula

• Custom status rules = Additional Validation Lines

The Implication:

When you configure workflows, you're actually configuring Rule Engine objects through a specialized UI. This means:

• ✅ All Rule Engine formula syntax works in workflows

• ✅ All Rule Engine placeholders work in workflows

• ✅ All Rule Engine operators work in workflows

• ✅ Validation Log shows workflow trigger evaluation

• ✅ You can view/edit the underlying Rule Engine objects directly

⚠️ WARNING: While you CAN edit the underlying Rule Engine Validation Sets directly, it's recommended to use the Workflow Setup pages. Direct edits may cause synchronization issues or unexpected behavior.

📊 Transaction-Level Processing

Workflows execute within Business Central transaction boundaries:

Synchronous Execution:

• Workflow instance creation happens DURING the BC transaction

• If workflow creation fails, the entire transaction rolls back

• This ensures data consistency (no "orphan" records)

Asynchronous Task Processing:

• Task execution happens AFTER transaction commits

• Users process tasks at their own pace

• Status updates are separate transactions

Example:

🔌 Integration Event Subscription Pattern

Technical detail for advanced users and developers:

QUALIA Workflow subscribes to Business Central integration events:

• GlobalTriggerManagement.OnAfterApplyRules: Notified when Rule Engine completes validation

• Table-specific events: Can subscribe to individual table events for custom logic

This event-driven design means:

• Workflows activate automatically without custom code

• Multiple workflows can trigger from same event

• Minimal performance impact (only evaluates when events occur)

• Standard BC upgrade path preserved

3.2. Essential Terminology

Understanding workflow terminology is essential for configuration and communication. This glossary defines key terms in business-friendly language.

📖 Core Workflow Concepts

Workflow (Workflow Setup)

• Definition: A template or configuration that defines a multi-step business process

• Technical: A record in the Workflow Setup table

• Example: "Customer Onboarding Process", "Sales Order Approval", "Vendor Setup Review"

• Analogy: Like a recipe - it defines the steps, ingredients, and instructions, but isn't the actual meal

• Storage: One record per workflow type

• Identification: Workflow No. field (e.g., "CUST-ONBOARD-001")

Workflow Instance (Workflow Entry Header)

• Definition: A specific execution of a workflow template

• Technical: A header record in Workflow Entries table (Detailed Entry No. = 0)

• Example: The Customer Onboarding workflow triggered when customer "C00010" was created

• Analogy: Like a meal cooked from a recipe - one instance of following the recipe

• Storage: One header entry per triggered workflow

• Identification: Entry No. field (e.g., Entry No. = 1001)

• Lifecycle: Created when workflow triggers → Active during execution → Completed when all tasks done

Task (Workflow Task Configuration)

• Definition: A step in the workflow that requires action or validation

• Technical: A task line in the Workflow Setup Tasks tab

• Example: "Manager Approval", "Verify Contact Information", "Set Up Defaults"

• Analogy: Like a step in a recipe - "Chop onions", "Sauté for 5 minutes", "Add spices"

• Storage: Multiple task configurations per workflow

• Identification: Task Code field (e.g., "TASK-001", "REVIEW", "APPROVE")

Task Instance (Workflow Entry Detail)

• Definition: A specific task created when workflow triggers

• Technical: A detail record in Workflow Entries table (Detailed Entry No. > 0)

• Example: The "Manager Approval" task assigned to user JSMITH for Sales Order SO-12345

• Analogy: Like actually chopping the onions for tonight's dinner

• Storage: One detail entry per task per workflow instance

• Identification: Entry No. + Detailed Entry No. (e.g., Entry No. 1001, Detailed Entry No. 1)

• Lifecycle: Created with workflow instance → Released when eligible → Completed when processed

Header Entry

• Definition: The parent record of a workflow instance

• Technical: Workflow Entry with Detailed Entry No. = 0

• Purpose: Groups all tasks for one workflow execution

• Contains: Workflow No., Source Table, Source Record ID, Overall Status

• Example: Entry No. 1001, Detailed Entry No. 0, Code = "SO-APPROVAL-001"

Detail Entry

• Definition: A child record representing one task within a workflow instance

• Technical: Workflow Entry with Detailed Entry No. > 0

• Purpose: Tracks individual task status and assignment

• Contains: Task Code, Assigned User, Status, Dates, Activity Type

• Example: Entry No. 1001, Detailed Entry No. 1, Code = "TASK-001"

• Relationship: Multiple detail entries belong to one header entry

🎯 Configuration Concepts

Initiated By

• Definition: The trigger conditions that start a workflow

• Technical: Links to Rule Engine Validation Sets with Scenarios

• Purpose: Answers "When should this workflow start?"

• Configuration: List of Validation Set codes on Initiated By tab

• Example: Workflow triggers when Sales Order Amount > $50,000

• Logic: If ANY linked validation matches, workflow triggers (OR relationship)

Status Rules

• Definition: Formulas that control when tasks transition between statuses

• Technical: Validation Lines targeting the Status field (Field No. 6)

• Purpose: Implements conditional task progression logic

• Auto-Created: System creates Line 9999 (Release) and Line 10000 (Completion)

• Example: "Release task when previous task completed", "Complete task when data valid"

Precedence Rules

• Definition: Dependencies between tasks that control execution order

• Technical: Relationships defined in Task Rules > Precedence subpage

• Purpose: Enforces "Task B cannot start until Task A completes"

• Configuration: Source Task Code → Target Task Code relationships

• Example: Finance Approval task waits for Manager Approval task

Activity Type

• Definition: Classification that determines how a task behaves and completes

• Values: Conditional (0), Interaction (1), Manual (2), Job Queue (3), Approval Workflow (4)

• Purpose: Controls task completion logic and UI behavior

• Example: Manual = user clicks Process; Conditional = completes automatically via formula

Assignment

• Definition: Identifies who is responsible for completing a task

• Methods:

  • Fixed User (direct User ID: "JSMITH")

  • Team (Team Code: "FINANCE-TEAM")

  • Dynamic Formula (placeholder: [36:29] = Salesperson Code from Sales Header)

  • Combined (User + Team for backup)

• Purpose: Routes work to appropriate person or group

• Resolution: System evaluates at workflow creation time (for formulas) or shows as-is

📅 Date and Time Concepts

Due Date

• Definition: Target completion date for a task

• Purpose: Sets expectations for task completion timing

• Format: Text[250] field supporting formulas

• Examples: +2D (2 days from creation), [18:54]+30D (Customer Due Date + 30 days), 12/31/2025

• Visibility: Shows in task lists, Role Center cues, overdue calculations

Critical Date

• Definition: Escalation threshold before Due Date

• Purpose: Early warning system for approaching deadlines

• Typical Usage: Critical Date < Due Date (e.g., Critical = +1D, Due = +2D)

• Role Center Impact: Tasks past Critical Date show in "Critical Tasks" cue

• Example: Critical Date = +23H (23 hours), Due Date = +2D (2 days)

Date Formula

• Definition: Expression that calculates a date dynamically

• Syntax: BC DateFormula format (+/-number + period code)

• Period Codes: D (days), WD (work days), W (weeks), M (months), Q (quarters), Y (years), C (current)

• Examples: +30D, +1M, +1Y, -5D, +5WD, +1CW

• Processing: BC CalculateDate function evaluates at runtime

👥 Team and Assignment Concepts

Team

• Definition: A group of users who share task assignments

• Purpose: Enables workload distribution and flexible assignment

• Configuration: Team Code with multiple User IDs as members

• Example: "FINANCE-TEAM" with members JSMITH, KJONES, MDAVIS

• Task Assignment: Any team member can self-assign and process

Team Member

• Definition: A user who belongs to one or more teams

• Configuration: User ID linked to Team Code in Team Members table

• Capabilities: View team tasks, self-assign tasks, process assigned tasks

• Example: User JSMITH is member of teams "FINANCE-TEAM" and "AUDIT-TEAM"

Self-Assignment

• Definition: Process where team member claims a team-assigned task

• Workflow: Task assigned to team → Member views task → Member assigns to self → Member processes

• Purpose: Enables workload balancing and flexible work distribution

• UI: "Assign to Me" action on team tasks

3.3. The Complete Workflow Lifecycle

Every workflow instance progresses through a predictable lifecycle from configuration to completion. Understanding these phases helps you design effective workflows and troubleshoot issues.

🔧 Phase 1: Configuration

Activities:

• Administrator creates Workflow Setup record

• Configures General tab (No., Description, Table, Dates)

• Links to Rule Engine Validation Sets (Initiated By)

• Defines Tasks (Code, Description, Activity Type, Assignment, Dates)

• Configures Status Rules (Release and Completion conditions)

• Sets up Precedence Rules (task dependencies)

• Tests configuration in sandbox environment

Status: Workflow exists but is disabled (Enabled checkbox = unchecked)

Duration: Hours to days, depending on complexity

Best Practice: Always configure and test with Enabled = unchecked first.

✅ Phase 2: Activation

Activities:

• Administrator verifies configuration complete

• Checks all tasks have proper assignment

• Confirms trigger conditions (Initiated By) are correct

• Reviews status rules and precedence

• Enables workflow (Enabled checkbox = checked)

• Monitors first few executions closely

Status: Workflow is active and listening for trigger events

Duration: Instantaneous (checkbox change)

Validation Checks:

• Start Date <= Current Date (if specified)

• End Date >= Current Date (if specified)

• At least one Initiated By rule exists

• At least one Task exists

• All required fields populated

⚠️ WARNING: Enabling a workflow immediately activates it. New records matching trigger conditions will create workflow instances. Monitor closely after enabling.

🎯 Phase 3: Triggering

Activities:

• User or process creates/modifies a BC record

• BC fires table event (OnInsert, OnModify, OnDelete, OnRename)

• Rule Engine GlobalTriggerManagement intercepts event

• Rule Engine evaluates linked Validation Sets

• Rule Engine checks Scenarios (inclusion filters)

• If ALL scenarios match → Validation qualifies

• Validation linked to workflow → Workflow triggers

Status: Trigger evaluation in progress

Duration: Milliseconds (typically < 10ms per validation)

CODE-VERIFIED Logic:

📋 NOTE: This counter-intuitive return logic (FALSE = match) is intentional in the Rule Engine. Scenarios are INCLUSION filters - they define what SHOULD trigger, not what shouldn't.

🔗 For detailed explanation of CheckConditions logic, see Rule Engine Technical Design Document Section 2.4.

📦 Phase 4: Instance Creation

Activities:

• Workflow Layer receives notification from Rule Engine

• System creates Header Entry (Detailed Entry No. = 0)

• System creates Detail Entries (one per task, Detailed Entry No. = 1, 2, 3...)

• System evaluates assignment formulas (placeholders)

• System calculates due dates and critical dates

• System applies initial status rules

• System logs creation in Workflow Entries table

Status: Workflow instance exists, tasks created

Duration: Milliseconds (typically < 100ms per workflow)

Header Entry Created:

Detail Entries Created:

⚡ Phase 5: Task Execution

Activities:

• Assigned users see tasks in Role Center cues

• Users open Workflow Entries page

• Users filter to their assigned tasks

• Users review "What To DO" FactBox

• Users click "Show Record" to view source data

• Users perform required actions

• Users click "Process" to complete tasks (Manual/Interaction)

• OR system auto-completes tasks (Conditional)

Status: Tasks progress from Open → Released → Completed

Duration: Minutes to days, depending on human response time

By Activity Type:

Manual Activity Processing:

1. User opens task

2. User reviews source record

3. User performs required action (approval, data entry, verification)

4. User clicks Process button

5. System prompts confirmation

6. System marks task Status = Completed

7. Status rules evaluate (may release next task)

Interaction Activity Processing:

1. User opens task

2. User clicks Process button

3. BC Interaction wizard opens

4. User fills in interaction details (type, description, date, notes)

5. User completes wizard

6. System creates Interaction Log entry

7. System creates Segment Line (if configured)

8. System marks task Status = Completed

Conditional Activity Processing:

1. System monitors source record changes

2. Status rule formula evaluates continuously

3. When formula evaluates to TRUE → Status = Completed

4. No user interaction required

5. Useful for data validation gates

Approval Workflow Activity Processing:

1. User opens task

2. Task may lock source record (prevents edits)

3. User uses BC approval workflow UI

4. Approval process completes

5. OnDatabaseModify event fires

6. System marks task Status = Completed

🔄 Phase 6: Status Transitions

Activities:

• Status rules evaluate continuously (or on events)

• Rules check conditions (formulas evaluate)

• When release condition TRUE → Status changes Open → Released

• When completion condition TRUE → Status changes Released → Completed

• Status changes trigger dependent status rules

• Precedence rules may release downstream tasks

Status: Tasks advance through lifecycle automatically or via user action

Duration: Instantaneous (rule evaluation typically < 10ms)

Transition Patterns:

Auto-Release Pattern:

Conditional Release Pattern:

Configuration: Line 9999 formula = [Previous task completed]

User-Driven Completion:

Auto-Completion Pattern:

Configuration: Line 10000 formula = [Data quality check]

✅ Phase 7: Workflow Closure

Activities:

• All tasks reach Status = Completed

• System evaluates workflow-level completion

• Header Entry Status updates to Completed

• Workflow removed from active lists

• Workflow appears in completed reports

• Audit trail preserved

Status: Workflow instance completed

Duration: Instantaneous (status update)

Completion Criteria:

A workflow instance completes when:

1. ALL detail entries have Status = Completed

2. No errors or exceptions exist

3. All required actions executed

Post-Completion:

• Instance remains in Workflow Entries table (historical record)

• Users can view completed workflows (filter Status = Completed)

• Administrators can analyze completion time and performance

• Audit trail available for compliance

Archival:

💡 TIP: Periodically archive completed workflows to maintain performance:

• Export completed workflow data

• Delete workflows older than retention period (e.g., > 1 year)

• Maintain audit trail in archive system

• Document archival process for compliance

3.4. Understanding Placeholders (with Rule Engine Cross-Reference)

Placeholders are the secret to dynamic, intelligent workflows. They allow workflows to read data from Business Central records and use it in calculations, assignments, descriptions, and logic.

📌 What Are Placeholders?

A placeholder is a reference to a specific field in a specific Business Central table. When the workflow evaluates the placeholder, it reads the current value of that field and uses it in the workflow.

Syntax: [TableNumber:FieldNumber]

Example: [18:2] means "Read Field 2 from Table 18"

• Table 18 = Customer table

• Field 2 = Name field

• Result: Reads the customer's name

Why Placeholders Matter:

Without placeholders, workflows would be static:

• ❌ Every task assigned to same person

• ❌ Same due date for every instance

• ❌ Generic descriptions

With placeholders, workflows are dynamic:

• ✅ Tasks assigned based on record data

• ✅ Due dates calculated from field values

• ✅ Descriptions include specific information

• ✅ Logic adapts to each instance

🔍 Where Placeholders Are Used in Workflows

1. Task Descriptions

Make task descriptions specific to each instance:

Static Description:
  "Review customer information"

Dynamic Description with Placeholder:
  "Review customer information for [18:2]

2. Assigned To Field

Route tasks based on record data:

Static Assignment:
  Assigned to: JSMITH

Dynamic Assignment with Placeholder:
  Assigned to: [36:29]

3. Due Date / Critical Date

Calculate deadlines based on record dates:

Static Due Date:
  Due Date: +2D (always 2 days from creation)

Dynamic Due Date with Placeholder:
  Due Date: [18:54]

4. Contact No. Field (Interaction Activities)

Identify the contact person dynamically:

Static Contact:
  Contact No.: CNT00001

Dynamic Contact with Placeholder:
  Contact No.: [18:5052]

5. Status Rule Formulas

Make task progression conditional on data:

📋 NOTE: Status rules reference Rule Engine Validation Sets, not direct formulas. You cannot write [18:39]>0 directly in a workflow field. Instead, create a validation set with the condition logic, then link that validation set to the status rule line.

🔗 See Rule Engine User Manual Chapter 5: Creating Validations for detailed instructions on building condition logic.

💡 Common Workflow Placeholder Patterns

⚠️ CRITICAL UNDERSTANDING: Placeholder Usage vs. Rule Engine Configuration

Placeholders can be used in two ways:

1. Direct Field Reference (Simple placeholders): [TableNo:FieldNo] in assignment, descriptions, dates

2. Rule Engine Configuration (Logic and comparisons): Must create Validation Sets with Scenarios/Conditions

Direct Usage (Supported in Workflow Fields):

• ✅ Assigned to: [36:29] (reads Salesperson Code)

• ✅ Due Date: [36:73]+2D (reads Shipment Date, adds 2 days)

• ✅ Description: "Review order [36:3]" (reads Order No.)

• ✅ Contact No.: [18:5052] (reads Primary Contact)

Rule Engine Configuration (CANNOT write directly in workflow fields):

• ❌ Initiated By: [36:179]>50000 (comparison logic requires scenario with Filter String: >50000)

• ❌ Initiated By: Cross-table comparison (requires linked table + scenario with placeholder in Filter String)

• ❌ Status Rule: Conditional logic (requires validation set with conditions)

How to configure comparisons:

• Simple comparison: Create scenario with Filter String: >50000

• Cross-table comparison: Link table + use placeholder in Filter String: >[18:39]

• Complex logic: Multiple scenario lines or condition lines with AND/OR combinations

When you need conditional logic, follow this pattern:

1. Create Rule Engine Validation Set

2. Add Scenario lines (for triggers) or Condition lines (for actions/status)

3. Link validation set to workflow (Initiated By tab or Status Rule line)

🔗 See Rule Engine User Manual Chapter 5: Creating Business Rules for validation set configuration.

Pattern 1: Assignment to Record Owner

Use Case: Assign task to salesperson who owns the order
Placeholder: [36:29]

Pattern 2: Due Date from Record Date

Use Case: Task due based on order shipment date
Placeholder: [36:73]

Pattern 3: Task Description with Record Details

Use Case: Include customer name and order number in task
Placeholder: Review order [36:3] for customer [36:2]

Pattern 4: Conditional Logic Based on Amount

📋 NOTE: Conditional logic is configured in Rule Engine Scenarios using the Filter String field. Scenarios determine WHEN workflows trigger (Initiated By), while Conditions determine action execution.

Pattern 5: Customer Credit Check (Cross-Table Comparison)

Use Case: Trigger workflow when order amount approaches credit limit
Implementation: Rule Engine Scenario with Linked Table
Configuration:
  Step 1 - Create Validation Set: SO-CREDIT-CHECK
  
  Step 2 - Link Customer table:
    * Reference Table No.: 18 (Customer)
    * Identifier: CUST (optional)
    * Add Reference Filter:
      - Reference Field No.: 1 (Customer.No.)
      - Filter Type: Field
      - Filter Value: 2 (Sales Header.Sell-to Customer No.)
  
  Step 3 - Add Scenario line:
    * Table ID: 36 (Sales Header)
    * Field No.: 179 (Amount Including VAT)
    * Filter String: >[18:39]

⚠️ CRITICAL: To compare fields from different tables (e.g., Sales Header amount vs. Customer credit limit), you must:

1. Configure a Linked Table (Reference Table) in the validation set

2. Define how to find the related record (Reference Filters)

3. Use placeholders in the Filter String: >[18:39] compares to Customer Credit Limit

4. The placeholder [18:39] resolves to the linked customer's credit limit value

See Rule Engine User Manual Section 6: Using Linked Tables and Section 25.6: Cross-Table Placeholders for detailed configuration steps.

Pattern 6: Related Table Lookup

Use Case: Assign to customer's salesperson
Placeholder: [18:29]

Pattern 7: Date Calculation with Business Days

Use Case: Due date is 5 working days after order date
Placeholder: [36:20]

Pattern 8: System Date Reference

🔗 Complete Placeholder Reference

For comprehensive placeholder documentation, see:

🔗 Rule Engine User Manual Section 25: Placeholder Reference Guide

That section covers:

• Complete table and field ID reference

• All supported placeholder syntax

• Aggregate functions (SUM, COUNT, AVG, MIN, MAX)

• Mathematical operators (+, -, *, /, ^, MOD)

• Comparison operators (=, <>, <, >, <=, >=)

• Logical operators (AND, OR, NOT)

• String operators (&, CONTAINS, STARTSWITH, ENDSWITH)

• Date/time functions

• Type conversion functions

• Troubleshooting placeholder errors

📋 NOTE: This workflow manual focuses on workflow-specific placeholder usage. For formula syntax details, operators, and advanced techniques, always refer to the Rule Engine manual to avoid duplication.

🛠️ Workflow-Specific Placeholder Tips

Tip 1: Test Placeholders Before Production

Always test placeholder resolution with real data:

1. Create test workflow instance

2. Check assigned user resolved correctly

3. Verify due dates calculated as expected

4. Review task descriptions show correct values

5. Test edge cases (empty fields, zero values, null dates)

Tip 2: Handle Empty Fields Gracefully

If a placeholder references an empty field:

• Assignment placeholders: Task may be unassigned

• Date placeholders: May result in invalid date

• Description placeholders: Shows blank

💡 TIP: Use fallback patterns:

• Assign to: [36:29] (placeholder) AND fallback to team if empty

• Configure team as backup assignment method

Tip 3: Understand Table Context

Placeholders evaluate against the source record:

• Workflow on Table 18 (Customer) → [18:XX] references customer fields

• Workflow on Table 36 (Sales Header) → [36:XX] references order fields

• Related tables work: [36:2] on Sales Header gets customer name (through table relation)

Tip 4: Date Placeholder Format

Date fields must use date formula syntax:

• ✅ Correct: [18:54]+30D

• ❌ Wrong: [18:54]+30 (missing D)

• ✅ Correct: [36:73]+2D

• ❌ Wrong: [36:73]2D (missing +)

🚨 Troubleshooting Placeholders

Issue: Task Unassigned

Symptom: Assigned to field is blank
Cause: Placeholder [XX:YY]

Issue: Invalid Due Date

Issue: Description Shows [18:2] Literally

Issue: Formula Doesn't Evaluate

🔗 For advanced troubleshooting, see Rule Engine User Manual Chapter 27: Troubleshooting Guide.

3.5. Understanding Activity Types

Activity Type determines how a task behaves and what's required to complete it. Choosing the correct activity type is essential for workflow design.

Activity Type Enum Values:

• 0 = Conditional: Completes automatically when condition met

• 1 = Interaction: Creates CRM interaction log

• 2 = Manual: User clicks Process to complete

• 3 = Job Queue: (Reserved for future use)

• 4 = Approval Workflow: Integrates with BC approval system

🔄 Conditional Activities (Value 0)

Purpose:

Conditional activities complete automatically when data meets specified criteria. No user action required. Useful for validation gates and system-driven progression.

How Completion Works:

1. Task created with Status = Open or Released

2. System monitors source record and status rules

3. Status Rule Line 10000 evaluates condition (via linked Rule Engine validation)

4. When validation returns TRUE → Status = Completed

5. No user interaction needed

Configuration Requirements:

• Activity Type = 0 (Conditional)

• Status Rule Line 10000 must exist

• Line 10000 must link to Rule Engine Validation Set

• Validation Set contains condition logic (cannot write formula directly)

Use Cases:

Use Case 1: Data Quality Gate

Use Case 2: Approval Received

Use Case 3: Amount Threshold Met

Best Practices:

💡 TIP: Conditional activities are perfect for "wait for data" scenarios where you need workflow to pause until specific conditions are met. They reduce manual task overhead while maintaining process control.

⚠️ WARNING: Ensure condition can actually become TRUE. If condition is impossible (e.g., field never populated), task will never complete and workflow will be stuck.

Troubleshooting:

If conditional task never completes:

1. Check Validation Log to see if condition ever evaluates TRUE

2. Verify source record data meets condition criteria

3. Test validation set independently in Rule Engine

4. Confirm status rule line properly links to validation set

📞 Interaction Activities (Value 1)

Purpose:

Interaction activities integrate with Business Central's CRM module to log customer interactions (calls, meetings, emails). When user completes the task, BC creates an Interaction Log Entry and optionally a Segment Line.

How Completion Works:

1. User opens task in Workflow Entries

2. User clicks Process button

3. BC Interaction wizard opens

4. User fills in interaction details:

   • Interaction Type (derived from Template)

   • Date and Time

   • Description and Notes

   • Contact Person

   • Document details

5. User completes wizard

6. System creates Interaction Log Entry (Table 5065)

7. System creates Segment Line if configured (Table 5077)

8. Task Status = Completed

Configuration Requirements:

• Activity Type = 1 (Interaction)

• Template Code field must be populated (required)

• Contact No. field should be populated (recommended, can use placeholder)

• BC CRM module must be configured

• At least one Interaction Template must exist

• User must have CRM permissions

Template Code Field:

The Template Code determines:

• What type of interaction (Phone Call, Meeting, Email, etc.)

• What information the wizard requests

• Whether document attachments allowed

• Whether wizard shows specific fields

Contact No. Field:

Specifies the contact person for the interaction:

• Can be direct Contact No.: CNT00001

• Can be placeholder: [18:5052] (Customer Primary Contact)

• Can be blank (wizard prompts user to select)

Use Cases:

Use Case 1: Welcome Call to New Customer

Scenario: Sales rep must call new customer within 2 days
Configuration:
  - Activity Type: Interaction
  - Description: "Call new customer [18:2] to introduce services"
  - Template Code: WELCALL (Welcome Call template)
  - Contact No.: [18:5052] (Primary Contact placeholder)
  - Assigned to: [18:29]

Use Case 2: Follow-Up Meeting After Quote

Scenario: Schedule and log follow-up meeting after quote sent
Configuration:
  - Activity Type: Interaction
  - Description: "Schedule follow-up meeting for quote [36:3]"
  - Template Code: MEETING (Meeting template)
  - Contact No.: [36:CustomField] (Quote Contact)
  - Assigned to: [36:29] (Salesperson)
  - Due Date: [36:OrderDate]

Use Case 3: Thank You Email After Order

Scenario: Send thank you email after order ships
Configuration:
  - Activity Type: Interaction
  - Description: "Send thank you email to [36:2]"
  - Template Code: THANKYOU (Email template)
  - Contact No.: [36:ContactNo] (Order contact)
  - Assigned to: [36:29]

Interaction Wizard Walkthrough:

When user clicks Process:

1. Interaction Type Screen

   • Auto-filled from Template Code

   • Usually not editable

   • Shows icon for interaction type

2. Contact Information Screen

   • Contact No. (from task or user selects)

   • Contact name displays

   • Related customer/vendor shows

3. Details Screen

   • Date (defaults to TODAY)

   • Time (defaults to current time)

   • Description (can edit)

   • Notes (multi-line text for details)

4. Document Attachment Screen (if template allows)

   • Attach files (emails, documents, photos)

   • Link to existing BC documents

5. Completion

   • Click Finish

   • Interaction log entry created

   • Task status = Completed

Best Practices:

💡 TIP: Use descriptive Template Codes that clearly indicate purpose (WELCALL, FOLUP-QUOTE, THANKYOU-EMAIL). This makes workflow configuration and reporting clearer.

💡 TIP: Always populate Contact No. field with placeholder when possible. Having the contact pre-filled saves user time and prevents errors.

📋 NOTE: Interaction activities require BC CRM setup. If CRM module not configured, users will receive errors when processing these tasks.

CRM Integration Details:

Interaction Log Entry (Table 5065):

• Created when wizard completes

• Links to Contact

• Contains date, time, description, notes

• Shows in Contact's interaction history

• Available for segmentation and reporting

Segment Line (Table 5077):

• Optionally created based on template configuration

• Used for marketing campaign tracking

• Groups interactions for mass communication

• Can trigger additional workflows

👤 Manual Activities (Value 2)

Purpose:

Manual activities require explicit user action to complete. Most common activity type for human tasks like approvals, reviews, data entry, or verification.

How Completion Works:

1. User opens task in Workflow Entries

2. User reviews "What To DO" FactBox

3. User clicks Show Record to view source data

4. User performs required action (approval, data entry, verification)

5. User clicks Process button

6. System prompts confirmation (optional based on setup)

7. Task Status = Completed

Configuration Requirements:

• Activity Type = 2 (Manual)

• Clear, actionable Description field

• Appropriate Assigned to configuration

• Due Date for accountability

Use Cases:

Use Case 1: Manager Approval

Scenario: Manager must review and approve sales order
Configuration:
  - Activity Type: Manual
  - Description: "Review and approve sales order [36:3] for [36:2]

Use Case 2: Data Verification

Scenario: Operations must verify shipping address before shipment
Configuration:
  - Activity Type: Manual
  - Description: "Verify shipping address for order [36:3]"
  - Assigned to: OPS-TEAM
  - Due Date: [36:73]

Use Case 3: Document Upload

Scenario: Finance must upload signed contract before order release
Configuration:
  - Activity Type: Manual
  - Description: "Upload signed contract for customer [18:2]

Process Button Behavior:

When user clicks Process on Manual activity:

• Optional confirmation prompt: "Complete this task?"

• Task status immediately changes to Completed

• Status rules evaluate (may release next task)

• User cannot undo (status change is permanent)

• Audit trail records who processed and when

Best Practices:

💡 TIP: Write descriptions that clearly explain WHAT to do and WHY:

• ❌ Unclear: "Review order"

• ✅ Clear: "Review order [36:3] and approve if amount < $50K and customer in good standing"

💡 TIP: Include success criteria in description:

• "Approved if: Credit limit sufficient, payment terms acceptable, no holds"

• "Verify: Address complete, contact phone valid, delivery instructions clear"

💡 TIP: Use critical dates for time-sensitive manual tasks to ensure escalation visibility:

• Due: +2D (2 days)

• Critical: +1D (1 day - appears in Critical Tasks cue)

⚠️ WARNING: Manual activities rely on user discipline. Ensure users understand they should only click Process when action is actually complete, not just to clear the task from their list.

Assigned User Considerations:

Manual activities work best with clear assignment:

• ✅ Specific user (low confusion)

• ✅ Small team (members coordinate)

• ❌ Large team (unclear ownership)

• ✅ Placeholder to role owner (auto-assigns to right person)

📋 Job Queue Activities (Value 3)

Status: Reserved for future functionality

Planned Purpose:

Job Queue activities will integrate with Business Central's Job Queue system for scheduled or background task execution.

Potential Use Cases:

• Scheduled report generation

• Batch data processing

• Automated exports/imports

• Background calculations

📋 NOTE: This activity type is not currently implemented. Selecting Activity Type = 3 will result in task behavior similar to Manual activities. For scheduled processing, use Conditional activities with time-based validation logic or use BC Job Queue separately.

✅ Approval Workflow Activities (Value 4)

Purpose:

Approval Workflow activities integrate with Business Central's standard approval workflow system. Use when you want QUALIA Workflow to orchestrate process steps that include BC's built-in approval functionality.

How It Works:

1. Task created with Activity Type = 4

2. System may lock source record (prevents editing during approval)

3. Source record status may change to "Pending Approval"

4. BC approval workflow processes (requests, notifications, approvals)

5. When approval completes, OnDatabaseModify event fires

6. QUALIA task detects approval completion

7. Task Status = Completed

8. Source record unlocked

Record Locking Behavior:

When Approval Workflow activity activates:

• Source record may be locked for editing

• Only approvers can modify (based on BC approval setup)

• Prevents conflicting changes during approval

• Lock released when approval completes or is cancelled

OnDatabaseModify Event:

The task monitors for database modifications to source record:

• Approval completion triggers modify event

• Task status automatically updates

• Workflow progression continues

Configuration Requirements:

• Activity Type = 4 (Approval Workflow)

• BC Approval Workflow must be configured for source table

• Approval users must be set up in BC

• Workflow task links to BC approval process

Use Cases:

Use Case 1: Purchase Order Approval Integration

Scenario: PO requires BC approval workflow before releasing
Configuration:
  - Workflow triggers on PO creation (Table 38)
  - Task 1:
    * Activity Type: Manual
    * Description: "Submit for approval"
    * User triggers BC approval request
  - Task 2:
    * Activity Type: Approval Workflow
    * Description: "Approval Workflow: Purchase Order [38:3]

Use Case 2: Sales Quote Approval

Best Practices:

💡 TIP: Use Approval Workflow activities when you need BC's approval features (approval chains, delegation, mobile approval) but want QUALIA to orchestrate the broader process.

📋 NOTE: You must configure BC Approval Workflow separately. QUALIA doesn't replace BC approvals, it orchestrates when they occur in a larger process.

⚠️ WARNING: If BC approval is cancelled or rejected, the QUALIA task may remain stuck. Design workflows with error handling paths (status rules that detect rejection and route to exception handling tasks).

Integration Architecture:

🎯 Choosing the Right Activity Type

Decision Matrix:

Common Patterns:

Sequential Human Tasks:

Human Task → System Gate → Human Task:

CRM Integration Pattern:

3.6. Understanding Status and Transitions

Task status controls workflow progression. Every task moves through a lifecycle from creation to completion. Understanding status transitions is essential for designing effective workflows.

📊 Status Enum Values

Tasks can have three status values:

🔄 Default Status Behavior

When workflow instance is created:

All tasks created with Status = Open (default)

Without any status rules:

• Tasks remain Status = Open forever

• Users cannot process (task not released)

• Workflow appears stuck

Why Open status exists:

Open status allows workflows to control task timing:

• "Don't start Task 2 until Task 1 completes"

• "Wait for data to be valid before releasing task"

• "Hold task until specific date/time"

⚙️ Auto-Created Status Rules

When you create a workflow task, system automatically creates two status rule lines:

Line 9999: Release Condition

• Field No.: 6 (Status field)

• Purpose: Controls when task transitions Open → Released

• Default: No validation linked (task never auto-releases)

• Common Pattern: Delete Line 9999 for immediate release

Line 10000: Completion Condition

• Field No.: 6 (Status field)

• Purpose: Controls when task transitions Released → Completed

• Default: No validation linked (user clicks Process to complete)

• Common Pattern: Link validation for auto-completion (Conditional activities)

🎯 Status Transition Patterns

Pattern 1: Immediate Release (Delete Line 9999)

Pattern 2: Sequential Dependency (Line 9999 checks previous task)

⚠️ WARNING: Remember you cannot write formulas directly. You must create a Rule Engine Validation Set with the condition logic, then link that validation set to Line 9999.

Pattern 3: Date-Based Release

Pattern 4: Manual Completion (Line 10000, no validation)

Pattern 5: Auto-Completion (Line 10000 with validation)

🔁 Status Rollback Scenarios

In some workflows, tasks need to revert status:

Scenario: Data Changes After Task Released

⚠️ WARNING: Status rollback requires careful design. Infinite loops are possible if not configured correctly. Always test rollback scenarios thoroughly.

Best Practice for Rollback:

• Use rollback sparingly (adds complexity)

• Document rollback logic clearly

• Test with multiple data change scenarios

• Monitor for stuck workflows

📋 Status Rule Configuration Steps

To configure status rules (proper Rule Engine method):

Step 1: Determine Status Logic

• When should task release?

• When should task complete?

• Any rollback scenarios?

Step 2: Create Validation Set in Rule Engine

1. Open Business Rule Setup page

2. Create new Validation Set

3. Give meaningful code (TASK-RELEASE, DATA-COMPLETE, etc.)

4. Add Scenario lines (if needed for filtering)

5. Add Condition lines with your logic

6. Test validation set independently

Step 3: Link to Status Rule Line

1. Open Workflow Setup

2. Navigate to Task Rules tab

3. Find status rule line (9999 or 10000)

4. Select validation set code

5. Save configuration

Step 4: Test Status Transitions

1. Create test workflow instance

2. Verify task starts with correct status

3. Trigger release condition

4. Confirm status changes to Released

5. Trigger completion condition

6. Confirm status changes to Completed

🔗 For detailed validation set configuration, see Rule Engine User Manual Chapter 5: Creating Business Rules.

3.7. Understanding Teams and Assignment

Teams enable flexible workload distribution and collaboration. Understanding assignment strategies is key to effective workflow design.

👥 Individual vs. Team Assignment

Individual Assignment:

Team Assignment:

🔄 Team Self-Assignment Workflow

When task assigned to team:

Step 1: Task Visible to Team

• All team members see task in "Team Tasks" section

• Task shows in Team Role Center cue

• Multiple users can view simultaneously

Step 2: Member Self-Assigns

• Team member opens task

• Clicks "Assign to Me" action

• System updates Assigned to field to member's User ID

• Task moves from "Team Tasks" to "My Tasks"

Step 3: Member Processes

• Now assigned to specific individual

• Member processes normally

• Other team members no longer see task

Step 4: Completion

• Member clicks Process

• Task completes

• Workflow continues

👥 Team Configuration

Teams are configured in QUA WorkFlow Teams page:

Team Setup:

Team Member Capabilities:

• View all tasks assigned to team

• Self-assign team tasks

• Process self-assigned tasks

• View other team member assignments (optional based on permissions)

🎯 Assignment Strategies

Strategy 1: Fixed Individual Assignment

Strategy 2: Team with Manager Oversight

Strategy 3: Dynamic Assignment (Placeholder)

Use When:
  - Assignment depends on record data
  - Different person per instance
  - Role ownership in source record
  
Configuration:
  Assigned to: [36:29]

Strategy 4: Hybrid (Individual + Team Backup)

Strategy 5: Round-Robin (Future Enhancement)

📊 Workload Distribution Patterns

Pattern 1: First Available

Team members self-assign based on availability:

• All see team tasks

• First available member takes it

• Natural workload distribution

• Works well for similar-skilled teams

Pattern 2: Skill-Based

Team members self-assign based on expertise:

• Task description indicates required skill

• Members with skill take appropriate tasks

• Requires team discipline

• Works for mixed-skill teams

Pattern 3: Manager Assignment

Manager manually assigns from team pool:

• Tasks assigned to team

• Manager views team tasks

• Manager assigns to specific member

• Centralized workload management

• More overhead but more control

⚠️ Assignment Best Practices

💡 TIP: For critical workflows, use individual assignment with team backup:

• Primary task assigned to specific person

• If overdue, secondary task assigned to team

• Ensures accountability while preventing bottlenecks

💡 TIP: Use teams for homogeneous work (everyone can do it):

• Data entry

• Document review

• Standard approvals

• Customer service tasks

💡 TIP: Use individual assignment for specialized work:

• Technical expertise required

• Authority level required

• Legal/compliance requirements

• Final approvals

⚠️ WARNING: Avoid mixing individual and team assignment for same task. Choose one approach. If you need backup, create a separate escalation task assigned to team.

3.8. Understanding Date Calculations

Due dates and critical dates drive workflow timing. Understanding date calculation patterns ensures tasks complete on schedule.

📅 Date Field Types

Due Date:

• Target completion date

• Shows in task lists and reports

• Used for overdue calculations

• Visible to assigned users

• Affects Role Center cues

Critical Date:

• Escalation threshold

• Earlier than due date (typically)

• Shows in "Critical Tasks" cue

• Warning indicator

• Prompts early action

🔢 Date Calculation Methods

Method 1: Fixed Offset from Workflow Creation

Method 2: Field-Based Date from Source Record

Configuration:
  Due Date: [36:73] (Shipment Date from Sales Header)
  
Calculation:
  Sales Order Shipment Date = 12/15/2025
  Due Date = 12/15/2025
  
Use When:
  - Deadline tied to record date
  - Process must complete by specific date
  - Date already in source data
  
Examples:
  [36:73] = Shipment Date
  [36:20] = Order Date
  [18:54]

Method 3: Field-Based Date + Offset

Configuration:
  Due Date: [36:73]+2D
  
Calculation:
  Shipment Date = 12/15/2025
  + 2 Days
  Due Date = 12/17/2025
  
Use When:
  - Deadline relative to record date
  - Buffer time needed
  - Process step timing
  
Examples:
  [36:73]-1D = Day before shipment
  [36:20]+7D = Week after order
  [18:54]

Method 4: System Date Reference

📆 Date Formula Operators

BC DateFormula supports these period codes:

Negative Offsets:

-5D = 5 days before reference date
-1W = 1 week before
-1M = 1 month before

Example:
  Due Date: [36:73]

Complex Formulas:

Multiple operators:
  +1M+5D = 1 month and 5 days
  +1Y-1D = 1 year minus 1 day
  +2W+3D = 2 weeks and 3 days

Example:
  Due Date: [36:20]

💼 Business Day Calculations

Work Days (WD):

Current Period (C prefix):

📋 NOTE: Work Day calculation respects BC base calendar and customization. Holiday calendar integration depends on BC configuration.

⏰ Critical Date Patterns

Critical dates provide early warning before due dates:

Pattern 1: Fixed Hours Before Due

Pattern 2: Percentage of Duration

Pattern 3: Explicit Time-of-Day

Pattern 4: Hours for Short-Duration Tasks

🎯 Date Strategy Examples

Use Case 1: Standard Approval

Use Case 2: Shipment-Linked Task

Task: Quality Check Before Shipment
Due Date: [36:73]-1D (day before shipment)
Critical Date: [36:73]

Use Case 3: Payment-Related Task

Task: Send Payment Reminder
Due Date: [18:54]-5D (5 days before customer payment due)
Critical Date: [18:54]

Use Case 4: Month-End Close

⚠️ Date Calculation Gotchas

Issue 1: Empty Date Fields

Problem:
  Due Date: [36:73]

Issue 2: Past Dates

Problem:
  Due Date: [36:20]

Issue 3: Month-End Edge Cases

Issue 4: Time Zone Considerations

3.9. Integration with Rule Engine (Critical Understanding)

QUALIA Workflow is built on QUALIA Rule Engine. Understanding this integration is essential for effective workflow design and troubleshooting.

🏗️ Architectural Integration

The Relationship:

Every Workflow Component Has Rule Engine Equivalent:

🎯 Scenarios: The Trigger Mechanism

What Scenarios Do:

Scenarios are inclusion filters that determine which records trigger workflows.

CODE-VERIFIED Logic:

Why This Matters:

• Scenarios are INCLUSION FILTERS (filters that identify records to process)

• Write filters that MATCH the records you WANT to process

• ALL scenario filters must match for workflow to trigger

• Think "positive case" not "negative case" - CODE-VERIFIED correct

🔗 For complete scenario logic explanation, see Rule Engine Technical Design Document Section 2.4: Scenario vs. Condition Evaluation Logic.

⚙️ Configuration Pattern: Always Use Rule Engine

Critical Rule: You CANNOT write comparison formulas directly in workflow fields.

❌ Wrong Approach (Will Not Work):

Initiated By field: [36:179]>50000
Status Rule field: [18:39]>=10000
Condition field: [36:2]

✅ Correct Approach (Rule Engine Configuration):

🔍 Validation Log: Your Troubleshooting Friend

The QUA Validation Log page shows Rule Engine evaluation results.

What It Shows:

• Every validation evaluation

• Which scenarios matched/didn't match

• Which conditions evaluated TRUE/FALSE

• Timestamp of evaluation

• Source record information

• Why workflow triggered or didn't trigger

Using Validation Log for Workflow Troubleshooting:

Problem: Workflow not triggering

Problem: Workflow triggered unexpectedly

🔗 See Rule Engine User Manual Chapter 27: Troubleshooting for detailed Validation Log usage.

🔗 Formula Syntax and Operators

All formula capabilities come from Rule Engine:

Supported Operators:

• Comparison: =, <>, <, >, <=, >=

• Mathematical: +, -, *, /, ^, MOD

• Logical: AND, OR, NOT

• String: &, CONTAINS, STARTSWITH, ENDSWITH

• Date/Time: Date calculations, WORKDATE, TODAY

• Aggregate: SUM, COUNT, AVG, MIN, MAX

Where to Use:

• ✅ In Rule Engine Validation Set conditions

• ✅ In Rule Engine Scenario filters

• ❌ NOT directly in workflow fields (must link to validation)

🔗 For complete formula reference, see Rule Engine User Manual Section 25: Formula and Placeholder Reference.

📋 Practical Integration Examples

Example 1: High-Value Order Approval

Example 2: New Customer Onboarding

Example 3: Conditional Task Completion

⚠️ Integration Warnings and Best Practices

⚠️ WARNING: Do not manually edit Rule Engine objects created by workflows. While technically possible, manual edits can cause synchronization issues. Always use Workflow Setup pages.

⚠️ WARNING: Deleting a Validation Set used by a workflow will break the workflow. Always check dependencies before deleting validation sets.

💡 TIP: Use meaningful Validation Set codes that clearly indicate purpose:

• SO-HIGH-VALUE (not VAL001)

• NEW-CUSTOMER (not CUST-CHECK)

• CREDIT-SET (not CREDIT-01) This makes Validation Log easier to read and troubleshooting faster.

💡 TIP: Test validation sets independently before linking to workflows:

1. Create validation set

2. Test with sample records

3. Check Validation Log

4. Verify scenarios evaluate correctly

5. Then link to workflow

📋 NOTE: The Rule Engine evaluates validations synchronously during BC transactions. Complex validations with many conditions can impact performance. Keep validation logic efficient.

This concludes Chapter 3: Core Concepts and Terminology. You should now understand workflow architecture, terminology, lifecycle, placeholders, activity types, status transitions, team assignment, date calculations, and Rule Engine integration.

Next Steps:

• Continue to Chapter 4 for hands-on tutorial (creating your first workflow)

• Or skip to Chapter 5 for detailed trigger configuration

• Or jump to Chapter 6 for comprehensive task design guidance