Processes

The lifecycle of a deployed automation — from use case folder to live process with versioning, environments, and user isolation

What is a process?

When you deploy a use case, the platform creates a process — the public, discoverable representation of your automation. Users can find, install, and run processes with their own credentials.

Each process has three layers:

Process (public listing)
  └── Deployment template (immutable version snapshot)

Process instance (user installation)
  └── Deployment instance (running copy with real workflow IDs)

Process

The top-level entity. Represents your automation on the platform.

Property	Description
Title	Display name
Description	What the automation does
Visibility	Who can see and install it
Tags	Categorization (e.g., email, ai, crm)
Process type	personal (one per user) or organizational (one per org)

Visibility levels

Level	Who can see and install
private	Only the owner
userList	Specific users
teamList	Specific teams
organizational	All members of the organization
public	Anyone on the platform

Deployment template

An immutable snapshot of a specific version. When you deploy version 1.2, the platform stores a template containing all workflow data with placeholders still present (not yet replaced with real values).

Templates are never modified after creation. A new deployment always creates a new template.

Property	Description
Version	API version (e.g., 1.0, 1.1, 2.0)
Status	inactive → published → deprecated
Workflows	Workflow metadata (triggers, schemas, integrations)

Process instance

A user’s personal installation of a process. Each user gets their own instance with isolated state and credentials.

Property	Description
Environment	dev or prod
Version	Which template version this instance runs
Active	Whether workflows are enabled
Sharing	Who in the org can use this instance
Deployment parameters	User-configured values (from INSTPARM placeholders)

Instance states

State	Behavior
Active	Fully functional, workflows execute on triggers
User paused	Visible but workflows disabled (user chose to pause)
Deploy failed	Visible but needs retry (deployment error occurred)
Missing integration	Visible but needs reconnection (OAuth token expired or deleted)
Archived	Hidden and disabled (soft-deleted)

Dev/Prod environments

Process owners get automatic environment management. By default, only one environment is active at a time:

• First deploy: Creates a dev instance, activates it
• Publish to prod: Auto-creates prod instance, deactivates dev
• Redeploy to dev: Deactivates prod, activates dev

This ensures you always test in dev before going live in prod.

Deployment instance

The running copy of a process instance with real n8n workflow IDs. This is what connects your process instance to live workflows in n8n.

Property	Description
Status	pending → deploying → deployed or failed
Workflow mappings	Links between your workflow template IDs and live n8n workflow IDs

Deployment status flow

pending → deploying → deployed (success)
                   → failed (error)
deployed → updating → deployed (version update success)
                   → failed (version update error)

Deployment pipeline

When you run codika-helper deploy use-case, the platform:

1. Validates the request (authentication, format, required fields)
2. Calculates version based on your version strategy (patch/minor/major)
3. Creates a deployment template — an immutable version snapshot
4. Creates or updates the process, process instance, and deployment instance
5. Deploys to n8n — for each workflow:
   • Replaces all placeholders with real values (credentials, parameters, IDs)
   • Creates or updates the workflow in n8n
6. Returns the deployment result (IDs, version, status)

Version updates

When a new version is published:

• Pinned instances: Users are notified that an update is available and can choose when to apply it
• Unpinned instances: Automatically updated to the new version — the platform creates a new deployment instance and updates the live workflows

If an automatic update fails, the instance falls back to showing “update available” for manual retry.

Public API access

Process instances with HTTP triggers expose a public API for triggering workflows and checking execution status. Authentication uses a per-instance API key passed via the X-API-Key header.

The codika-helper trigger and codika-helper get execution commands wrap these endpoints — you don’t need to call them directly.