Rich-text descriptions
Headings, fonts, colors, lists, tables, images and uploaded video; uploads are virus-scanned and SVG is refused by design.
TASKS
Plan the work. Order the board. Let the rules do the boring part.
Internal work lives on the same engine as customer requests: kinds with their own workflows, a kanban that holds the exact order you gave it, projects that mirror your org chart, and if-this-then-that rules with a full run history.
KINDS & WORKFLOWS
A task is not a ticket.
A task is not a ticket.
The board knows the difference.
Every kind of work carries its own statuses and its own workflow. On the board, only the grip handle starts a drag, a click on the title opens the item, and a move the workflow forbids snaps back with the reason why.
- Kinds. Work-item kinds - for example Task, Issue and Ticket - each with its own statuses and workflow.
- The board. Drag-and-drop kanban: only the grip handle starts a drag, clicking a title opens the item; illegal moves snap back with an explanation.
- Beyond the board. List, Timeline, Calendar and Dashboard views over the same items; portfolios and goals/OKRs; multi-homing (one item in several projects, counted once); tags, custom fields.
Clocks, escalation and the customer's history live on Ticketing
KANBAN · REAL ORDERING
Drop a card between two others. It stays there.
Ordering here is not a sort that reshuffles behind your back: the position you gave a card is saved with the move. Work-in-progress limits warn when a column overfills, and sections give a project its own buckets.
- Real ordering. Manual ordering is real and persistent: a card dropped between two others keeps that exact board position (status + rank saved in one server transaction, optimistic on the client).
- WIP limits. Custom board columns with work-in-progress limits: the header counts "3 / 5" and an Over WIP limit badge appears when a column exceeds it.
- Sections. A project board groups by Status or by Sections - your own buckets like "This week" - with inline add, drag between sections, and add/rename/reorder of sections.
- Saved views. Named filter presets with a visibility you pick - Private, Brand or Organization.
AUTOMATIONS
If this, then that.
If this, then that.
And a record of every time it ran.
A rule is a trigger, conditions that must ALL match, and actions that run in order - through the same service layer a person uses. Every evaluation lands in Run history, including the times a rule chose not to fire.
fires once per item per action
depth cap 8
action cap 500
Automation actions pass the same workflow guards a person does, and land in the audit log as the automation actor.
- The shape. Automations are Trigger -> Conditions -> Actions. Triggers: item created, status changed, item updated, comment created. Conditions are field-operator-value (equals, not equals, in, contains, is set, is empty) and ALL must match. Actions run in order: set status (workflow-validated), assign, set priority, set a custom field, add a comment (defaults to internal), add a watcher.
- No side doors. Automation actions go through the exact same service layer a human uses, land in the audit log stamped as the "automation" actor.
- Loop safety. Loop safety is built in: a rule fires at most once per item per originating action, cascades are capped at depth 8 and 500 total actions, and the engine records why it stopped.
- On the record. Every rule evaluation is recorded in Run history: Applied, Skipped (duplicate), Skipped (chain-depth cap), No match, or Error with the reason; runs in one cause-and-effect chain share a chain reference.
- Deliberate scope. A rule's scope is deliberate: no brand = the whole organization, a brand set = only that brand's items.
PROJECTS & CONTAINERS
From a two-week sprint to a four-level org tree.
Containers scope the board: boards and sprints, nestable, picked from one selector. Larger organisations get a four-level tree over the same items - pick a node, and the board shows exactly that slice of the work.
- Containers. Boards and sprints, nestable (a sprint inside a board); the Container selector scopes the board.
- Hierarchy. A four-level hierarchy - Department, Team, Project, Section - scopes the same board for larger organisations.
- Sections. A project's own buckets, like "This week".
- Shareable state. The view state lives in the URL, so a copied link shows the same board.
ASSIGNEES · SUBTASKS · FOLLOWERS
Many hands. One owner of record.
An item can carry many people, but exactly one wears the star: the PRIMARY assignee, the owner of record for routing and reports. Subtasks are real work items underneath, and collaborators follow along without owning anything.
- One PRIMARY. Multiple assignees with exactly one PRIMARY (starred) - the owner of record for routing and reports; co-assignees work it too.
- Subtasks. Real child work items with their own status, assignee and history; a parent with children is protected from deletion.
- Collaborators. They follow an item's activity without owning it; watchers get notified per their own preferences.
- Routing. Routing picks an owner in two steps: first narrow to eligible agents (right brand, online, under capacity, holding every required skill), then the strategy chooses - round-robin, least load, skills match, or priority order. A fallback assignee catches the nobody-eligible case; nothing is force-assigned to someone offline.
- Availability. Agents set their own availability (online / away / offline) and a personal open-items cap; routing honors both.
RICH ITEMS
Steps, tables, screenshots, video.
Steps, tables, screenshots, video.
On the item, not around it.
A work item holds the whole story: a rich description, previews of everything attached, and a history of every change - restorable, never rewritable.
Previews, in-app
Attachments with inline previews - PDF, images, video, Word (.docx), sandboxed HTML and plain text - rendered in-app, nothing leaves the platform.
History with restore
Immutable per-item history with restore. Every version stays on the record - restoring an old one never erases the trail.