Chapter 06: Designing and Configuring Workflow Tasks

Chapter Objectives:

• Understand workflow task design principles and best practices

• Master the Task table structure and field-by-field configuration

• Learn to choose appropriate Activity Types for different scenarios

• Configure dynamic assignment using placeholders and teams

• Implement due date and critical date formulas effectively

• Build complete task configurations for real-world scenarios

Who Should Read This Chapter: Workflow Administrators, Business Analysts, Configuration Specialists

Prerequisites:

• Understanding of Rule Engine basics (Chapter 3.9)

• Familiarity with workflow triggers (Chapter 5)

• Knowledge of placeholders (Chapter 3.4)

⏱️ Estimated Reading Time: 45-60 minutes

6.1. Task Design Principles and Best Practices

Effective workflow design begins with well-designed tasks. Tasks are the fundamental building blocks of any workflow - they represent the individual steps that guide users through a business process from start to completion.

🎯 What Makes a Good Task?

A well-designed task has these characteristics:

1. Single Responsibility

• ✅ Each task represents one action or decision

• ✅ Task description clearly states what needs to be done

• ✅ Users can complete the task without switching context

• ❌ Avoid: "Review order, contact customer, and update payment terms"

• ✅ Instead: Three separate tasks (Review, Contact, Update)

2. Clear Ownership

• ✅ Task is assigned to a specific person or team

• ✅ Assignee has the authority to complete the task

• ✅ Assignee has access to required data and tools

• ❌ Avoid: Generic assignment like "Someone needs to..."

• ✅ Instead: "[36:29]" (Salesperson assigned to the order)

3. Measurable Completion

• ✅ Clear criteria for when the task is done

• ✅ System can automatically verify completion (when possible)

• ✅ Manual tasks have obvious completion action

• ❌ Avoid: Ambiguous completion like "Review as needed"

• ✅ Instead: "Approved" status or "Verify [18:39]>[36:179]"

4. Appropriate Timing

• ✅ Realistic due date based on workload and complexity

• ✅ Critical date set for escalation when needed

• ✅ Task sequence reflects business process reality

• ❌ Avoid: Everything due "tomorrow" or arbitrary dates

• ✅ Instead: "[36:20]+7D" (Order Date + 7 days)

📐 Task Granularity Guidelines

Too Granular (Task Proliferation):

Too Coarse (Hidden Complexity):

Just Right (Balanced Granularity):

Granularity Rule of Thumb:

• 5-15 tasks for most workflows

• Each task represents 5-30 minutes of work

• Task sequence reflects actual process flow

• Conditional branches add tasks only when needed

🏷️ Task Naming Conventions

Task Code Best Practices:

The "Code" field uniquely identifies each task within a workflow. Choose codes that are:

• Descriptive but concise

• Sortable by sequence (use prefixes or numbers)

• Consistent across similar workflows

• Memorable for power users

Common Naming Patterns:

Pattern 1: Sequential Numbering

Pattern 2: Functional Prefixes

Pattern 3: Hybrid Approach

Avoid These Patterns:

• ❌ Generic codes: TASK1, TASK2, TASK3

• ❌ Too long: REVIEW_CUSTOMER_CREDIT_AND_ORDER_DETAILS

• ❌ Inconsistent: Task-1, TASK02, tsk_3, T004

• ❌ Special characters: TASK#1, TASK@REVIEW, TASK(NEW)

📝 Task Description Best Practices

The "Description" field is what users see in their task list. Write descriptions that:

• Start with a verb (action-oriented)

• Explain what to do, not just what to look at

• Include key context using placeholders

• Stay under 100 characters (field limit)

Description Pattern Examples:

Basic Description (Static):

Context-Rich Description (Placeholders):

Code: APP-MGR
Description: Approve order for [18:2] - Amount [36:179]

Decision-Oriented Description:

Code: CREDIT-CHK
Description: Verify [18:2] credit: Limit [18:39] vs Order [36:179]

Status-Based Description:

Code: FOLLOW-UP
Description: Follow up with [18:2] - Order [36:3] status [36:120]

Placeholder Guidelines for Descriptions:

• ✅ Use 1-3 placeholders maximum (readability)

• ✅ Choose high-value fields (names, amounts, statuses)

• ✅ Test placeholder resolution with sample data

• ✅ Have fallback description in mind if placeholder fails

• ❌ Avoid: Too many placeholders (cluttered)

• ❌ Avoid: Technical field names in description text

🔄 Task Sequencing Strategies

Tasks execute in a specific order determined by their initial Status and Precedence rules:

Sequential Execution (Default Pattern):

Parallel Execution Pattern:

Hybrid Pattern (Common in Practice):

Conditional Branching (Advanced):

Task 1: Status = Released  (review order)
  → If [36:179]>10000 → Releases Task 2 (Manager Approval)
  → If [36:179]

⚠️ CRITICAL: Precedence rules and conditional branching are covered in detail in Chapter 7. The examples above show the concepts; implementation details follow in the next chapter.

⚡ Avoiding Task Proliferation

Problem: Too many tasks create workflow maintenance nightmares and user frustration.

Symptoms:

• Workflows with 20+ tasks for simple processes

• Tasks that take 30 seconds to complete

• Tasks that just say "Check X" with no clear action

• Users complaining about "checkbox fatigue"

Solutions:

1. Combine Related Checks into Single Task

2. Use Conditional Activity Type for Automatic Validation

❌ Before: (Manual task)
Task: Manually verify credit limit not exceeded

✅ After: (Conditional activity)
Task: Credit Limit Check
  Activity Type: Conditional
  Completion Condition: [18:39]>=[36:179]

3. Group Sequential Admin Tasks

❌ Before: (3 separate tasks)
Task 1: Update order status field
Task 2: Update order date field
Task 3: Send notification

✅ After: (1 task with multiple actions)
Task 1: Finalize Order Processing
  Action 1: Assign [36:120]=Released
  Action 2: Assign [36:5792]=[TODAY]

4. Remove Redundant Review Steps

Balance Question: "If we removed this task, would the business process break?"

• Yes → Keep the task (it's essential)

• No → Consider removing or combining

• Maybe → Convert to conditional task (executes only when needed)

💡 Task Design Checklist

Before creating a new task, ask these questions:

Purpose and Scope:

• Can I describe this task in one sentence?

• Does this task represent a single action or decision?

• Is this task necessary for the business process?

• Could this be combined with another task?

Assignment and Ownership:

• Who should perform this task?

• Does that person/team have the authority to complete it?

• Can I assign it dynamically using placeholders?

• What happens if the assigned person is unavailable?

Completion Criteria:

• When is this task "done"?

• Can completion be verified automatically?

• What actions should happen when this completes?

• What happens if this task is never completed?

Timing and Sequence:

• When should this task become available?

• What's a realistic due date?

• Does this task depend on other tasks?

• Can this task run in parallel with others?

User Experience:

• Is the task description clear and actionable?

• Will users have the information they need?

• Are there too many similar tasks in this workflow?

• Would this frustrate or help the user?

Technical Configuration:

• What Activity Type is appropriate?

• Are placeholders resolving correctly?

• Have I tested the date formulas?

• Does this work with the source table structure?

Use this checklist during task design to catch issues early.

6.2. Understanding the Workflow Task Table

Before diving into field-by-field configuration, let's understand how tasks fit into the overall workflow architecture and what happens behind the scenes when you create a task.

🗄️ Task Table Structure Overview

Table Information:

• Table ID: 72777601

• Table Caption: "QUA Workflow Task"

• Primary Key: Workflow No. + Code

• Parent Table: QUA Workflow Setup (72777600)

• Created By: Workflow administrators and configuration specialists

Relationship to Other Tables:

Each task creates its own Rule Engine validation set automatically. This is a critical architectural pattern that enables:

• Task-specific conditions (status rules)

• Task-specific actions (assign fields, send emails)

• Integration with the Rule Engine evaluation cycle

⚙️ Auto-Created Objects When You Create a Task

When you insert a new Workflow Task record, the system automatically creates several related objects behind the scenes. Understanding this automation helps you troubleshoot and work efficiently.

Step-by-Step: What Happens on Task Insert

User Action:

System Response (Automatic):

1. Validation Set Creation

2. Base Validation Record Creation

Creates: QUA Validations (Table 72777801)
  Validation Set ID = "WF-ONBOARD_MGR-REVIEW"
  Line No. = 0
  Description = "Manager review order"
  Trigger String = "[36:0]

3. Default Status Rules Creation

Why Two Default Status Rules?

Line 9999: "When should this task become Released (available)?"

• Default behavior: Immediate release (no formula, auto-releases)

• Customizable: Add formulas to create wait conditions

• Example use: Wait for previous task completion, wait for data

Line 10000: "When should this task be Completed?"

• Default behavior: Manual completion (user clicks "Process")

• Customizable: Add formulas to create auto-complete conditions

• Example use: Data validation passed, threshold met, date reached

🔗 Related Topic: Chapter 7 covers Status Rules in complete detail, including how to customize Lines 9999 and 10000 for conditional release and auto-completion.

🔗 Task-to-Rule Engine Integration

Critical Understanding: Each task is backed by a Rule Engine validation set. This means:

Tasks CAN do everything Rule Engine can do:

• ✅ Evaluate conditions (scenarios, formulas)

• ✅ Execute actions (assign fields, send emails, create records)

• ✅ Reference placeholders (same record, linked records)

• ✅ Use complex formulas (comparisons, calculations)

Tasks inherit Rule Engine limitations:

• ❌ System values (TODAY, USERID) not supported in scenarios

• ❌ Aggregate functions (SUM, COUNT, AVG) not in placeholders

• ❌ Old values not available (record must exist)

• ❌ Direct formula syntax not in workflow fields (must use Rule Engine configuration)

Navigation Pattern:

From any Workflow Task, you can access the Rule Engine configuration:

1. Open the Workflow Setup card

2. Select the task line in the Tasks subpage

3. Click "Actions" → "Show Validation Set"

4. This opens the Rule Engine configuration for this task

5. Here you can add conditions, actions, formulas

This navigation is essential for advanced task configuration.

📋 Task Primary Key and Uniqueness

Primary Key: Workflow No. + Code

Uniqueness Rules:

• ✅ Same Code can exist in different workflows

  • Workflow "WF-A" can have task "REVIEW"

  • Workflow "WF-B" can have task "REVIEW"

• ❌ Same Code cannot exist twice in same workflow

  • Error: "REVIEW already exists in workflow WF-A"

• ✅ Solution: Use different codes or sequential numbering

  • REVIEW-1, REVIEW-2

  • REV-MGR, REV-FIN

Best Practice: Establish naming conventions at the organization level to avoid conflicts and improve consistency across workflows.

🗑️ Task Deletion Behavior

What Gets Deleted (Cascade)

When you delete a Workflow Task:

1. ✅ The task record itself (Table 72777601)

2. ✅ ALL Status Rules for that task (Table 72777603)

3. ✅ ALL Precedence Rules referencing that task (Table 72777604)

4. ✅ The Validation Set (Table 72777800)

5. ✅ ALL Validations in that set (Table 72777801)

6. ✅ ALL Validation Formulas for those validations (Table 72777802)

What Does NOT Get Deleted:

• ❌ Workflow Entries (historical instances)

• ❌ Workflow Entry Details (completed tasks)

• ❌ Other tasks in the same workflow

• ❌ The parent Workflow Setup

When You Delete a Task from an active workflow:

⚠️ WARNING: Deleting tasks from workflows that have active instances (Workflow Entries with Status=Open or Released) creates orphaned data:

• Existing workflow instances still reference the deleted task

• Entry Detail records remain but have no task definition

• Users may see incomplete task lists

• Reporting and tracking may show gaps

Safe Deletion Pattern:

1. Check for active instances:
   - Open Workflow Entries page
   - Filter: Workflow No. = [Your Workflow]

Recommendation: Instead of deleting tasks from active workflows, consider:

• Disable the workflow while editing

• Create a new version of the workflow (V2)

• Use Status Rule formulas to conditionally skip tasks

6.3. Creating Tasks (Step-by-Step Procedure)

Now that you understand task architecture, let's walk through the actual task creation process.

📝 Opening the Task Configuration Interface

Method 1: From Workflow Setup Card

Method 2: From Search

1. Search: "QUA Workflow Task"
2. Opens list of ALL tasks across ALL workflows
3. Filter: Workflow No. = [Your Workflow]

Page Layout:

┌─────────────────────────────────────────────────────────┐
│ QUA Workflow Setup Card                                 │
│                                                           │
│ General Tab                                              │
│   Workflow No.: WF-ONBOARD                               │
│   Description: Customer Onboarding Workflow              │
│   ...                                                     │
│                                                           │
│ Tasks Tab ←─ YOU CONFIGURE TASKS HERE                   │
│ ┌───────────────────────────────────────────────────┐  │
│ │ Code         │ Description      │ Status │ Activ.. │  │
│ │──────────────│──────────────────│────────│─────────│  │
│ │ TASK-010     │ Initial Review   │ Releas │ Manual  │  │
│ │ TASK-020     │ Manager Approval │ Open   │ Manual  │  │
│ │ TASK-030     │ Final Processing │ Open   │ Condit  │  │
│ └───────────────────────────────────────────────────┘  │
│                                                           │
│ [New Task Button]

➕ Adding a New Task

Procedure:

Step 1: Initiate New Task Creation

Actions:
  - Click in empty row at bottom of Tasks subpage, OR
  - Click [New]

Step 2: Enter Required Fields

Required Fields (Must Enter):
  1. Code: Unique task identifier
     - Example: "MGR-APPROVE"
     - Validation: Must be unique within this workflow
     - Format: Code[20] (letters, numbers, hyphens)
     
  2. Description: User-facing task name
     - Example: "Manager approval for order [36:3]"
     - Validation: Recommended (not technically required)
     - Format: Text[100]

Step 3: Configure Essential Fields

Essential Configuration (Strongly Recommended):
  3. Status: Initial status for task instances
     - Options: Open, Released
     - Default: Open
     - Choose: Released if task should execute immediately
     
  4. Activity Type: How users interact with this task
     - Options: Conditional, Interaction, Manual, Job Queue, Approval
     - Default: Conditional
     - Choose based on task purpose (see Section 6.5)
     
  5. Assigned to: Who performs this task
     - Format: User ID, placeholder, or email
     - Examples: "JDOE", "[36:29]", "[18:102]"
     - Can be combined with "Assigned to Team"
     
  6. Due Date: When task should be completed
     - Format: Date formula (text field)
     - Examples: "+7D", "[36:20]

Step 4: Save the Task

Actions:
  - Click outside the row, OR
  - Press Tab/Enter to next field until row unfocused, OR
  - Click [Save] if button visible

System Response:
  - Validates required fields
  - Creates Validation Set (background)
  - Creates base Validation record (background)
  - Creates 2 Status Rules (Lines 9999, 10000)
  - Displays confirmation (if configured)
  
Result:
  - Task is saved and ready to configure further
  - Validation Set created: [Workflow No.]_[Code]

⚠️ Common Creation Errors and Solutions

Error 1: "Code already exists"

Error 2: "Workflow No. must have a value"

Error 3: "Activity Type causes field visibility issues"

Error 4: "Placeholder doesn't resolve"

Problem:
  Used placeholder like [18:102] but field shows "[18:102]

🎯 Quick Start: Minimal Task Configuration

For rapid testing or simple workflows, you can create tasks with minimal configuration:

Minimal Manual Task (simplest possible):

Minimal Conditional Task (auto-complete):

Code: CHECK-AMOUNT
Description: Verify amount threshold
Status: Released
Activity Type: Conditional

Then: Add completion condition via Status Rule (Chapter 7)
  Condition: [36:179]

You can always return to add more configuration (assignment placeholders, due dates, actions) after initial creation.

6.4. Task Field Reference (Complete Field-by-Field Guide)

This section provides comprehensive documentation for every field in the Workflow Task table. Each field is documented with its caption, data type, purpose, usage patterns, and configuration examples.

📋 Field Reference Organization

Fields are presented in logical grouping order:

1. Identification Fields: Workflow No., Code, Description

2. Status and Type Fields: Status, Activity Type

3. Assignment Fields: Assigned to, Assigned to Team

4. Date Fields: Due Date, Critical Date

5. Activity-Specific Fields: Template Code, Contact No.

6. System Fields: Rule, Rule Line No., No. of Actions

🔑 Identification Fields

"Workflow No." Field

Field Properties:

• Caption: "Workflow No."

• Data Type: Code[20]

• Required: Yes (always)

• Editable: No (auto-populated from parent)

• Table Relation: QUA Workflow Setup (72777600)

Purpose: Links this task to its parent workflow. Every task must belong to exactly one workflow.

Behavior:

• Auto-populated when creating task from Workflow Setup card

• Cannot be changed after task creation

• Used as first part of primary key (Workflow No. + Code)

Usage Pattern:

Troubleshooting:

• ❌ Error: "Workflow No. must have a value"

  • Cause: Creating task directly in table (not via Workflow Setup)

  • Solution: Always create tasks from Workflow Setup card page

"Code" Field

Field Properties:

• Caption: "Code"

• Data Type: Code[20]

• Required: Yes

• Editable: Yes (during creation, limited after)

• Validation: Must be unique within the workflow

• Case Sensitive: No (BC normalizes to uppercase)

Purpose: Unique identifier for this task within the workflow. Used for task references, status rules, precedence rules, and validation set naming.

Naming Patterns: (see Section 6.1 for detailed patterns)

• Sequential: TASK-010, TASK-020, TASK-030

• Functional: REV-ORDER, APP-MGR, FIN-VERIFY

• Hybrid: 10-REV, 20-APP-MGR, 30-FIN

Character Restrictions:

• ✅ Allowed: Letters (A-Z), numbers (0-9), hyphen (-), underscore (_)

• ❌ Not allowed: Spaces, special characters (@, #, $, %, etc.)

• ✅ Recommended: Consistent format across organization

Usage Examples:

Important Notes:

• ⚠️ Changing Code after task is in use affects:

  • Validation Set Code (gets renamed)

  • Status Rule references (auto-updated)

  • Precedence Rule references (may need manual update)

  • Active Workflow Entries (historical data keeps old code)

Best Practice: Decide on Code before creating active workflow instances. Changing codes in production workflows creates confusion in historical data.

"Description" Field

Field Properties:

• Caption: "Description"

• Data Type: Text[100]

• Required: No (but strongly recommended)

• Editable: Yes (can change anytime)

• Placeholder Support: YES ✅

• Copies To: Validation Set description, Validation description, Entry Detail description

Purpose: User-facing name for this task. This is what users see in their task list, so clarity is essential.

Description Best Practices: (see Section 6.1 for detailed guidance)

Writing Effective Descriptions:

1. Start with action verb: "Review", "Approve", "Verify", "Contact", "Update"

2. Include key context: What record? What field? What threshold?

3. Use placeholders: Show dynamic data to users

4. Keep concise: 100 character limit, aim for 40-60 for readability

5. Test readability: Does it make sense without opening the record?

Placeholder Usage in Descriptions:

Static Description (no context):

Context-Rich Description (with placeholders):

Code: MGR-APPROVE
Description: "Approve order [36:3] for [18:2] - Amount [36:179]

Decision-Support Description (comparison):

Code: CREDIT-CHK
Description: "Credit check: [18:2] limit [18:39] vs order [36:179]

Common Placeholder Patterns:

Customer name: [18:2]
Order number: [36:3]
Order amount: [36:179]
Order status: [36:120]
Salesperson: [36:29]
Order date: [36:20]
Customer credit limit: [18:39]
Customer email: [18:102]

Description Character Limit Strategy:

✅ Good (58 characters):
"Approve order [36:3] - [18:2] - Amt [36:179]"

❌ Too long (112 characters - will truncate):
"Please review and approve this sales order [36:3] for customer [18:2] with total amount including VAT [36:179]"

✅ Shortened (85 characters):
"Review order [36:3] for [18:2] - Amt [36:179] - Due [36:5792]

Troubleshooting:

• Issue: Placeholder shows "[36:179]" literally instead of value

  • Explanation: Placeholders resolve at runtime (when workflow instance created)

  • Solution: This is normal during configuration; test with actual workflow instance

• Issue: Description truncated in UI

  • Cause: Exceeds 100 character limit or column width too narrow

  • Solution: Shorten description or widen column

⚙️ Status and Type Fields

"Status" Field

Field Properties:

• Caption: "Status"

• Data Type: Enum (QUA Workflow Task Status - 72777601)

• Options: 0=Open, 1=Released, 2=Completed

• Required: Yes

• Default: Open

• Editable: Yes

Purpose: Defines the initial status for task instances when workflow is created. This is the starting point for each task in every workflow instance.

Status Values Explained:

Open (0): Task is not yet ready for user action

Released (1): Task is ready for user action immediately

Completed (2): Task starts as already done

Typical Workflow Pattern:

Workflow: Customer Onboarding

Task 1: Initial Data Review
  Status = Released  ← Starts immediately
  
Task 2: Credit Check
  Status = Open  ← Waits for Task 1 to complete
  Release Condition: [Task 1 Status] = Completed
  
Task 3: Manager Approval
  Status = Open  ← Waits for Task 2
  Release Condition: [Task 2 Status] = Completed
  
Task 4: Final Setup
  Status = Open  ← Waits for Task 3
  Release Condition: [Task 3 Status]

Parallel Task Pattern:

Workflow: Order Verification

Task 1: Initial Review
  Status = Released  ← Starts immediately
  
Task 2: Credit Review
  Status = Released  ← Also starts immediately (parallel)
  
Task 3: Inventory Review
  Status = Released  ← Also starts immediately (parallel)
  
Task 4: Final Approval
  Status = Open  ← Waits for Tasks 1, 2, 3 all complete
  Release Condition: [All previous tasks]

Status vs. Status Rules:

• This "Status" field: Initial state when task instance is created

• Status Rules (Chapter 7): Conditions that change status dynamically

  • Line 9999: When to change Open → Released

  • Line 10000: When to change Released → Completed

  • Custom rules: Any other status transitions

Special Behavior: Setting Status = Released:

When you set the default Status to "Released" on a task definition:

⚠️ CRITICAL: If you change a task from Released → Open after creation, you MUST add release conditions (Status Rules) or the task will never become Released in workflow instances.

Decision Guide:

"Activity Type" Field

Field Properties:

• Caption: "Activity Type"

• Data Type: Enum (QUA Workflow Activity Type - 72777600)

• Options: 0=Conditional, 1=Interaction, 2=Manual, 3=Job Queue, 4=Approval Workflow

• Required: Yes

• Default: Conditional

• Editable: Yes

• Affects: Field visibility, completion behavior, user interaction model

Purpose: Defines HOW users interact with this task and HOW the task completes. This is one of the most important configuration decisions.

Activity Type Overview Table:

Activity Type: Conditional (0)

When to Use:

• Task completion depends on data meeting specific criteria

• System can automatically verify conditions

• User confirms after condition is met

• Examples: Credit limit check, data validation, threshold verification

How It Works:

1. Task starts (Status = Released)

2. System continuously evaluates completion condition

3. When condition TRUE → Task can complete

4. User clicks "Process" to confirm

5. Task Status → Completed

Configuration Requirements:

• ✅ Must add completion condition to Status Rule Line 10000

• ✅ Condition formula evaluates to TRUE/FALSE

• ✅ Task remains Released until condition met

Example Configuration:

Task: Credit Limit Verification
  Code: CREDIT-CHK
  Description: "Verify credit: [18:2] limit [18:39] vs order [36:179]"
  Status: Released
  Activity Type: Conditional
  
Status Rule (Line 10000):
  Field No.: 6 (Status)
  Value: Completed
  
  Validation Formula (Condition):
    Table ID: 18 (Customer via linked table)
    Field No.: 39 (Credit Limit)
    Filter String: >=[36:179]

User Experience:

Advantages:

• ✅ Eliminates manual verification errors

• ✅ Provides objective completion criteria

• ✅ Gives users real-time status visibility

• ✅ Can chain multiple conditional tasks

Limitations:

• ❌ Requires data to be present in system

• ❌ Cannot handle subjective decisions

• ❌ Condition must be expressible as formula

Activity Type: Interaction (1)

When to Use:

• Task requires customer/contact interaction

• Need to log interaction in CRM (Interaction Log Entries)

• Examples: Follow-up call, send email, schedule meeting, customer contact

How It Works:

1. Task starts (Status = Released)

2. User clicks task to open

3. System opens Interaction Creation wizard

4. User creates interaction (call, email, meeting, etc.)

5. Interaction logged to BC Interaction Log Entries

6. Segment Line created linking interaction to workflow

7. Task Status → Completed automatically

Configuration Requirements:

• ✅ Must specify Template Code (Interaction Template)

• ✅ Should specify Contact No. (or use placeholder)

• ✅ Interaction Template must exist in BC

• ✅ Contact must be valid Contact record

Required Fields for Interaction Activity:

"Template Code" Field:

• Caption: "Template Code"

• Type: Code[10]

• Required: Yes (for Interaction activity)

• Visible: Only when Activity Type = Interaction

• Table Relation: Interaction Template

• Purpose: Defines interaction type (call, email, meeting)

"Contact No." Field:

• Caption: "Contact No."

• Type: Text[250]

• Required: Recommended

• Visible: Only when Activity Type = Interaction

• Placeholder Support: YES ✅

• Purpose: Contact person for the interaction

Example Configuration:

Task: Customer Follow-Up Call
  Code: CALL-CUST
  Description: "Follow up with [18:2] - Order [36:3]"
  Status: Released
  Activity Type: Interaction
  Template Code: CALL (must exist in Interaction Templates)
  Contact No.: [18:102]  ← Resolves to Customer Contact
  Assigned to: [36:29]

Placeholder Patterns for Contact No.:

Direct contact field:
  [18:102]  ← Customer."Primary Contact No."
  
Email-based lookup:
  [18:5052]  ← Customer."E-Mail"
  
Salesperson contact:
  [36:29]  ← Sales Header."Salesperson Code" (if Salesperson is contact)
  
Dynamic from related table:
  [Contact:1]

User Experience:

CRM Integration:

Advantages:

• ✅ Automatic CRM logging (no manual entry)

• ✅ Interaction history tracked

• ✅ Integrates with BC Contact Management

• ✅ Provides interaction reporting

Limitations:

• ❌ Requires BC Interaction Templates configured

• ❌ Requires valid Contact records

• ❌ Template Code must exist in system

• ❌ More complex setup than Manual activity

Activity Type: Manual (2)

When to Use:

• Simple tasks requiring human judgment

• Tasks without specific completion criteria

• Tasks where "done" means "user says it's done"

• Examples: General review, manager approval, simple confirmation

How It Works:

1. Task starts (Status = Released)

2. User opens task (views record, performs work)

3. User clicks "Process" button

4. Task Status → Completed

5. No automatic verification

Configuration Requirements:

• ✅ No special configuration needed

• ✅ Simplest activity type to set up

• ✅ Just set Activity Type = Manual

Example Configuration:

Task: Manager Review
  Code: MGR-REVIEW
  Description: "Review and approve order [36:3]

User Experience:

User opens task:
  - Sees task description
  - Can view source record (Sales Order, Customer, etc.)
  - Performs review/work
  - Clicks [Process]

Advantages:

• ✅ Simplest to configure

• ✅ No prerequisites

• ✅ Flexible (user decides when done)

• ✅ Works for any task type

Limitations:

• ❌ No automatic verification

• ❌ Relies on user judgment

• ❌ No objective completion criteria

• ❌ Can be "clicked through" without work

Best Practices for Manual Tasks:

Activity Type: Job Queue (3)

Status: Future feature (not yet implemented in current version)

Planned Use:

• Scheduled batch processing

• System-driven tasks (no user action)

• Background operations

• Examples: Nightly report generation, data sync, scheduled updates

Current Recommendation: Use other activity types until Job Queue is fully implemented.

Activity Type: Approval Workflow (4)

When to Use:

• Integration with Business Central standard approval workflows

• Tasks that prevent record modification until approved

• Formal approval processes requiring BC approval entries

• Examples: Document approval, purchase order approval, invoice approval

How It Works:

1. Task starts (Status = Released)

2. System locks source record (prevents modification)

3. User performs approval in BC approval system

4. BC approval granted → OnDatabaseModify event fires

5. Event triggers Status Rule evaluation

6. Task Status → Completed

7. Source record unlocked

Configuration Requirements:

• ✅ Task Status must be Released (not Open)

• ✅ Source record must support BC approval workflows

• ✅ BC approval workflow must be configured separately

• ✅ Status Rule triggered by OnDatabaseModify event

Example Configuration:

Task: Approve Sales Order
  Code: APP-SO
  Description: "Approve order [36:3] - Amount [36:179]"
  Status: Released  ← MUST be Released
  Activity Type: Approval Workflow
  Assigned to: [36:29]

Record Locking Behavior:

Integration with BC Approval System:

Advantages:

• ✅ Integrates with standard BC approval workflows

• ✅ Prevents record modification during approval

• ✅ Uses familiar BC approval UI

• ✅ Audit trail in BC Approval Entries

Limitations:

• ❌ Requires BC approval workflow setup

• ❌ More complex configuration

• ❌ Must use Status = Released (cannot start as Open)

• ❌ Limited to records supporting BC approvals

🎯 Activity Type Decision Tree

Use this flowchart to choose the right Activity Type:

START: What does this task need to do?
   │
   ├─ Formal BC Approval Required?
   │  └─ YES → Activity Type: Approval Workflow (4)
   │
   ├─ Customer/Contact Interaction Required?
   │  └─ YES → Activity Type: Interaction (1)
   │
   ├─ Can Completion Be Verified Automatically?
   │  └─ YES → Activity Type: Conditional (0)
   │
   ├─ Simple User Confirmation Needed?
   │  └─ YES → Activity Type: Manual (2)
   │
   └─ Scheduled/Batch Processing?
      └─ YES → Activity Type: Job Queue (3) [Future]

Quick Reference Table:

👥 Assignment Fields

"Assigned to" Field

Field Properties:

• Caption: "Assigned to"

• Data Type: Text[250]

• Required: No (but strongly recommended for most task types)

• Editable: Yes

• Placeholder Support: YES ✅

• Validation: Resolves to User ID, Email, or Team Member at runtime

Purpose: Specifies WHO should perform this task. This is one of the most powerful fields because it supports dynamic assignment using placeholders.

Assignment Patterns:

Pattern 1: Fixed User Assignment

Pattern 2: Dynamic Field-Based Assignment (Common)

Placeholder resolves to user from source record:
  Assigned to: "[36:29]"
  
Explanation:
  - [36:29]

Pattern 3: Email-Based Lookup

Placeholder resolves to email, system finds user:
  Assigned to: "[18:102]"
  
Explanation:
  - [18:102]

Pattern 4: Cross-Table Assignment (Linked Tables)

Placeholder from related table via linked table:
  Assigned to: "[18:29]"
  
Explanation:
  - Requires Reference Table configured
  - Reference Table: 18 (Customer)
  - Reference Filter: Customer."No." = Sales Header."Sell-to Customer No."
  - [18:29]

Pattern 5: Team Assignment (see "Assigned to Team" field)

Combined assignment:
  Assigned to: [36:29]

Common Placeholder Examples for Assignment:

Sales Orders (Table 36):
  [36:29]  = Salesperson Code
  [36:31]  = Purchaser Code (if present)
  
Customers (Table 18):
  [18:29]  = Salesperson Code
  [18:102] = E-Mail (email-based lookup)
  
Purchase Orders (Table 38):
  [38:31]  = Purchaser Code
  
Service Orders (Table 5900):
  [5900:29] = Salesperson Code
  
Custom Fields:
  [36:50000]

Assignment Resolution at Runtime:

Step 1: Placeholder Resolution

Task configuration:
  Assigned to: "[36:29]"

Workflow triggered by: Sales Order SO-12345
  Sales Header."Salesperson Code" = "JSMITH"

Resolution:
  [36:29]

Step 2: User Lookup

Step 3: Task Assignment

Assignment Troubleshooting:

Problem: Task shows "[36:29]" literally in Assigned to

Cause: Placeholder didn't resolve
Possible reasons:
  1. Source record doesn't have value in field 29
  2. Field 29 is blank on that specific record
  3. Placeholder syntax error

Solution:
  - Check source record: Does it have Salesperson Code filled?
  - Verify placeholder syntax: [TableID:FieldID]

Problem: Task unassigned (Assigned to is blank)

Problem: Wrong user assigned

Best Practices:

• ✅ Always test assignment with sample data

• ✅ Verify users exist in BC before going live

• ✅ Have fallback strategy (team assignment)

• ✅ Document what field is used for assignment

• ❌ Don't assume field always has value

• ❌ Don't use email assignment without validation

"Assigned to Team" Field

Field Properties:

• Caption: "Assigned to Team"

• Data Type: Code[20]

• Required: No

• Editable: Yes

• Placeholder Support: No (static team code only)

• Table Relation: QUA Team (72777609)

Purpose: Assigns task to a team rather than (or in addition to) an individual user. Enables workload distribution, team visibility, and self-assignment workflows.

Team Assignment Patterns:

Pattern 1: Team-Only Assignment

Pattern 2: User + Team Assignment (Recommended)

Configuration:
  Assigned to: [36:29]

Pattern 3: Team with Manager Oversight

Team Self-Assignment Workflow:

User Experience (Team Member):

Benefits of Team Assignment:

• ✅ Workload distribution (first available takes it)

• ✅ Coverage during absences (team can cover)

• ✅ Skill-based routing (specialized teams)

• ✅ Manager visibility (team performance tracking)

• ✅ Flexibility (team members self-select work)

Team Configuration (QUA Team table):

Assignment Resolution with Teams:

Scenario: Individual + Team Assignment

Scenario: Team-Only Assignment

When to Use Teams vs. Individual Assignment:

Troubleshooting Team Assignment:

Problem: Team members don't see team tasks

Problem: Too many people seeing tasks

Problem: Tasks not being claimed

📅 Date Fields

"Due Date" Field

Field Properties:

• Caption: "Due Date"

• Data Type: Text[250]

• Required: No (but strongly recommended)

• Editable: Yes

• Formula Support: YES ✅

• Placeholder Support: YES ✅

• Validation: Must evaluate to valid date at runtime

Purpose: Specifies when the task should be completed. Critical for time-sensitive workflows, SLA tracking, and user prioritization.

Due Date is TEXT field: Unlike typical date fields, this is stored as text (formula) that evaluates to a date at runtime. This enables dynamic date calculations based on record data.

Date Formula Patterns:

Pattern 1: Fixed Offset from Today

Pattern 2: Offset from Record Date Field

Due Date: "[36:20]+30D"

Explanation:
  - [36:20]

Pattern 3: Use Record Date Directly

Due Date: "[36:5792]"

Explanation:
  - [36:5792]

Pattern 4: Complex Calculation

Due Date: "[36:20]+1M+5D"

Explanation:
  - [36:20]

Pattern 5: Business Days (Work Days)

Date Formula Syntax Reference:

Time Unit Codes:

Operator Examples:

Combined Formulas:

+1M+5D      = Plus 1 month AND plus 5 days
+2W-1D      = Plus 2 weeks MINUS 1 day
[36:20]

System Date Placeholders:

Common Due Date Patterns:

Next Day:
  "+1D"

Next Business Day:
  "+1WD"

One Week:
  "+7D" or "+1W"

Two Weeks:
  "+14D" or "+2W"

30 Days from Order:
  "[36:20]+30D"

End of Current Month:
  "CM"

First Day of Next Month:
  "CM+1D"

Customer Requested Date:
  "[36:5792]"

Shipment Date minus 3 days:
  "[36:5794]

Due Date Calculation Examples:

Example 1: Simple Offset

Example 2: Record Date + Offset

Task: Follow-up Call
Due Date: "[36:20]+7D"

Order Date ([36:20]

Example 3: Business Days

Example 4: Month-End Processing

Due Date and User Priorities:

Tasks are typically sorted by due date in user task lists:

Overdue Tasks:

Troubleshooting Due Date Formulas:

Problem: Due date shows formula text "[36:20]+7D" literally

Problem: Due date is blank

Cause: Formula evaluation failed
Reasons:
  1. Source field ([36:20]

Problem: Due date in past

Best Practices:

• ✅ Always set due dates (helps prioritization)

• ✅ Use realistic timeframes (test with real workload)

• ✅ Consider business days for user tasks

• ✅ Account for weekends/holidays if critical

• ✅ Test formula evaluation with sample data

• ❌ Don't set due dates too aggressive (causes burnout)

• ❌ Don't use complex formulas without testing

• ❌ Don't forget time zones if global team

"Critical Date" Field

Field Properties:

• Caption: "Critical Date"

• Data Type: Text[250]

• Required: No

• Editable: Yes

• Formula Support: YES ✅

• Placeholder Support: YES ✅

• Validation: Must evaluate to valid date at runtime

Purpose: Specifies an escalation threshold date. When Critical Date is reached (before Due Date), task is flagged for management attention. Used for SLA monitoring and proactive escalation.

Critical Date vs. Due Date:

Critical Date Formula Patterns (same syntax as Due Date):

Pattern 1: Fixed Days Before Due Date

Pattern 2: Percentage of Time Period

Pattern 3: Based on Record Field

Due Date: "[36:5792]"  (Requested Delivery Date)
Critical Date: "[36:5792]

Pattern 4: Business Days Before Due

Critical Date Behavior:

When Critical Date Reached:

User Interface Display:

Cue Tile Integration:

Common Critical Date Patterns:

75% Rule (Critical at 75% of time to deadline):
  Due Date: "+20D"
  Critical Date: "+15D"
  Escalation window: 5 days

50% Rule (Critical at midpoint):
  Due Date: "+10D"
  Critical Date: "+5D"
  Escalation window: 5 days

Fixed Warning Period (3 days before due):
  Due Date: "[36:5792]"
  Critical Date: "[36:5792]

When to Use Critical Date:

✅ Use Critical Date when:

• Task has serious consequences if late

• Management wants early warning

• SLA monitoring required

• Proactive escalation needed

• Multiple stakeholders need visibility

• Time-sensitive customer commitments

❌ Skip Critical Date when:

• Task has no time sensitivity

• Due date is sufficient

• No escalation process defined

• Task duration is very short (< 1 day)

• Flexibility in completion timing

Critical Date and Escalation Workflows:

Troubleshooting Critical Date:

Problem: Critical Date never triggers

Problem: All tasks showing as critical

Problem: Critical date ignored by users

Best Practices:

• ✅ Critical Date should be BEFORE Due Date

• ✅ Allow reasonable escalation window (20-33% of timeline)

• ✅ Use consistently across similar task types

• ✅ Train users on critical date meaning

• ✅ Implement escalation process

• ❌ Don't mark everything critical (dilutes importance)

• ❌ Don't set critical date too close to due date (no time to escalate)

• ❌ Don't use without escalation follow-up process

Activity-Specific Fields

These fields are only visible and relevant for specific Activity Types.

"Template Code" Field

Field Properties:

• Caption: "Template Code"

• Data Type: Code[10]

• Required: Yes (when Activity Type = Interaction)

• Editable: Yes

• Visible: Only when Activity Type = Interaction

• Table Relation: Interaction Template (5064)

• Placeholder Support: No (must be static template code)

Purpose: Specifies which CRM Interaction Template to use when creating customer/contact interactions.