# Projects > Browse your organization's projects as a list or a card grid — scan health metrics, filter by member, and pin favorites to the top. A **project** is an independent repository of suites, test cases, runs, milestones, and defects. The **Projects** screen is your organization's landing page: a directory of every project you can access, with at-a-glance health metrics and quick navigation into each one. ## Reaching the screen Sign in and you land on `/projects`. You can also click **Projects** in the top navigation from anywhere in the app. ## Two view modes The directory renders the same paginated set of projects in either of two layouts, switched with the **view toggle** at the top right: - **List** — a compact row per project. This is the default on your first visit. - **Cards** — a responsive grid of project cards, denser on metrics and the team. Your choice is remembered per browser (it persists across reloads), and it applies to both the directory and its loading, empty, and no-results states. Switching modes never re-fetches — it only re-draws the projects already on the page. On a narrow (phone-width) screen your chosen mode is still honoured — the view toggle stays visible and switching still works. **List** reflows to a card per project (the same name, id, metrics, team, and favorite/menu actions as the row, just stacked instead of columned); **Cards** reflows to a single column instead of a multi-column grid. At tablet width and above both modes look exactly as described above. ## Per-project metrics Every project shows the same four health metrics in both modes, computed live from the project's data: | Metric | Meaning | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Cases** | Active (non-archived) test cases in the project | | **Runs** | All test runs, with a **"\{n\} in progress"** qualifier for runs that are still open | | **Defects** | Unresolved defects (open or in progress). This metric is **warn-highlighted** when greater than zero, and the count is always shown as a number so the warning never relies on color alone | | **Milestones** | Live (non-deleted) milestones in the project | **Runs**, **Defects** and **Milestones** are links: a count greater than zero opens that project's matching list. **Cases** is not one — the project itself already opens on a click anywhere else in its row or card — and neither is a count of zero, because there is nothing there to open. On a [locked project](https://docs.probara.net/en/guides/billing/#what-a-locked-project-is), selecting a count opens your plan details instead. ## The team avatar-stack Each project shows a small stack of overlapping member avatars — the project **team** — with a **"+N"** indicator when the team is larger than the avatars shown. > **What the team reflects today.** By default every project is **public**: every member of your > organization has access, and each project's team stack shows the whole active organization. A project can > be switched to **private** from the in-app **Control access** tab in project settings, or via the > integrator API; once private, the team stack automatically narrows to that project's allowlist — > [Control access — Individual members](#control-access--individual-members) below is where you manage > exactly who is on it. Enforcement follows the data, not the URL shape: a test case, run, or similar > entity reached by its own ULID is gated exactly like the project itself, so a private project's contents > stay unreachable that way too. One documented limitation still applies: organization API tokens always > keep reaching every project regardless of mode — "private" applies to human callers only. ## Filtering The filter row offers: - **Search** — type to filter projects by name. The term is reflected in the URL so a filtered view is shareable and survives a reload. - **Member** — filter the directory to projects a selected member can access. The selection is encoded in the URL as a `memberUlid` set, so a filtered link reproduces the same view when opened fresh. > **Member filter today.** For a public project the member filter behaves as before. A private project not > on your allowlist is excluded from the directory entirely (whether or not it matches your filter > selection) — organization owners and administrators always see every project regardless of mode. - **Test runs** — filter to projects that have no runs (`Without runs`), have at least one active run (`Has active runs`), or have at least one run of any state (`Has any run`). - **Defects** — filter to projects that have at least one unresolved defect (`Has defects`) or no unresolved defects (`Without defects`). - **Milestones** — filter to projects that have at least one milestone (`Has milestones`) or no milestones (`Without milestones`). - **Cases** — filter to projects that have at least one test case (`Has cases`) or no test cases (`Without cases`). - **Status** — a permanent filter (always visible, never removable) with two options: **Active** and **Archived**. The directory shows **active projects by default** — an archived project is hidden from both view modes and from the counter/pager until you check **Archived** (or both options, to see everything). Leaving it empty is the same as selecting **Active** alone, not a third state. Your selection is encoded in the URL as `status`, so a filtered link (for example `?status=archived`) reproduces the same view when opened fresh. These filters compose with each other, with the Member filter, and with the search term — all active conditions are applied together (AND across filters, OR within a filter's selected options). Each selection is encoded in the URL so filtered views are shareable and survive a reload. When a search, member, or Status filter matches **no** projects, the directory shows a **no-results** state with a **Clear filters** action that removes the search term, the member selection, and the Status selection all at once (the Status chip stays visible, just empty afterward, returning you to the default active-only view). This is distinct from the **empty** state shown when your organization simply has no projects yet, which offers a **Create first project** action (for organization owners and administrators). ## Favorites Click the **star** on any project to add it to your favorites. Favorited projects float to the **top of the page** you are viewing, keeping their relative order otherwise. Favorites are stored per user and per organization in your browser. > **Favorites sort within the current page only.** A favorite that lives on another page of a large > directory is **not** pulled forward to the first page. For the typical single-page portfolio this is > invisible; it only matters once a directory is large enough to paginate. ## Pagination When your organization has fewer than ten projects, no pager is shown — the directory is a single page. With ten or more, the pager appears below the directory: the rows-per-page selector and the range summary always show, and the previous/next and page-number controls appear only once the directory spans more than one page. Changing the page requests that page of projects. ## Navigating tables with the keyboard Across Probara's list screens rendered as a table — the projects list in **List** mode, test runs, workspace members, and others — every row that opens a detail can be reached without a mouse: press `Tab` until the row is focused, then press `Enter` or `Space` to open it, the same as clicking. A row's own controls (an actions menu, a remove button) still work independently and never trigger the row's own navigation. ## Creating a project Organization **owners** and **administrators** see a **New project** button in the header (and a **Create first project** action in the empty state). Members and viewers can browse the directory but do not see the create action. ## Project settings Open **Settings** from the project sidebar or choose **Edit** on the projects list (⋯ menu). You can review **Name**, **Project ID**, and **Description** for any member of the organization. The description can hold formatting and images, as it can when you create the project. Only organization **owners** and **administrators** can save changes. **Members** and **viewers** see the same fields read-only. **Owners** and **administrators** can also upload, change, or remove the project picture from settings. The image appears in the project sidebar, the projects list, and the settings header. **Members** and **viewers** see the picture (or initials fallback) but cannot change it. Allowed formats: PNG, JPEG, or WebP, up to 5 MB. The picture counts toward your organization's storage, so an upload is refused when the organization is out of storage. The **Project ID** is the uppercase prefix used in test case and suite display IDs (for example `ACME-14`). Changing it updates those prefixes immediately and breaks old `/projects/` URLs and bookmarks—plan integrations and shared links before renaming. ## Repository — test case review The **Repository** tab in project settings turns on **test case review** for the project and sets how it works: whether review is mandatory, self-merge, the approvals required, auto-merge and the default reviewers. Test case review is available on the **Pro** and **Enterprise** plans. See [Test case review](https://docs.probara.net/en/guides/test-case-review/) for each setting and for sending cases to review. The same tab sets the **Default step format**, **Classic** or **Gherkin**. A new test case takes it unless its author picks another format, and changing it leaves existing cases as they are. See [Gherkin test cases](https://docs.probara.net/en/guides/gherkin-test-cases/). ## Archiving and deleting a project The settings header carries two whole-project lifecycle actions, visible to organization **owners** and **administrators** only: - **Archive / Unarchive** — a reversible toggle. Archiving hides the project from the default directory (see [Status filter](#filtering) above) everywhere it is listed, but changes nothing else: the project, its suites, cases, runs, milestones, and defects stay fully readable and writable, and every existing link still resolves. Unarchiving brings it back to the default view. Archiving does **not** free a project seat toward your plan's project limit — deleting remains the only way to do that. - **Delete** — permanent and irreversible. It removes the project and every suite, case, run, and milestone it holds. Both actions ask you to confirm before doing anything; cancelling makes no request at all. **Storage.** Deleting a project also deletes every file it holds — images inside texts, files uploaded to test cases, result evidence, defect evidence, and its picture — and frees that space in your organization's storage right away. See [what counts toward storage](https://docs.probara.net/en/guides/attachments/). ## Control access — Individual members Open the **Control access** tab in project settings to manage who can open a project. The owner comes first, then the **Public** / **Private** toggle, with a line that says what the current mode means. In private mode two inner tabs appear, **Groups** and **Individual members**, each with its count. Every member of a group on the Groups tab can open the project. The **Individual members** tab lists every member currently on the allowlist with their avatar, name, email, role, and position title. The button at the right end of the tab strip adds to the tab you are on: **Add member** here, **Add group** on Groups. To add someone, choose an active organization member who isn't already listed and confirm — they gain access immediately, without changing the project's mode. To remove someone, use the **Revoke access** action on their row and confirm in the dialog that names them. The revoke action only appears on a **Member**-role row — never on an Owner row or an Administrator row, even when that administrator happens to hold a grant themselves (their access comes from their organization role regardless, so revoking that particular row would change nothing about who can open the project). If every remaining row on the list is an Owner or Administrator, no row is actionable — the mode toggle is the only exit, and that is intentional: publishing a project is a mode change and should be made as one, not as a side effect of removing the last few visible rows. Removing the **last** remaining grant on a private project now succeeds: the allowlist is emptied and the project stays private, reachable only by the organization owner/admin bypass until someone is granted again or the mode is explicitly switched to public. Emptying the allowlist is never itself a publication — only the mode toggle above publishes a project.