Skip to main content
Project templates help you create repeatable Kodexa projects without rebuilding the same workspace setup each time. They capture the project boundary: stores, data definitions, forms, statuses, knowledge, task templates, workspace panels, and the bindings a project needs to run its Activities. Use project templates for the setup that changes by project. Keep reusable business process logic in Activity Plans so multiple projects can adopt the same process shape with different stores, data definitions, forms, permissions, and integrations.

​
What a Template Should Capture

AreaTypical template responsibility
StoresCreate the intake, review, exception, and output document stores
Data DefinitionsReference or create the structured data model for the process
Data FormsProvide the review UI used by Tasks
Task TemplatesDefine human review work that Activity Plans can create
StatusesDefine project-specific document, task, and attribute states
KnowledgeBind knowledge sets and feature types used by the process
WorkspaceConfigure panels and default project workspace behavior
ResourcesAttach service bridges, modules, prompts, and other reusable resources

​
Minimal Template

slug: invoice-operations
orgSlug: acme
version: 1.0.0
name: Invoice Operations
type: projectTemplate
description: Workspace setup for AP invoice intake and review

stores:
  - slug: "${project.id}-intake"
    name: "Invoice Intake"
    description: "Upload incoming invoices here"
    storeType: DOCUMENT
    storePurpose: OPERATIONAL

workspaces:
  - name: Review Workspace
    slug: review
    workspaceStorage:
      availablePanels:
        documentStores: true
        dataForms: true
        taxonomies: true
        exceptions: true
      overview: |-
        # Invoice Operations

        Upload documents, review extracted data, and resolve exceptions from this workspace.

​
Activity-First Project Setup

An Activity Plan should model the business process. A project template should provide the local project resources that plan needs. 
Project Template
  -> creates project stores, statuses, forms, and task templates
  -> binds reusable data definitions and knowledge
  -> prepares the workspace where people review Tasks

Activity Plan
  -> runs extraction, classification, scripts, bridge calls, LLM steps, and approvals
  -> creates Tasks when human judgment is needed
  -> records step outputs, logs, status, and audit history
This split keeps project setup reusable without hiding the process logic inside project-specific wiring.

​
Template Design Guidance

  • Start with the real business workflow, then identify the project resources it needs.
  • Put repeatable process logic in Activity Plans.
  • Put human review configuration in Task Templates and Data Forms.
  • Keep store names and slugs project-specific with ${project.id} where uniqueness matters.
  • Bind shared Data Definitions and Knowledge Sets by reference instead of duplicating them.
  • Keep workspace panels focused on repeated operator work: stores, data forms, Data Definitions, exceptions, audit trail, and navigation.

​
Next Steps

Project Template Structure

See the template fields and structure.

Build Project Templates

Build an activity-first project template.