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 |
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 |
- 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) |
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.
