# Projects

Group services into projects and restrict which people see them on the project-aware, service-scoped pages.

**Projects** group your services and restrict who sees them. Without projects, everyone in the organization sees every service; with them, a service that belongs to a project is shown only to that project's members — and to organization admins, who always see every service.

:::info
Projects is off by default. If **Projects** isn't in your organization settings, [contact us](mailto:support@brizz.ai) to enable it.
:::

## What it is

A project is a name, an optional description, a set of **members**, and a set of **services**. Reach for it when different teams run different agents and shouldn't be looking at each other's traffic day to day.

Treat it as scoping rather than hard isolation: it restricts the project-aware, service-scoped pages, but some information — including tenant usage figures — remains tenant-wide. Don't rely on a project to keep tenant-wide data from someone who already has access to your organization.

Services that aren't assigned to a project sit in a **Default** group, which stays visible to everyone.

## How to read it in the dashboard

Each project is listed with its services and its member count. From here you can:

- **Create a project** — name it, describe it, and add members.
- **Rename or re-describe** an existing project.
- **Add or remove members** — membership is what grants a non-admin visibility of that project's services.
- **Move a service** between projects, or back to Default.

Once projects are in use, the service selector groups services under their project heading, so where a service lives is visible everywhere you switch services rather than only in settings.

## How to act on it

1. **Start from who should see what.** A project is an access boundary first and an organizing device second — if everyone should see everything, you don't need one.
2. **Watch the Default group.** A new service lands in Default and is therefore visible to everyone. If you're using projects for isolation, assign new services deliberately.
3. **Remember that removing a member removes their visibility.** Someone dropped from a project stops seeing its services on the scoped pages.
4. **Don't expect projects to restrict admins.** Organization admins see every service regardless of membership, so a project isn't a way to hide a service from them.
5. **Know the label boundary.** Label data and service-specific rules follow service access; label definitions and tenant-wide rules remain organization-wide. Project-restricted users can view but not change tenant-wide rules, and only organization admins can delete label definitions.

## Availability

Off by default, and managing projects requires **Organization Admin**.

## See also

- [Organization & members](/docs/admin/organization-and-members.md) — the people and roles you assign to a project.
- [Services & configuration](/docs/admin/services-and-configuration.md) — per-service settings for the services a project contains.