Projects

Projects (Settings → Projects) group properties and scope member access. Agencies use them per client; larger organizations use them per brand, region or team.

The access model

• Properties outside any project are the org-wide commons — visible to every member.
• Assigning a property to a project restricts it — that’s the point. Only members granted access to the project (plus owners and admins, who always see everything) can access its properties.
• Grants are per member, per project: Viewer (read only) or Editor (can modify), managed on Settings → Team by expanding a member’s row.

A member’s effective access is their organization role, narrowed by project grants:

Org role	Grant on “Client X”	Result for Client X’s properties
Admin or owner	(grants don’t apply)	Full access, always
Editor	Editor	Can view and modify
Editor	Viewer	Read-only
Editor	None	Not visible
Member / viewer	Viewer	Read-only

Everything a project scopes goes with it — the properties’ events, issues, alerts and audits are only visible to members who can see the project.

Setting up projects

1. On Settings → Projects, create a project — name it after the boundary you’re drawing (Client X, EMEA sites, Checkout team).
2. Add properties to it. A property belongs to at most one project; removing it returns it to the org-wide pool.
3. On Settings → Team, grant the members who need access their per-project role.

Deleting a project never deletes data — its properties simply return to the org-wide pool.

Projects elsewhere in Monita

Once defined, projects become a first-class grouping across the app:

• Vendor list policies can be set at project scope — approve a vendor for one client and block it for another, with property-level overrides on top.
• Usage can group consumption by project, so you can attribute event volume per client for rebilling.

Tip

If everyone in your organization should see everything, skip projects entirely — properties are org-wide by default and there is nothing to configure.