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

# Process

> Define item types with configurable fields, features, workflow transitions, and field-level permissions.

## Overview

A process defines an item type — its fields, features, workflow, and permissions. When you create an [item](/guide/concepts/items), you choose which process it follows. That choice determines which [fields](/guide/concepts/fields) appear, which capabilities are available, and how the item moves through status transitions.

You manage processes under **Settings > Process**. Creating, editing, and deleting processes requires the **Super Admin** role. All other users can view process configurations but cannot change them.

Each process has five configuration tabs:

| Tab      | Purpose                                                                                   |
| -------- | ----------------------------------------------------------------------------------------- |
| Field    | Choose which fields appear, set display order, and mark fields as required                |
| Feature  | Toggle capabilities like annotations, attachments, dependencies, links, and time tracking |
| Workflow | Define status transitions and control which user groups can make each move                |
| Clone    | Copy a process as a starting point for a new one                                          |
| Detail   | Configure the process name, description, and icon                                         |

Every item follows exactly one process. A single [container](/guide/concepts/containers) can run multiple processes simultaneously — for example, tracking defects, change requests, and tasks each with their own fields, features, and workflow rules.

## Default processes

Every new tenant comes with five default processes:

| Process        | Description                          |
| -------------- | ------------------------------------ |
| Defect         | Defect triage and management         |
| New Feature    | Introducing additional functionality |
| Enhancement    | Improving existing functionality     |
| Change Request | Change request management            |
| Task           | General task management              |

All five share the same default workflow and field set. They are fully editable — rename them, adjust their fields, change their workflows, delete the ones you do not need, or create entirely new processes using the **+** button.

## Fields

The **Field** tab controls which [fields](/guide/concepts/fields) appear on items of this type, their display order, and whether they are required.

* **Add or remove fields** — select from system fields and custom fields using the dropdown, then click **Add**
* **Set required** — toggle the **Required** switch to make a field mandatory when creating or editing an item
* **Reorder** — use the arrow buttons to control the order fields appear on-screen
* **Always present** — some fields are always included and cannot be removed: CreateDate, ChangeDate, CreateBy, ChangeBy, RecordSource, EmailGuid, Name, Description, RestrictedTo, OwnedBy, and Status. When you create a new process, these eleven fields are added automatically.

Every process must have at least **11 fields**. You cannot save a process with fewer than the mandatory set.

The same field can behave differently across processes — required in one, optional in another, or absent entirely. For example, you might require Severity on the Defect process but leave it optional on Task. The Required flag applies when creating and editing items — it does not affect the view screen.

The field display order you set here applies uniformly across all three screens (add, update, and view). If you remove a field from a process, that change automatically propagates to every container that uses the process.

<Tip>
  See [Fields](/guide/concepts/fields) for details on system fields, custom field types, and how field values are used across the application.
</Tip>

## Features

The **Feature** tab toggles which capabilities are enabled for the process. Each feature can be independently turned on or off:

| Feature    | What it enables                                                 |
| ---------- | --------------------------------------------------------------- |
| Annotation | Add annotations to items (text, embeds, code snippets)          |
| Attachment | Upload file attachments to items                                |
| Dependency | Create parent-child dependency trees between items              |
| Link       | Create cross-reference links between items (duplicate, related) |
| Time       | Log [time entries](/guide/concepts/time-tracking) against items |

When you create a new process, all five features are enabled by default.

<Tip>
  Disable features you do not need for a process. For example, a simple task process may not need dependencies or time tracking, keeping the interface clean for users.
</Tip>

## Workflow

The **Workflow** tab defines status transitions — which status an item can move to from its current status, and who is allowed to make that transition.

Each transition rule specifies:

| Column | Description                                           |
| ------ | ----------------------------------------------------- |
| Status | The current status of the item                        |
| Next   | The status the item can transition to                 |
| Groups | Which user groups are allowed to make this transition |

Ekso recognizes four status types that categorize where an item is in its lifecycle:

| Status type | Meaning                                                     |
| ----------- | ----------------------------------------------------------- |
| Open        | Item has been created and is ready for triage or assignment |
| Working     | Item is actively being worked on                            |
| Closed      | Item has been resolved or completed                         |
| Blocked     | Item cannot progress and is waiting on something            |

When you create a new process, Ekso generates a default set of transitions: Open → Working, Working → Open, Working → Closed, and Closed → Working — all available to Everyone.

For example, after customization, a Defect process might define these transitions:

* Open → Assigned (Everyone)
* Assigned → Open (Everyone)
* Assigned → Closed (Everyone)
* Closed → Assigned (Everyone)

Every process must have at least **3 workflow transitions**. Add new transitions using the **New Transition** row at the bottom of the list. Each dropdown lets you pick from the available statuses and user groups.

<Note>
  User groups control who can make each workflow transition. This means you can restrict certain status changes to specific teams — for example, only QA can move items to "Verified", or only managers can close items.
</Note>

## Field-level access control

Each process in a container has a field-level permission matrix that controls which user groups can interact with each field. The matrix has three columns:

| Column | When it applies                                              |
| ------ | ------------------------------------------------------------ |
| See    | When viewing an item — controls whether the field is visible |
| Set    | When creating an item — controls who can provide a value     |
| Change | When updating an item — controls who can modify the value    |

For each field in the process, you assign a user group to each column. This lets you show a field to everyone but only allow managers to change it, or hide sensitive fields from certain groups entirely.

Field-level access is configured per process, per container. Navigate to the container's **Process** tab and click the **Access** button next to the process you want to configure. By default, all fields are set to **Everyone** for all three columns.

<Note>
  Field-level permissions work alongside [container-level access control](/guide/concepts/containers#access-control). A user needs both container-level access and process-level field access to interact with an item. See [Access control](/guide/concepts/access-control) for the full permission model.
</Note>

## Clone and detail

* **Clone** creates a copy of the process as a starting point for a new one. This is the fastest way to create a new process that shares most of its configuration with an existing one.
* **Detail** configures the process name, description, and icon displayed in process lists and item headers.

## Content templates

Processes support content templates that pre-fill descriptions or checklists when creating new items. Templates are scoped to a specific container and process combination — so you can have different default content for Defect items in your "Support" container versus your "Engineering" container.

## Process and containers

Processes are global templates defined under **Settings > Process**. Containers enable or disable individual processes via their **Process** tab. This means:

* A process is configured once and can be used across multiple containers
* Each container chooses which processes are available for creating items
* Field-level access control is configured per container, allowing different permission rules for the same process in different containers

Changes to a process cascade to all containers that use it. If you remove a field from a process, it is removed from every container's configuration for that process. If you delete a process entirely, it is removed from all containers.

<Warning>
  Deleting a process affects every container that uses it. Check the process stats on the **Settings > Process** page to see how many items currently follow a process before removing it.
</Warning>

See [Containers](/guide/concepts/containers) for details on container settings, areas, labels, saved filters, and role-based access control.