All Projects (Admin)

Settings → Projects is one list of every project in the workspace — active and completed together — with a status filter, a search box and a row menu. Its subtitle states the split it enforces: “The projects in this workspace, who can open each one, and the role they get inside it. A project owns its test cases, runs and milestones; everything else in this admin area is shared across all of them.” To open the projects you work in from the workspace navigation instead, see Browsing Projects.

Finding the page

Open the account menu at the foot of the sidebar and choose Settings. The settings rail groups its entries — Personal, Users & Access, Test Design, Execution, Workspace, Administration. Projects is the first entry under Test Design, beside Fields and Templates.

One list, not two tables

Active and completed projects share a single table. Completed rows stay in place and are drawn at reduced contrast rather than moved into a section of their own, so the count beside the panel heading is the whole workspace unless you filter it.

Column	What it shows
Project	The icon and name, with the summary on a second line. A project with no summary reads No summary.
Access	The project’s default only — Everyone, own role, or Everyone as <role> when one role is applied to everybody. Exceptions are not counted here; open the project to see them.
Created	How long ago the project was created (“9 weeks ago”, “today”). The exact date is on the cell’s tooltip.
Status	Active or Completed. Completed carries a help marker: “Out of the project switcher and out of new runs. Everything recorded in it is kept.”
Actions	The row menu — see The row menu.

Project and Created are sortable: click the header to sort, click again to reverse. The list opens sorted by project name, A to Z, with completed projects interleaved. Access and Status are not sortable — use the Status filter instead.

Search and the Status filter

Search projects matches on both the name and the summary, so typing ledger finds a project whose description mentions it. When nothing matches, the table is replaced by No projects match “…” with “Try a different search, or switch the status filter.” and a Clear filters button.

The Status control offers three choices, two of them with live counts:

All — no count, because it is the sum of the two below it
Active N
Completed N

The count beside the Projects heading follows the filter and the search, so it always matches the rows you can see.

Every row carries an actions menu with four entries:

Entry	What it does
Edit project…	Opens the project’s own page — see Create a Project.
Manage access…	Opens the same page with the Access panel in focus. See Project Access.
Mark completed / Reopen project	Flips the status in place. The menu shows whichever direction applies to that row.
Delete project…	Opens the delete confirmation — see Deleting a project.

Edit project… and Manage access… open the same editor the Projects page and the sidebar row menu open — one page, wherever you start from. What this list keeps to itself is the pair below: the plan’s project limit, and Delete project….

Completing and reopening

Both directions are one click and both are reversible from the confirmation that follows. Marking a project completed raises “<name> marked completed” with an Undo; reopening raises “<name> reopened”, also with Undo. Undo puts the row straight back to where it was.

Completing is not deleting. A completed project keeps every test case, run, result, milestone and attachment. What changes is that it leaves the project switcher, stops being offered for new runs, and becomes read-only — its pages say so and offer Reopen. Reopening is a single menu click, and takes an active-project slot.

The project limit

Plans cap how many projects a workspace can hold. At the cap, New project stays where it is but is disabled, and a one-line note sits directly under the panel heading — “Free includes 2 active projects and both are in use — mark one completed, or move to Starter for unlimited projects.” The note carries one action: Upgrade to Starter for a billing admin, or Ask for anyone who can’t change the plan. Over the cap after a downgrade, the note turns red: the plan keeps that many projects active and the rest are read-only until a billing admin chooses which stay — Choose projects opens the choice (see Choosing active projects). The workspace Projects page shows the same sentence and the same disabled button, so the refusal reaches you wherever you try to create. See Plans & Billing.

Completed projects don’t count. The cap is on active projects, so marking one completed frees a slot — and a completed project keeps all its data and can be reopened. On a plan with room neither the note nor the disabled button appears.

Nothing else on this page is plan-gated. On a Free workspace the list, the search, the status filter, the editor and every row-menu action behaved exactly as on a paid one. The limit is on how many projects the workspace can hold, not on what you can do with the ones you have.

Deleting a project

Delete project… opens a confirmation headed Delete “<name>”? that states exactly what is at stake:

“Everything recorded inside this project goes with it — test cases, runs and their results, milestones, sessions and attachments. This cannot be undone, and support cannot recover it.”

“The number of affected records is not available before deletion, so this dialog cannot show you what you are about to lose. If you are not certain, mark the project completed: it disappears from the switcher and from new runs, and nothing is destroyed.”

The dialog is deliberately honest that it cannot count what it is about to remove. In exchange it makes you type the project’s exact name into the Type <name> to confirm field before Delete project becomes clickable.

The confirmation is case-sensitive. For a project called Legacy admin, neither legacy admin nor Legacy Admin enables the button. Only Legacy admin does.

An active project’s dialog offers a third button, Mark completed instead, beside Cancel and Delete project. A project that is already completed does not get it — there is nothing left to offer.

After the delete the row is gone and a confirmation appears: “Project and all related data permanently deleted successfully.” That sentence is the whole summary the product gives you — there is no per-record breakdown afterwards either.

There is no undo for a delete, and no restore path. The completion confirmations carry an Undo; the delete confirmation does not, and nothing in the product will bring a deleted project back. If you are hesitating, complete it instead — that is reversible, and the dialog itself says so.

Who can use this page

Everything here is gated on capabilities, and those capabilities are answered by Access Level, not by a Role:

Capability	What it unlocks here
View projects	The list itself. Without it the page reads “You don’t have permission to view projects. This needs the View projects capability — ask a Tenant Admin to grant it.”
Create projects	The New project button and the create page.
Edit projects	Editing and completing. Without it the page carries a banner: “Read-only. Creating and editing projects needs the Edit projects permission.”
Delete projects	Delete project… in the row menu.
Manage project members	The Access and Exceptions panels. It is needed together with Edit projects, because saving a project rewrites its access rules.

In practice: a Project Admin gets the whole page, including Delete project…. A Regular User does not — and giving that user a custom Role that includes View Projects does not change it, because these are workspace-level capabilities that the Access Level answers.

Deleting is not reserved to Tenant Admins. A Project Admin sees the same four-entry row menu a Tenant Admin does. If you need someone who can configure projects but not destroy them, that separation is not available from the Access Level alone.