Open App

Framework

How MONOid's organisation layer (containers, projects, tasks) works and when to use it

What it is

The organisation layer in MONOid is the hierarchy that structures your work: Containers → Projects → Tasks. It answers "where does this live?" and "why does it exist?" so you can scope views, filter index pages, and connect work to your week.

When to use it

  • You want to separate areas of life or work (e.g. Work, Studio, Home) and keep projects grouped.
  • You need to see lists or boards scoped to one container or one project.
  • You're planning the week and want tasks tied to projects (and projects to containers) so routine blocks and reviews make sense.

How it works

Containers are the top level; each contains projects. Projects contain tasks. Tasks can also exist without a project — for example, quick to-dos captured before you decide where they belong. Index pages (Containers, Projects, Tasks) can show everything or be scoped to a parent (e.g. "projects in this container"). The week and routine blocks then reference projects and tasks, so your plan stays aligned with your structure.

How to use it

  1. Create one or more containers (e.g. Work, Studio, Home) from the Containers index.
  2. Create projects inside a container from the Projects index (or from a container's detail page).
  3. Create tasks inside a project from the Tasks index, calendar, or project detail. Tasks can also be created without a project.
  4. Use filters and grouping on index pages to view by container or project as needed.

Key concepts / fields

  • Container — Top-level group of projects; has a name and optional notes.
  • Project — Belongs to one container; represents an ongoing effort with an outcome; can be linked to routine blocks.
  • Task — Optionally belongs to a project; has a bucket (status), dates, and can be assigned to a routine block for the week. Tasks without a project appear in "No project" groups.
  • Team (organisation workspaces) — Groups members and can be linked to containers/projects to apply access in bulk.

Common workflows

  • Set up from scratch: Create containers → add projects to each → add tasks to projects; then configure routine blocks and plan the week.
  • Scope a view: Open the Projects index and filter or group by container to focus on one area.
  • Weekly planning: Open the calendar, pull tasks from the backlog into the right routine blocks, and move between projects as needed.
  • Review and tidy: Use index pages (list/columns) to see status across containers and projects, then archive or reassign as needed.

Teams in the model

In organisation workspaces, Teams are a coordination and permission layer on top of the hierarchy:

  • Teams do not replace containers/projects/tasks.
  • Teams let you share container/project access as a group.
  • Linking teams avoids adding members one-by-one to each resource.

See Teams for setup and permission behavior.

Tips + gotchas

  • Put every project in a container so scoping and filters stay consistent.
  • If a task outlives its project, move it to another project (or a "holding" project) rather than leaving it orphaned — or let it exist without a project until you decide.
  • Use the same organisation structure when you run reviews so priorities and outcomes stay aligned.
  • Containers — Create and manage containers
  • Projects — Create and manage projects
  • Tasks — Create and manage tasks
  • Teams — Group members and apply container/project access in bulk
  • Concepts — Core MONOid concepts and terminology
  • Conventions — Index pages, detail pages, and display config