Containers

Organize work into containers with areas, labels, processes, saved filters, and role-based access control.

Overview

A container groups related items together. Think of it as a project, product, service line, or team workspace. Every item belongs to exactly one container, and containers are the primary organizational boundary for work management in Ekso.

Containers define the structure for the work inside them: which processes are available, how items are categorized with areas and labels, and who has access.

Container settings

Container configuration is split across five tabs under Settings:

Tab	Purpose
Detail	Name, code, description, label, owner, and container-level toggles
Area	Sub-groupings for organizing items within the container
Filter	Predefined filters shared with all container users
Access	Role-based permissions for user groups
Process	Item types available in the container, with field-level access control

Detail

The Detail tab captures the container’s identity and high-level controls.

• Name — the display name shown in container lists and navigation
• Code — a short identifier (up to four characters) used as the prefix for item keys. A container with the code SVC produces items like SVC-1, SVC-2, SVC-3
• Description — a rich-text summary of the container’s purpose
• Label — a category tag displayed next to the container name in lists (for example, Service, Product, or Support)
• Owner — the person responsible for the container
• Archived — hides the container from default views and prevents changes while preserving its data
• Deleted — removes the container from the system

The Sequence button in the top-right corner renumbers all items in the container to remove gaps caused by deletions.

Item numbering

Items within a container are numbered sequentially using the container code as a prefix. For example, SVC-1, SVC-2, SVC-3. This gives every item a unique, human-readable identifier across the entire tenant.

Areas

Areas are sub-groupings within a container. You use them to organize items by feature, module, component, or team area — whatever subdivision makes sense for your work.

Each area has a name and description. For example, a “Consulting Services” container might have areas for “Implementation” and “Maintenance.”

An item can belong to at most one area. Areas are scoped to a single container, so each container defines its own area structure independently.

Labels

Labels are flat tags defined globally and shared across all containers. Unlike areas, labels are not scoped to a single container. An item can have multiple labels.

Use labels for concerns that span containers — for example, security, documentation, or urgent. Use areas for structure that is specific to a single container.

Processes

Processes define item types within a container. A process controls the fields, features, workflow transitions, and permissions for items that follow it. When you create an item, you choose which process it follows — for example, Defect, New Feature, Enhancement, Change Request, or Task.

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 — you can rename them, adjust their fields, change their workflows, or delete the ones you do not need.

A container can run multiple processes simultaneously. This means a single container can track defects, change requests, and tasks — each with their own fields, features, and workflow rules. You manage processes under Settings > Process. Each process can be enabled or disabled for the container, and each has an Access button for configuring field-level permissions.

Each process has five configuration tabs — Fields, Features, Workflow, Clone, and Detail — that control everything about the item type. See Process for full details.

Field-level access control

Each process in a container has a field-level permission matrix that controls which user groups can see, set, and change each field. Navigate to the container’s Process tab and click the Access button next to the process you want to configure. See Process — field-level access control for the full explanation.

Saved filters

Container admins can define saved filters that are shared with all users in the container. Saved filters provide quick access to common views like “Open”, “My Work”, “Owned By Me”, or “Working.”

Each saved filter has:

• Name — displayed in the filter dropdown on the container list view
• Active — whether the filter appears in the dropdown for all users
• Filter conditions — the query criteria that define the filter

Filter conditions

A filter is built from one or more condition groups joined by OR logic. Within each group, conditions are joined by AND logic. Each condition specifies:

Part	Description
Field	The item field to evaluate (for example, Status, Severity, Resource)
Operator	The comparison type (Equal, Not Equal, Contains, Starts With, Ends With, Less Than, Greater Than, and variants)
Value	The target value to compare against

Filters also support:

• Sort — choose a field to sort results by (for example, Name, Status)
• Include closed — toggle whether closed items appear in results

Users select saved filters from the dropdown on the container list view. They can also build ad-hoc filters using the same condition builder without saving them.

Create filters for your team’s most common views. A “My Work” filter using Resource Equal Me helps team members quickly find their assigned items.

Access control

The Access tab sets container-level permissions by assigning roles to user groups. Eight roles control what users can do:

Role	Permission
View	Can view and interact with the container
Add	Can add new items to the container (subject to process access rules)
Filter	Can filter items within the container (subject to process access rules)
Manage	Can perform any operation within the container
Change	Can change items within the container (subject to process access rules)
Change Own	Can change own items within the container (subject to process access rules)
Delete	Can delete items within the container (subject to process access rules)
Delete Own	Can delete own items within the container (subject to process access rules)

Each role is granted to one or more user groups via the Access button next to each role.

Container permissions work alongside process field-level permissions. A user needs both container-level access and process-level field access to interact with an item.

Secure containers

Ekso supports secure containers — containers where access is strictly enforced, even for Super Admins. If a Super Admin does not have explicit access to a secure container, they cannot see or manage it. This enables confidential workspaces for sensitive work like HR investigations, legal matters, or security incidents.

A secure container is invisible to users without access, including Super Admins. Make sure at least one admin has access before restricting a container.