Items

​

Overview

An item is the core unit of work in Ekso. Items represent tickets, tasks, bugs, features, or any other trackable piece of work. Every item belongs to exactly one container and follows a process that defines its fields, features, and workflow. Items carry standard fields like name, status, priority, and severity, plus any custom fields defined on their process. Constraints and rules can further control and automate how field values behave.

​

Item keys

Each item has a unique key composed of its container code and a sequential number — for example, SVC-23. Keys are stable identifiers you can use to reference items across the application. The container code comes from the container the item belongs to.

​

Item detail

When you open an item, its detail view displays the fields configured by its process. A typical item shows: Not all fields appear on every item. The process controls which fields are visible, and field-level permissions control who can see, set, and change each field. Items created through the ticketing pipeline display an email metadata bar beneath the field summary, showing the sender’s email address and the receiving mailbox address.

​

Item lifecycle

Each item moves through a status workflow defined by its process. The lifecycle has three broad phases: Status transitions are governed by the process workflow. Not every status can transition to every other status — the process defines which moves are valid and which user groups can make each transition.

​

Item tabs

Below the field summary, items organize related data into tabs. Which tabs appear depends on the features enabled on the item’s process.

​

Description

The description tab displays the item’s rich-text content. This is the primary space for detailed requirements, acceptance criteria, or context about the work.

​

Attachments

The attachment tab lets you upload files to the item. Use attachments for screenshots, documents, logs, or any supporting material.

​

Annotations

Annotations are threaded entries on an item used for commentary, updates, and collaboration. Unlike a simple comment field, annotations support three content types: Each annotation records who created it and when. Annotations can come from three sources:

​

Annotation visibility

Each annotation has its own Restricted To setting, independent of the item’s visibility. This means you can have a public item with private annotations — for example, internal notes on a customer-facing ticket that only the support team can see.

​

Ticket

The Ticket tab appears on items created through the mailbox ticketing pipeline. It shows the email conversation history — both inbound messages from the sender and outbound replies from agents. Each entry displays the message content, sender, and timestamp. This tab is separate from annotations. Annotations capture internal team commentary, while the Ticket tab tracks the external email conversation.

​

Time

The time tab shows time entries logged against the item. Each entry displays: Time entries are created by team members and approved through the cycle time approval process.

​

Links

Links create cross-references between items. You search for an item by keyword or number and select a link type to describe the relationship — for example, Duplicate, Related, Blocks, or Blocked By. Links work across containers. An item in SVC can link to an item in FEN, making it easy to track related work across different projects or teams.

​

Dependencies

Dependencies create parent-child relationships between items, forming a hierarchical tree. A parent item represents a larger piece of work, and its children represent the subtasks or prerequisites needed to complete it. You add dependencies by searching for items by keyword or number. Dependencies work across containers — a parent in one container can have children in another.

​

Dependency tree rules

Parent items (items with children) behave differently from leaf items: These rules ensure that work tracking and planning happen at the leaf level, while parent items serve as rollup summaries.

​

Visibility

The Restricted To field controls which user group can see an item. By default, items are visible to everyone with container access. Setting a specific group restricts visibility to members of that group only. Visibility applies at two levels:

• Item level — the Restricted To field on the item controls who can see it in lists and open its detail view
• Annotation level — each annotation has its own Restricted To setting, allowing private commentary on otherwise-visible items

This two-level model lets you keep items visible to a broad audience while restricting sensitive discussion to specific teams.

​

Filtering items

The container list view shows all items in a container. You filter items using saved filters or ad-hoc conditions.

​

Saved filters

Saved filters are predefined by container admins and appear in the filter dropdown. Common examples include “Open”, “My Work”, “Closed”, “Open or Working”, and “Owned By Me.” See Saved filters for how they are configured.

​

Ad-hoc filters

You can also build a filter on the fly using the same condition builder. Choose a field, operator, and value, then add more conditions or OR groups as needed. Ad-hoc filters are not saved — they apply only to your current session.

​

Planning items onto boards

The Plan button on an item assigns it to a board and cycle. Once planned, the item shows a “Planned” badge with a breadcrumb showing the board, cycle, and assigned resource — for example, “Dotcom Refresh > Design > Sarah Chen.” Items can only be planned onto boards that have approved the item’s container. The assigned resource must come from the board’s approved resource pool. For details on how items are tracked within cycles, see Cycles.

​

Watch, pin, and follow

You can track items you care about without being assigned to them. Ekso supports two watch types:

​

Watcher types

Watches can be created for different recipient types: See the API reference for endpoint details on watches.