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.

Activity Plans describe how Kodexa should run a document-heavy business process. They are the reusable definition. An Activity is one run of that definition inside a project. Use Activity Plans when you need the platform to coordinate automated work, human review, external system calls, and audit history as one workflow.

​
What an Activity Plan Defines

An Activity Plan answers four questions:
  • What starts the work? A manual start, intake upload, task status change, another Activity completing, or another trigger.
  • What inputs are required? Document family IDs, project-specific values, routing hints, external reference IDs, or metadata supplied by the trigger.
  • What steps run? A graph of CREATE_TASK, SCRIPT, BRIDGE_CALL, EXECUTION, LLM, AGENT, and APPROVAL steps.
  • What result is produced? Completed tasks, updated documents, external system updates, extracted data, logs, and step results.

​
Activity Plan vs Activity

ConceptScopeWhat it means
Activity PlanOrganizationThe reusable workflow definition: inputs, step graph, defaults, and metadata
ActivityProjectOne execution of an Activity Plan with concrete inputs, status, steps, logs, and results
StepActivityOne materialized unit of work inside an Activity run
TaskProjectHuman work created by an Activity when review, correction, or approval is needed
Activity Plans are organization-level resources so the same business process can be reused across projects. A project must bind an Activity Plan before it can start Activities from it. That binding is intentional: it says this project is allowed to run this process with its document stores, task templates, data definitions, data forms, modules, and service bridges.

​
Basic Shape

An Activity Plan is usually authored as resource configuration and deployed with the rest of your Kodexa project assets. 
{
  "name": "Invoice Intake",
  "slug": "invoice-intake",
  "description": "Classify, extract, review, and post invoice data",
  "inputsSchema": {
    "type": "object",
    "required": ["documentFamilyId"],
    "properties": {
      "documentFamilyId": { "type": "string" },
      "sourceSystem": { "type": "string" }
    }
  },
  "defaultTitleTemplate": "Invoice intake for {{documentFamilyId}}",
  "steps": [
    {
      "slug": "extract",
      "kind": "EXECUTION",
      "config": {
        "moduleRef": "kodexa/invoice-extractor",
        "options": {
          "documentFamilyId": "{{inputs.documentFamilyId}}"
        }
      }
    },
    {
      "slug": "route",
      "kind": "SCRIPT",
      "dependsOn": ["extract"],
      "config": {
        "scriptActions": [
          { "name": "review" },
          { "name": "post" }
        ],
        "scriptBody": "return { action: inputs.needsReview ? 'review' : 'post' };"
      }
    },
    {
      "slug": "analyst-review",
      "kind": "CREATE_TASK",
      "dependsOn": ["route:review"],
      "config": {
        "taskTemplateRef": "invoice-review",
        "waitForCompletion": true
      }
    },
    {
      "slug": "post-to-erp",
      "kind": "BRIDGE_CALL",
      "dependsOn": ["route:post", "analyst-review:approved"],
      "config": {
        "serviceBridgeRef": "finance-erp",
        "endpointName": "post-invoice",
        "requestBody": {
          "documentFamilyId": "{{inputs.documentFamilyId}}"
        }
      }
    }
  ]
}

​
Step Graphs

Steps form a directed graph. Each step has a slug, a kind, optional dependencies, and kind-specific configuration. Dependencies can reference a step generally: 
{ "dependsOn": ["extract"] }
They can also reference a specific action emitted by a branching step: 
{ "dependsOn": ["route:review"] }
This is how a SCRIPT step, approval step, human task, or bridge call can decide which path the Activity follows next.

​
Common Step Kinds

Step kindUse it for
CREATE_TASKCreate human review, exception, approval, or correction work from a Task Template
SCRIPTRun inline JavaScript for routing, document inspection, data updates, enrichment, or custom logic
BRIDGE_CALLCall a configured Service Bridge as a first-class workflow step
EXECUTIONRun a module or automated extractor/classifier
LLMRun a prompt or prompt template and map the result into the Activity
AGENTDelegate a bounded operation to an agent runtime
APPROVALPause for approval before continuing

​
A Practical Modeling Order

  1. Start with the business process: what outcome does the organization need?
  2. Define the documents and data model: what document families and data definitions are involved?
  3. Identify the automation: extraction, classification, validation, enrichment, posting, and notifications.
  4. Identify the human work: which decisions need a Task?
  5. Identify external systems: which Service Bridges are needed?
  6. Convert that model into an Activity Plan step graph.
  7. Bind the Activity Plan and all referenced resources to the project that will run it.

Step Catalog

Learn each Activity Plan step kind and when to use it.

Create Task Steps

Create human review, correction, and exception work from an Activity.

Execution Steps

Run module-backed extraction, classification, and processing work.

Script Steps

Add JavaScript routing and business logic to an Activity Plan.

Service Bridge Steps

Call external systems as first-class Activity Plan steps.

LLM Steps

Run bounded prompts and map model output into the workflow.

Agent Steps

Delegate bounded work to agent runtimes.

Approval Steps

Model authorization gates and approval outcomes.