Skip to content

How Initiative is organized

Initiative has a simple shape underneath it. Once you picture how the pieces nest together, everything else clicks into place.

The big picture

Think of it like a building with nested spaces:

graph TD
  G["🏠 Guild<br/>(your group's workspace)"]
  I1["📁 Initiative<br/>(a big effort)"]
  I2["📁 Initiative"]
  P1["📋 Project<br/>(a task board)"]
  P2["📋 Project"]
  D1["📄 Documents"]
  T1["🛠️ Tools<br/>(calendar, queues,<br/>counters, dashboards)"]
  TASK["✅ Tasks"]

  G --> I1
  G --> I2
  I1 --> P1
  I1 --> P2
  I1 --> D1
  I1 --> T1
  P1 --> TASK

From biggest to smallest:

  1. Guild — the whole workspace for one group of people.
  2. Initiative — a folder inside a guild for one big effort.
  3. Projects, documents, and tools — the actual work, kept inside an initiative.
  4. Tasks — the individual to-dos on a project's board.

Let's take them one at a time.

You don't have to set all this up

Creating a guild gives you an initiative and somewhere to put your first project straight away. Most groups run on one guild, one initiative, and a couple of projects for a long time — and only reach for the rest when a real need turns up.

Guild — your group's workspace

A guild is the outermost container: one separate space for one group of people. Your business, your volunteer committee, and your neighborhood association would each be their own guild.

Guilds don't mix. Nothing in one guild is visible from another, even on the same server. You can belong to several guilds and switch between them from the guild rail down the left edge of the screen — but each is its own sealed world.

Within a guild there are just two member levels: admin (runs the place) and member (takes part). More in Working with guilds.

A real example

"Riverside Players" is a community theater group. They make one guild for everything they do together. Inside it, they'll create initiatives for each production.

Initiative — a big effort

An initiative is a folder for a major undertaking, gathering all its related projects, documents, and tools in one place. It's the level where you decide who's involved and what they can do.

Why have this middle layer? Because real groups juggle several efforts at once, and not everyone needs to see all of them. Initiatives let you keep each effort tidy and give the right people access to the right things.

Continuing the example

Riverside Players creates an initiative called "Spring Play: Our Town." Inside it go the rehearsal-schedule project, the budget spreadsheet, the script document, and the performance calendar. Only the people working on the spring play are added to it — the folks doing the summer show don't need to see it.

Every guild comes with one Default Initiative so you always have somewhere to start. You can add as many more as you need.

People are added to an initiative as members, and each member is given a role (like "Director" or "Cast") that decides which kinds of tools they can use. See Initiative roles.

Projects and tasks — getting work done

A project is a board for tracking work. It holds tasks — the individual to-dos — and lets you see them in whatever way suits you: a simple Table, a drag-and-drop Kanban board, or a Calendar. The same work, three ways of looking at it, so nobody has to think about it the way someone else does.

A task can have a description, a status (like "To Do" or "Done"), a priority, start and due dates, people assigned to it, subtasks, and tags. Tasks are where the day-to-day happens. See Projects & tasks.

Documents — writing things down

A document lives inside an initiative and holds knowledge: meeting notes, a plan, a script, a budget spreadsheet, or a whiteboard for the things that are easier drawn than written. Documents can be written and edited together, in real time, so two people can work on the same page — or the same canvas — at once. You can also upload files (PDFs, Word, images) as documents. See Documents.

Tools — added when you need them

Beyond projects and documents, each initiative can use extra tools:

  • Calendar & events — schedule things, invite attendees, and send reminders.
  • Queues — keep track of whose turn it is (rotations, rosters, running orders).
  • Counters — track numbers that go up and down (tallies, scores, budgets).
  • Dashboards — a single screen of charts, numbers, and timelines built from your own data.

You don't have to use any of these — they're there when you need them. See Tools.

Apps — what the community has already built

Some of what a group needs isn't in the list above, and doesn't have to be. Initiative has a marketplace of ready-made dashboards and apps built by people solving the same problems. Adding one takes a couple of clicks: pick a listing, choose where it goes, name it.

What's on offer is what ships with Initiative plus what the person running your server has approved — so the catalog is curated by someone you can ask about it.

Dashboards land in an initiative like any other tool. Apps are added at the guild level by a guild admin, because they add something the whole guild shares. See Apps & the marketplace.

The other half: people and access

Everything above is about where things live. The other half of the picture is who can see and do what. Initiative layers access from the outside in, and it's surprisingly intuitive:

Layer The question it answers
Guild Are you a member of this group at all?
Initiative Are you part of this particular effort?
Initiative role What kinds of tools are you allowed to use here?
Sharing For this specific project or document, can you view it, edit it, or own it?

Each layer sits inside the one above it. You can only reach a document if you're in its guild, and in its initiative, and it's been shared with you. The practical upshot: the only people who ever see something are the people you deliberately put in front of it. We explain this in friendly detail in Sharing & access, and in technical depth in Security & privacy.

For the technically minded — these four layers are enforced in the database

The four layers above aren't just interface conveniences. The guild layer is structural: each guild's content lives in its own PostgreSQL schema, and a request is routed into one guild's schema and can't address another's. The initiative, role, and sharing layers are enforced inside that schema by PostgreSQL's row-level security, evaluated on every statement — so a bug in the app can't quietly hand someone data they shouldn't see. There are also two overrides: a guild administrator always has full access within their own guild, and platform staff can be granted temporary, time-limited, audited access for support — never a standing back door. The full model is in How your data is kept separate.

Where to go next