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.
An Activity is how Kodexa represents a real business process in motion.
It is bigger than a Task. A Task is a unit of human work inside the process. An Activity is the process run itself: the thing that carries work from a business trigger to a trusted outcome.
For document-heavy workflows, the Activity is where Kodexa keeps the automation, human review, institutional knowledge, integrations, results, and audit trail aligned.
Start With The Business Process
When you model work in Kodexa, start by naming the Activity in business terms:
| Real-world process | Kodexa Activity |
|---|
| Invoice intake and three-way match | Receive invoice, extract fields, match PO and receipt, route exceptions, post result |
| Loan packet intake | Classify packet, extract covenant data, validate completeness, route exceptions |
| Claims intake | Classify claim documents, extract loss details, validate evidence, assign review |
| KYC review | Collect identity documents, extract entities, check lists, create case or exception |
Activity, Task, Activity Plan
These concepts work together, but they are not interchangeable.
| Concept | Meaning | Example |
|---|
| Activity Plan | The reusable definition of how work should run | ”AP invoice three-way match” |
| Activity | One run of that plan inside a project | ”Run invoice match for document family 8f2…” |
| Activity Step | One configured operation inside the run | Extract, classify, call bridge, create task, approve |
| Task | A unit of human work created when judgment is needed | Analyst reviews mismatched vendor fields |
| Project | The workspace that binds plans to documents, data definitions, forms, queues, permissions, and integrations | North America AP project |
What An Activity Carries
An Activity gives business process state a first-class shape.
| Area | What it answers |
|---|
| Inputs | What document, document family, task, project, data definition, or context started the work? |
| Step graph | Which automated operations need to run, and in what order? |
| Dependencies | What must finish before another step can start? |
| Runtime state | What is pending, running, waiting, complete, failed, or canceled? |
| Human judgment | Where should the Activity pause and create a Task? |
| Results | What data, decision, exception, status, or external action came out of the run? |
| Audit | What happened, who or what changed state, and when? |
Activity Lifecycle
A typical Activity moves through this shape:
The Activity owns the process state. The Task owns the human work item. When the Task is completed, rejected, escalated, or routed, the Activity can continue or branch based on that result.
Tasks Are Part Of Activity
Tasks belong inside the Activity mental model. They are the explicit human-work points in an Activity, not a separate way to model the business process.
Activities create Tasks when the workflow reaches a point that should not be fully automated.
Examples:
- The extraction confidence is low and an analyst needs to review fields.
- A vendor match conflicts with ERP data and AP needs to decide which record is correct.
- A loan packet is missing a document and a credit analyst needs to request remediation.
- A sanctions check returns a possible match and compliance needs to resolve it.
The Task should not contain the whole business process. It should contain the human decision point, and the Activity should continue or branch after that decision is made.
How Activities Work With Projects
Activity Plans are reusable organization-level process definitions. Projects bind those plans to the resources needed for a specific business use case:
- Document stores and document families
- Data definitions and data forms
- Task templates, queues, and statuses
- Modules, prompts, Service Bridges, and integrations
- Permissions, users, and teams
That binding is what lets the same business process shape run across different teams or business units without rebuilding the process every time.
Design Rule
Ask this first:
What business process should Kodexa carry forward from unstructured input to trusted outcome?
That answer is usually the Activity.
Then ask:
Where does the process need a person to make a judgment, resolve an exception, or approve the next move?
Those points are Tasks.
Next Steps
- Tasks explains the human work surface inside an Activity.
- Data Forms explains the review UI that a Task uses inside an Activity.
- Projects explains where Activity Plans are bound to documents, forms, queues, permissions, and integrations.
- Activity Plans explains how to define the reusable process.
- SCRIPT steps explains how custom Activity logic runs inside a plan.
