Project settings

Each project has its own Settings, organised into tabs. The tabs run down the left of the page (across the top on a phone — swipe it sideways for the rest) and stay in view as you scroll, so you can switch tab from anywhere on a long one. You can deep-link to a tab with ?tab= in the URL, and most setup flows send you straight to the right one.

General

The project’s core details — its name, code, status, the client and programme it belongs to, and the project aliases that help route incoming items to it. Retiring or deleting the project also happens here, at the bottom of the tab.

Retiring a project

When a project finishes, set its status at the bottom of the General tab:

• Active — in flight. This is the default, and the only status the Projects list shows unless you change its status filter.
• Closed — delivered and handed over. The work finished.
• Archived — shelved without finishing: cancelled, superseded, or on ice.

Closed and Archived behave the same way; the difference is what you’re recording. Either one takes the project off the Projects list and out of the sidebar’s project switcher, drops its items out of My Work, and stops the nightly sweeps (hygiene, advisories, themes) running against it. Nothing is deleted: the project’s pages, files, registers, chat and search all keep working, and setting it back to Active resumes everything.

To find a retired project again, open Projects and change the status filter from Active to All statuses, Closed, or Archived. The switcher lists live work only, so a retired project won’t appear there.

You need the projects: write permission to change the status — a project manager, co-manager or client lead has it. If you don’t, the tab shows the current status without the controls.

Deleting a project

Deleting is permanent and there is no undo. It removes the project and everything on it — every ingested item, filed document, transmittal, risk, issue, decision, action, meeting note, financial document, stakeholder, note and tender. There is no archive copy afterwards.

Almost always, Archived is what you want instead: it takes the project out of your way and keeps the record.

If you really do need to delete — a test project, or one created by mistake — open the red Danger zone at the bottom of the General tab and choose Delete this project…. Before anything happens you’ll see exactly how many records would be destroyed, and you have to type the project’s code to unlock the button.

Two things will stop a delete:

• Sub-projects. A project with sub-projects nested under it can’t be deleted. Un-nest or delete those first.
• Permission. Deleting is workspace admins only. Being a project manager, co-manager or client lead is not enough — those roles archive and close, which is what finishing a project needs. If you aren’t an admin the Danger zone doesn’t appear at all. An admin can hand the projects: delete permission to a role deliberately in Roles & permissions, but no role has it by default.

The uploaded files go too. The confirmation tells you how many stored files are involved, and they are erased from the underlying storage within a few minutes of the delete — you don’t need to ask anyone to clean up afterwards.

Team

The people on the project and their roles. A role sets what each member can see and do — the built-in roles are project manager, co-manager, client lead, finance, consultant, viewer, and client viewer. Roles are assigned here per project; the role-to-permission mapping itself lives in Roles & permissions.

Note

Workspace admins can open every project even without a member row here. If someone can’t see a project, add them on this tab.

Every member row also names the company the person is on the project for, chosen in the Company field when you add them. It defaults to your own company (the workspace’s consultancy) — a workspace member is almost always one of your people — and offers every company in the workspace, so a managing consultancy’s staff go under that consultancy and a client’s staff under the client. The company matters beyond the label: a task given to a company is announced to the people whose member rows sit under it, the Tasks page’s Task settings → Who runs this list grants closing to the members of the company named there whose role can edit tasks, and a company’s own tasks show to its people even above their clearance level (never inside a private pocket) — to the people whose rows sit under that company. Your own company is offered as a task’s owner on every project whether or not anyone’s row sits under it, but a colleague filed under the client is treated as the client’s on that project: told of the client’s tasks, not yours, with replies stamped as the client’s. A person holds one role on a project, under one company: adding them a second time — under another company, say — is refused, naming the role and company they already hold. To change someone’s company, remove the row and add them again under the right one.

Delivery partners are not members: they work from their own portal and are added on the project’s Partners page, never here.

When someone leaves the workspace

Only people in your workspace can be added here. People join and leave the workspace from the workspace switcher at the top of the app (Manage, then Members), where you invite them — not from this tab. When you remove someone there:

• they lose access straight away, everywhere — the app, the Claude connector and any API token of theirs;
• their roles on every project are removed too, and each removal is written to the audit log.

If you invite them back later, they start with no projects. Add them to each project they need on this tab again. (Someone removed before this changed may still have old roles on some projects. They can’t use them while they’re out of the workspace, but if you invite them back, check this tab on their projects.)

Connections

Where you connect the project’s input sources — email aliases, Slack channels, and ClickUp — and run their backfills. See Connecting your tools for the per-source how-tos.

Methodology

The project methodology — PMBOK, ISO 19650, or Agile. Your choice drives the set of deliverables the project can generate, and you can switch it later. See Documents for what it controls.

Modules

Turn feature modules on or off for this project. Disabling one stops new processing and hides it from the sidebar but keeps existing data — see Modules.

Import data

The onboarding checklist for seeding an in-flight project — choose a methodology, connect your inputs, seed your registers, and add documents. See Import your data.