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.
Who sees what
A Project's sidebar has three rails: Context, Views, and Work items. Select one at the top of the sidebar to show it.
| Rail | What it shows | Who sees it |
|---|---|---|
| Context | The Context tree: everything the Project is made of, where you author Instructions, add Workflows, attach data, and mount tools | Builders and admins |
| Views | The Project's views: the built-in Project home and any custom views. The one marked Home opens by default | Everyone who can open the Project |
| Work items | What the Project's Workflows produced, with counts for the items waiting on a decision and the ones running or queued | Everyone who can open the Project |
Your role decides what you can do. A Builder or Admin on the Project, on its team, or on the workspace sees the Context rail and the authoring controls. A Member sees Views and Work items, and can run, rerun, and retry Work items on the Project's existing Workflows. Roles are assigned in teams and permissions.
A builder opens a Project on its start page, and a member opens it on the Project's default view. A Project that already has Workflows and Work items opens on the Work items rail the first time you visit it. After that, the rail you pick is remembered per Project in your browser, and changing it does not change what a teammate sees.