Skip to content
NovaVMS Manual

Why NovaVMS uses five roles instead of three

Why NovaVMS uses five roles instead of three

Early versions of NovaVMS shipped three roles: admin, operator, and viewer. Compliance buyers repeatedly flagged this as insufficient, and the same criticism lands against Eagle Eye Networks’s single Administrator role. In April 2026 we redesigned to five roles so governance and day-to-day operations no longer share a seat (per D78).

The problem with three roles

A single admin role combined two jobs that belong to different people.

  • Governance — who works here, which LLM model the org trusts, how long recordings live, who reads the audit log.
  • Daily operations — which cameras exist, which alert rules fire, which prompt pack runs.

An operations manager reconfiguring alert rules does not need to add a user who can see every camera in the org. Bundling both into one role forced you to over-grant on one axis to enable the other. Auditors preparing SOC 2 or ISO 27001 evidence rejected this directly. Decision D81 records the split.

The five-role model

RoleScopeExample duty
OwnerOrg-wide, exactly one per org, transferableBilling, transfer ownership, delete org
AdminOrg-wide governanceInvite users, select LLM model, review audit log, rotate webhook secrets
OperatorOrg-wide operationsPair gateways, configure cameras, edit alert rules, tune prompt packs
ViewerSite-scoped read-only via user_site_accessWatch live, review clips, receive alerts for granted sites
Platform adminCross-org, via scoped impersonation onlyNovalien staff or MSP operators supporting a specific customer

Each role inherits the ones below it. An admin can do anything an operator can do. Owner is the exception at the top: only the owner changes billing, transfers ownership, or deletes the organisation (per D79).

How it compares to the industry

  • Verkada Command uses Org Admin, Site Admin, Site Viewer, and Live-Only Viewer. Their split is by site; ours is by job type. Either works. We chose job type because most NovaVMS orgs are small enough that one person owns every site, and site scoping adds friction without adding security.
  • Eagle Eye Networks ships a single Administrator role plus eighteen permission flags. Their own reseller support article calls out this as the weak point for compliance buyers. EEN also pioneered the scoped impersonation pattern (/authorizationTokens). We borrowed that pattern for platform admin so Novalien staff never hold standing access to customer data (per D80).
  • Rhombus ships an immutable Super Admin plus fully custom roles. We ship the immutable root (Owner) but defer custom roles to v2. Most orgs do not need them, and shipping presets first lets us define custom roles as “clone preset X, then edit” (per D84).

Trade-offs we accepted

Five roles is more to explain. You pay this cost once during onboarding and keep the flexibility forever. The alternative — shipping a permission matrix with dozens of flags, EEN style — pushes the same complexity onto every admin every day.

Transfer Ownership becomes a first-class flow. Some VMSs let an admin demote the owner; we do not. The owner is immutable until the target user accepts the nomination within seven days. This exists to prevent an admin from locking out the owner, which is a documented attack pattern in other vendors’ incident reports (per D79).

Viewers are site-scoped; operators are not. An operator inherits org-wide device access on purpose. Per-camera tag scoping is deferred to v2 (per D85) because EEN’s per-camera allow-lists become unmanageable past a hundred cameras.

Custom roles wait for v2. If you need “operator except cannot delete cameras,” v1 cannot express that. The trade-off was deliberate: ship presets that cover 90% of needs, then build custom roles on top of a proven foundation (per D84).

See also