Projects
A Project is a shared, governed place for a piece of work: the conversations, the files, the data, and the processes that belong to it.
Audience: builders
What belongs in a Project
Think of a Project as the unit of work your team would name in a meeting. A quarterly close. An audit response. The AP help desk. A market analysis.
It holds two things from the start:
- Context. What the Project knows and can reach: files, instructions, data, knowledge, tools.
- Conversations. Where the work actually gets done, shared with the team so anyone can pick up where someone else left off.
Everything else arrives later, because the work put it there. Workflows show up when part of the work turns out to repeat. Views show up when enough people are operating the Project that they need a screen of their own.
That ordering matters more than it sounds. A Project gets better with use: corrections your team makes, memories it saves, instructions it tightens all stay with the Project, so the next cycle starts ahead of the last one. A Project configured up front and never used has none of that.
Projects are shared by default. Threads belong to the Project, not to the person who started them. That is the point: nothing important depends on what one person remembers or which window they left open.
Project or Data Collection
Both appear in the top navigation, and both are workspaces, so it is worth being clear about the difference.
A Project is organized around a piece of work. A Data Collection is organized around a set of data that several pieces of work depend on.
If you are describing something your team does, that is a Project. If you are describing data your team owns, that is a Data Collection. A Project attaches the Data Collections it needs.