Skip to main content
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.
An Activity run carries a document-heavy business process from trigger to outcome

​
Start With The Business Process

When you model work in Kodexa, start by naming the Activity in business terms: The Activity should describe the work the platform is responsible for carrying forward. The Task should describe the point where a person needs to participate.

​
Activity, Task, Activity Plan

These concepts work together, but they are not interchangeable. The Activity Plan is the reusable definition. The Activity is the running instance. The Task is the moment a person needs to make a decision inside that run.

​
What An Activity Carries

An Activity gives business process state a first-class shape. This is why Activity is a larger concept than document extraction. Extraction may be one step inside the Activity. The Activity is the coordinated business process around it.

​
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.