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, you choose which process it follows. That choice determines which 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 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 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.

See Fields for details on system fields, custom field types, and how field values are used across the application.

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 against items

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

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.

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.

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.

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.

Field-level permissions work alongside container-level access control. A user needs both container-level access and process-level field access to interact with an item. See Access control for the full permission model.

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.

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.

See Containers for details on container settings, areas, labels, saved filters, and role-based access control.