Project Templates Concept

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

Area	Typical template responsibility
Stores	Create the intake, review, exception, and output document stores
Data Definitions	Reference or create the structured data model for the process
Data Forms	Provide the review UI used by Tasks
Task Templates	Define human review work that Activity Plans can create
Statuses	Define project-specific document, task, and attribute states
Knowledge	Bind knowledge sets and feature types used by the process
Workspace	Configure panels and default project workspace behavior
Resources	Attach 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.

Introduction

Activity

Knowledge System

Organization & Projects

Resources

Modules

What a Template Should Capture

Minimal Template

Activity-First Project Setup

Template Design Guidance

Next Steps

Project Template Structure

Build Project Templates

​What a Template Should Capture

​Minimal Template

​Activity-First Project Setup

​Template Design Guidance

​Next Steps

Project Template Structure

Build Project Templates

What a Template Should Capture

Minimal Template

Activity-First Project Setup

Template Design Guidance

Next Steps