コンテンツにスキップ

Project settings

このコンテンツはまだ日本語訳がありません。

Each project has its own Settings, organised into tabs. You can deep-link to a tab with ?tab= in the URL, and most setup flows send you straight to the right one.

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.

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 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.

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

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.

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.

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.

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.