Overview
Manifests are YAML files that define which resources should be deployed as part of a sync target. Each target in yoursync-config.yaml references one or more manifest files, and each manifest lists the specific resources (by slug) that belong to that deployment unit.
Manifests give you fine-grained control over what gets pushed or pulled for a given environment. By splitting resources across multiple manifests, you can share common definitions across teams while keeping division-specific or project-specific resources separate.
Manifest Format
A manifest file has the following top-level fields:manifest_version- The manifest format version (currently"1.0")metadata_dir- Optional directory where resource YAML files are stored, relative to the manifest file locationresources- A map of resource type to list of resource slugsprojects- Optional map of project slug to project-scoped resource configurationmodules- Optional list of module definition file paths (relative to thesync-config.yamldirectory)
resources: accept both canonical type names and friendly aliases (see the Resource Type Reference below).
Example: shared.yaml
A shared manifest containing resources used across the entire organization:Example: Division-Specific
A manifest for resources scoped to a specific division or team:Project-Scoped Resources
Projects listed in a manifest’sresources.projects section automatically include their nested resources (task templates, assistants, knowledge items, etc.). The project directory structure under kodexa-resources/projects/<slug>/ determines what gets synced.
Additionally, manifests support a top-level projects: section for fine-grained control over project-scoped resources:
Task Template Structure
Task templates define review tasks with UI forms, actions, and optional plan templates for orchestrating sub-tasks:Orchestration with Plan Templates
Setplanned: true to create an orchestration template that coordinates execution steps and sub-tasks:
Resource Type Reference
The following resource types are supported in manifests, along with their aliases:| Type | Aliases | Scope | Directory |
|---|---|---|---|
label | - | org | labels/ |
exceptiontype | exception-type | org | exception-types/ |
datadefinition | data-definition, taxonomy | org | data-definitions/ |
dataform | data-form | org | data-forms/ |
store | datastore, data-store | org | data-stores/ |
module | cloud-module, model | org | modules/ |
prompttemplate | prompt-template | org | prompt-templates/ |
servicebridge | service-bridge | org | service-bridges/ |
knowledgetype | knowledge-type, knowledge-item-type | org | knowledge-item-types/ |
knowledgefeaturetype | knowledge-feature-type, feature-type | org | knowledge-feature-types/ |
knowledgefeatureinstance | knowledge-feature-instance, feature-instance | org | knowledge-feature-instances/ |
knowledgeset | knowledge-set | org | knowledge-sets/ |
projecttemplate | project-template | org | project-templates/ |
project | - | org | projects/ |
assistant | - | project | assistants/ |
knowledgeitem | knowledge-item | project | knowledge-items/ |
tasktemplate | task-template | project | task-templates/ |
taskstatus | task-status | project | task-statuses/ |
workflow | - | project | workflows/ |
Push Order
Resources are pushed in dependency order — labels and exception types first, then definitions/forms/stores/modules, then knowledge resources, then projects, and finally project-scoped resources. This ensures references resolve correctly during push.
The metadata_dir Field
The metadata_dir field in the manifest controls where resource YAML files are stored relative to the manifest file location:
metadata_dir: kodexa-resources— standard convention for dedicated resource directoriesmetadata_dir: .— files stored alongside the manifestmetadata_dir: resources— alternative short name
