Skip to content

Workspaces, Spaces & Lists

Hule organises everything in a three-level hierarchy:

Workspace
  └── Space
        └── List
              └── Task

Each level has a distinct purpose and ownership boundary.

Workspace — the tenant boundary

A workspace is a fully isolated container. Tasks, spaces, lists, views, tags, members, and settings inside one workspace are invisible to another.

Think of a workspace as a separate organisation. Use cases:

  • Personal workspace — your private tasks, no sharing needed.
  • Team workspace — shared with colleagues, with its own membership.
  • Client workspace — if you freelance, one workspace per client keeps data separate.

Every workspace has exactly one owner (the creator). The owner controls membership and sharing. Members must have an active Hule account and be explicitly invited.

Workspace-level features:

  • Members and invitations.
  • Tags (shared across all spaces/lists in the workspace).
  • Recurring jobs.
  • Automations (actions).
  • Notification settings (per-user, stored in the workspace context).

Data isolation

All workspace-scoped entities carry a workspaceId field. Every database query filters by it — even if a guard has already verified membership, the query won't accidentally return data from another workspace. This is defence in depth, not redundancy.

Space — a grouping layer

A space is a named group of lists. It has no tasks directly — tasks live in lists inside the space.

Spaces exist because a flat list of lists becomes unwieldy past a certain size. They let you organise lists by:

  • Area: "Engineering", "Design", "Marketing"
  • Project: "Mobile App v2", "Website Redesign", "Q3 Campaign"
  • Context: "Work", "Personal"

Spaces are the unit of sharing. When you share a space with a member, all lists and views inside it are shared automatically at the same access level.

List — the task container

A list holds tasks. Every task belongs to exactly one list. Each list has its own status template — the set of status values available for tasks in that list.

A list can be moved between spaces (drag it in the sidebar). Moving a list moves all its tasks with it.

Lists have a status template assigned at creation. You can switch to a different template later — existing tasks keep their current status values, but the available statuses for new tasks change.

Status templates

A status template defines what status values exist in a list and which group each belongs to. There are three kinds:

KindDescription
SystemBuilt-in templates (type: system). Cannot be modified or deleted. Available to all workspaces.
SharedCustom templates created in your workspace, reusable across lists.
InlinePrivate to one list. Doesn't appear in the shared pool. Can be promoted to shared later.

Each status has a group that determines its behaviour:

  • Open — not yet complete (e.g. To Do, Backlog).
  • In Progress — actively being worked on (e.g. In Progress, In Review).
  • Closed — finished or discarded (e.g. Done, Cancelled).

The hierarchy in action

When you create a workspace from scratch (or after import), the typical structure looks like:

My Workspace
  ├── Personal
  │   ├── To Do
  │   ├── In Progress
  │   └── Done
  └── Work
      ├── Backlog
      ├── This Week
      └── Waiting

You can rename, reorder, and restructure at any time. The hierarchy is a tool, not a constraint.