Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developer.kodexa.ai/llms.txt

Use this file to discover all available pages before exploring further.

CREATE_TASK steps are how an Activity brings a person into the workflow. Use them when the next decision cannot be safely automated: analyst review, correction, approval, exception handling, reconciliation, or escalation. An Activity is broader than a task. The Activity owns the business process. A Task is the unit of human work created when that process needs judgment.

​
When to Use CREATE_TASK

Use a CREATE_TASK step when the workflow needs someone to:
  • Review extracted fields before posting them to a downstream system
  • Correct data that failed validation
  • Decide whether an exception should be accepted, rejected, or escalated
  • Approve work above a business threshold
  • Add missing context that is not present in the document
  • Resolve a mismatch between the document and a system of record
Do not use CREATE_TASK for pure automation. Use EXECUTION, SCRIPT, BRIDGE_CALL, or LLM for automated work.

​
Basic Shape

{
  "slug": "analyst-review",
  "kind": "CREATE_TASK",
  "dependsOn": ["route:review"],
  "config": {
    "taskTemplateRef": "invoice-review",
    "taskStatusSlug": "open",
    "taskData": {
      "priority": "high",
      "sourceSystem": "{{inputs.sourceSystem}}"
    }
  }
}
Config keyDescription
taskTemplateRefTask Template used to create the human work item
taskStatusSlugInitial status for the created Task
taskDataProperties copied onto the Task
titleOptional explicit title for the Task
descriptionOptional explicit description for the Task
priorityOptional priority; otherwise the parent Task priority can be inherited
In the current runtime, the underlying materialized item type is still named TASK in some code and stored data. The Activity Plan concept should still be modeled as CREATE_TASK: create a Task, wait for human work, then continue the Activity from the Task result.

​
How It Runs

When the step becomes ready, Kodexa:
  1. Resolves the target project from the running Activity context.
  2. Resolves taskTemplateRef inside that project organization.
  3. Resolves taskStatusSlug to the initial project task status.
  4. Builds task properties from taskData, title, description, and priority.
  5. Creates the child Task and links it to the Activity step.
  6. Attaches the relevant document families.
  7. Waits for the Task to reach an outcome that can continue the Activity.

​
Document Family Handling

A CREATE_TASK step should carry the document context the reviewer needs. The runtime copies document families from the parent workflow context onto the created Task. When the upstream dependency is a per-document step, Kodexa can narrow the copied document families to the document-level results that actually succeeded. This is useful for exception queues because the reviewer sees only the documents that need attention.

​
Task Templates

The Task Template is where you define the review surface:
  • Which Data Form the reviewer sees
  • Which document families and data definitions are relevant
  • Which actions or statuses complete the work
  • Which assignment, priority, or team rules should apply
  • Which fields are required before completion
Keep the Activity Plan focused on orchestration. Keep the reviewer experience in the Task Template and Data Form.

​
Routing From a Task

Downstream steps can depend on the Task outcome. 
[
  {
    "slug": "analyst-review",
    "kind": "CREATE_TASK",
    "dependsOn": ["route:review"],
    "config": {
      "taskTemplateRef": "invoice-review"
    }
  },
  {
    "slug": "post-approved-invoice",
    "kind": "BRIDGE_CALL",
    "dependsOn": ["analyst-review:approved"],
    "config": {
      "serviceBridgeRef": "finance-erp",
      "endpointName": "post-invoice"
    }
  },
  {
    "slug": "notify-rejection",
    "kind": "BRIDGE_CALL",
    "dependsOn": ["analyst-review:rejected"],
    "config": {
      "serviceBridgeRef": "finance-erp",
      "endpointName": "reject-invoice"
    }
  }
]
The Task remains the human unit of work. The Activity uses the Task outcome to keep the business process moving.

​
Naming Tasks

Use clear, business-facing titles. A reviewer should be able to scan a queue and know what needs attention. Good titles:
  • Review invoice INV-10482
  • Resolve vendor mismatch
  • Approve loan packet exception
  • Review missing claim documents
Avoid titles that describe implementation details:
  • Step 3 child task
  • Script exception
  • Manual checkpoint

​
Practical Pattern

A common Activity Plan shape is: The Activity handles the process. The Task exists only for the review segment.

​
Checklist

  • The Task Template exists and is bound to the project.
  • The Data Form gives the reviewer all required document and data context.
  • The Activity Plan declares every Task outcome that downstream steps depend on.
  • The created Task receives the right document families.
  • Task titles and priorities are meaningful in a real review queue.
  • Automated follow-up work depends on explicit Task outcomes, not only on the Task existing.

Activity Plan Steps

Compare CREATE_TASK with the other step kinds.

Data Forms

Build the reviewer interface used by human Tasks.