> ## Documentation Index
> Fetch the complete documentation index at: https://doc.codika.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

* **First deploy:** Creates a `dev` instance, activates it
* **Publish to prod:** Use `codika publish <templateId>` to promote a deployment. Auto-creates a `prod` instance.
* **Redeploy to dev:** Updates the `dev` instance with new workflows

By default, both dev and prod instances run simultaneously after publishing. Use `--auto-toggle-dev-prod` with the publish command to pause dev when prod is active.

Use `codika list executions <instanceId>` to view recent executions for either environment — pass the dev or prod instance ID.

### Rerunning a deployment without versioning

Sometimes you need to change deployment parameters (e.g., company name, language, timezone) without creating a new template version. The `codika rerun deployment` command handles this:

* **Parameters are merged** — you only pass what changed; existing parameters keep their values
* **No new template** — the instance continues running the same template version
* **Uses owner credentials** — workflows are redeployed with the instance owner's integration bindings
* **Retry failed deployments** — failed instances can be retried without `--force`

This is useful after publishing to production when you need to adjust configuration, or when a deployment fails and you want to retry with the same or updated parameters.

```bash theme={null}
# Change a parameter on the dev instance
codika rerun deployment --param LANGUAGE=fr

# Retry a failed deployment
codika rerun deployment --environment dev

# Update prod parameters
codika rerun deployment --environment prod --param COMPANY_NAME="New Corp" --force
```

See the [`codika rerun deployment` reference](/operations/rerun-deployment) for full details.

## 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 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 trigger` and `codika get execution` commands wrap these endpoints — you don't need to call them directly.