Projects

What this is

Projects are named groups inside a workspace. Use them to split a workspace’s tests by product area, system boundary, or team, for example Core APIs, Checkout, or Mobile backend. A test belongs to at most one project. Runs, secrets, and access controls come from the workspace, and every project inside it inherits them.

Projects only organise tests. They do not change how tests run or which regions are available.

Projects sit below workspaces and above tests in the account hierarchy: account → workspace → project → test. Project access, secrets, and runs all flow down from the parent workspace. See Account overview & active runs for the full four-layer model and role table.

Where to find it

Click Projects in the left navigation sidebar. The route is /projects. The page is scoped to the workspace selected in the top-bar workspace scope switcher. You must select a workspace to see or create projects.

Projects list

The Project directory section lists every project in the active workspace, one per row.

Each row contains:

Element	What it does
Project name	Click the name to edit it inline (if you have edit rights). Press Enter or click away to save; press Escape to cancel.
Project ID	A truncated stable identifier below the name. Hover to see the full value.
View tests	A quick link that opens the Tests list filtered to this project.
Actions menu (three-dot icon)	Contains Settings (opens Project detail) and Delete… (opens the delete confirmation dialog). Visible only if you have edit or delete rights.

How to view tests for a project

Open Projects in the left nav.
Find the project row.
Click View tests. The Tests list opens, filtered to that project.

Create a project

Workspace editors and admins create projects with the Create project button in the page header.

How to create a project

Make sure a workspace is selected in the top-bar scope switcher.
Click Create project in the page header. A dialog opens.
Enter a Name for the project (up to 200 characters). Use something descriptive, such as Core APIs or Mobile backend.
Click Create. The dialog closes and the new project appears in the list.

Rename a project

You can rename a project inline in the list or on the Project detail page.

How to rename a project (inline)

In the Project directory, click the project name text.
The name becomes an editable field. Type the new name.
Press Enter or click outside the field to save.
If the rename fails (e.g. a network error), an error message appears next to the field and the previous name stays.

Delete a project

Deleting a project is a soft-delete. The project leaves the directory and you can no longer use it, but its historical run data stays in the database. If the project still has tests, the API returns a conflict error unless you force-delete the tests with the project.

How to delete a project

Open the Actions menu (three-dot icon) on the project row.
Click Delete…. A confirmation dialog opens.
In the Project name field, type the exact project name to enable the delete buttons.
Choose one of two actions:
- Delete: soft-deletes the project. Fails with a 409 error if the project still has tests. The error message suggests “Delete including tests” instead.
- Delete including tests: force-deletes the project and all its tests in one operation. Use it only when you mean to remove the tests permanently.
Click the chosen button. The dialog closes and the project is removed from the list.

Project detail

Open the Project detail page from the Actions menu → Settings, or go to /projects/<project-id>.

The page has four sections:

Identity

Shows the project’s stable identifiers (project ID, workspace ID, and account ID) and your current access level (viewer, editor, or admin).

Launch control

Two quick-action buttons:

Tests in this project: opens the Tests list, filtered to this project.
Workspace settings: opens the Workspace detail page for the parent workspace.

Access

Explains how the project inherits access. Project roles (viewer, editor, admin) come from workspace and account-level team grants; you cannot assign permissions per project. The section lists the team grants on the parent workspace, so you can see which teams have access to this project.

To change access, go to Account → Teams or Workspace settings.

Danger zone (admin/owner only)

If you have delete rights, a Delete project… button appears in a red-bordered section at the bottom. It opens the same confirmation dialog as the list-row delete action.

Assign tests to a project

You assign a test to a project when you create it, or later by editing its configuration.

Assign during test creation

Open Tests → New test (or New Vario test).
In the test configuration, look for the Project field.
Select the project from the dropdown. A test created without a project is unassigned. It appears in the Tests list under “No project” and stays reachable whatever project filter you set.

Reassign an existing test

Open the test’s detail page → Configuration tab.
Find the Project field and change the selection.
Save the configuration.

Tips & gotchas

No workspace, no projects. The Projects page needs a workspace selected in the top-bar scope switcher. If the scope is “All workspaces”, the page shows no data.
Rename is instant. Inline rename saves on blur or Enter. The inline flow has no Cancel (only Escape before blurring). If you make a mistake, click the name again and retype.
Delete vs force-delete. Deleting a project that still has tests returns a 409 conflict. Delete the tests first, or use Delete including tests to remove everything at once.
Access is inherited. Projects do not have their own member list. Team and workspace grants control who can see, edit, or delete a project.

Account overview & active runs: the full account → workspace → project → test hierarchy.
Tests — create and configure: create tests and assign them to a project.
Workspaces: manage workspaces and their settings.
Teams: configure the team-based access that projects inherit.
Navigating the console: the shell, sidebar, and workspace scope switcher.