Project settings overview

Project settings is where a project's name, description, team, and members are managed. It is reached from Project settings at the bottom of the project's group in the sidebar, and it applies only to the project you have open.

Most of what is here requires admin access on the project. If you can open the page but the controls are unavailable, see Roles and permissions.

General settings

The name is worth getting right early, because it is how everyone identifies the project in the selector and how you will refer to it when contacting support. A site or structure name reads better than an internal job number.

Note: The Team field controls which team the project sits under, and team membership is one of the ways people reach a project. Changing it affects who can see the project. Treat it as an access change rather than a piece of labelling, and check the member list afterwards.

Project info

A read-only panel shows when the project was created, when it was last updated, and its Project ID.

The Project ID is the one to copy when raising a support request. Project names can be similar or duplicated across an organization; the ID is unambiguous, and quoting it removes a round of questions.

Project members

The members list shows everyone with access to this project, with their email and role. It can be searched by name or email and sorted by any column, which matters once a project has more than a handful of people.

From here you can:

• Add more members, drawing from users who already exist in your organization.
• Change a role using the dropdown on each row.
• Remove someone from the project.

Adding someone here gives them access to the project. It does not give them access to the dashboards and alerts inside it — those are shared separately. This is the most common reason a newly added member reports being able to see a project but not the dashboard they were told to look at. Sharing a dashboard covers that side.

Some rows cannot be edited or removed here. A team admin gets admin access to every project belonging to their team, so they appear on this list even though nobody added them to the project. Those rows are marked, and their role dropdown and Remove action are unavailable, because the access comes from the team rather than from this project. To change it, change their team role.

That distinction matters when you are auditing who can alter a project. The list shows everyone with access, but only some of it can be changed from this page.

Removing someone from a project does not remove them from your organization or team. They lose access to this project and keep everything else.

Danger zone

Deleting a project is permanent and cannot be undone. It takes the project's dashboards, connections, Virtual Devices, alerts, and access configuration with it.

Before deleting anything, consider whether the monitoring data has any remaining value as a record. Projects on real infrastructure often need to be produced years later for a client, a claim, or a review, and a deleted project cannot answer that.

If the project is simply finished, leaving it in place costs little. If you need it gone, contact BDI Cloud Support first to confirm nothing else depends on it.