Skip to content
NereusDocs

Projects & Access

Nereus is multi-tenant: your organisation is a sealed boundary, and no query can ever reach another organisation’s data. Inside that boundary, work is divided into projects, and each project’s assets are arranged into a group tree. Access is granted against a point in that hierarchy — which is what lets someone be an Engineer on one project and a read-only Viewer on another.

The hierarchy

Section titled “The hierarchy”
Organisation (your whole tenant)
  ├── Project — "Northern Network"
  │     ├── Group — North Basin (region)
  │     │     └── Group — Central Zone
  │     └── Group — West Shore (region)
  └── Project — "Trade Waste"
        └── Group — …
  • Organisation — the tenant. Every user, project, asset, and sensor belongs to exactly one.
  • Project — an operational workspace with its own assets, dashboards, alert rules, and reports.
  • Group — the region → zone → site tree that organises a project’s assets (see Assets & groups).

Scoped role grants

Section titled “Scoped role grants”

A member doesn’t just “have a role” — they hold a grant: a role at a scope. The scope is one of three levels, and it decides how far the role reaches:

Scope The grant covers Example
Organisation Everything in the tenant An Owner administering the whole organisation
Project One project’s assets, rules, reports, dashboards An Engineer who manages the Northern Network
Group One group and everything beneath it An Operator responsible only for the West Shore region

Because a member can hold several grants, roles compose naturally: an Engineer on the Northern Network and a Viewer on Trade Waste is just two grants on one membership. A member’s effective permissions are the union of every grant that covers the resource they’re touching.

Data isolation underneath all of this is enforced by the database itself (row-level security), not just the UI — a request scoped to one project physically cannot read another’s rows.

The roles

Section titled “The roles”

There are five system roles, each a strict superset of the one below it. A higher role can do everything a lower one can, plus more:

Role Adds on top of the role below In practice
Viewer Read access to assets, alerts, rules, members, billing Look at everything; change nothing
Operator Acknowledge alerts Front-line incident triage
Engineer Edit rules, manage assets, edit dashboards & reports, manage billing Day-to-day configuration and operations
Admin Invite & manage members, grant roles Team administration
Owner Manage the organisation itself Full control, including tenant settings

A few consequences worth knowing:

  • Operator is the notification floor. Alert emails go to every member with role Operator or above — Viewers watch the queue but aren’t paged. See alert notifications.
  • Viewing a report needs no special permission — a report is a lens over data you can already see, so any member with project access can open one. Editing or scheduling it needs Engineer.
  • Roles are a fixed system set today; per-organisation custom roles are a planned, additive evolution.

Where you manage this

Section titled “Where you manage this”

Members, their roles, and their scopes are managed on the Settings → Members screen — that page covers the UI; this page covers the model behind it.

Section titled “Related”