> ## 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 > Use CREATE_TASK steps in Activity Plans to bring people into the workflow for review, correction, approval, exception handling, or escalation. `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 ```json theme={null} { "slug": "analyst-review", "kind": "CREATE_TASK", "dependsOn": ["route:review"], "config": { "taskTemplateRef": "invoice-review", "taskStatusSlug": "open", "taskData": { "priority": "high", "sourceSystem": "{{inputs.sourceSystem}}" } } } ``` | Config key | Description | | ----------------- | ---------------------------------------------------------------------- | | `taskTemplateRef` | Task Template used to create the human work item | | `taskStatusSlug` | Initial status for the created Task | | `taskData` | Properties copied onto the Task | | `title` | Optional explicit title for the Task | | `description` | Optional explicit description for the Task | | `priority` | Optional 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. ```mermaid theme={null} sequenceDiagram participant Activity participant Step as CREATE_TASK step participant Task as Human Task participant Reviewer Activity->>Step: Dependencies complete Step->>Task: Create from Task Template Task->>Reviewer: Appears in queue Reviewer->>Task: Complete with status or action Task-->>Activity: Outcome recorded Activity->>Activity: Continue matching downstream path ``` ## 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. ```json theme={null} [ { "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: ```mermaid theme={null} flowchart LR Intake["EXECUTION: extract"] --> Route["SCRIPT: route"] Route -->|"clean"| Post["BRIDGE_CALL: post"] Route -->|"review"| Review["CREATE_TASK: analyst review"] Review -->|"approved"| Post Review -->|"rejected"| Reject["BRIDGE_CALL: notify rejection"] ``` 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. Compare CREATE\_TASK with the other step kinds. Build the reviewer interface used by human Tasks.