Organisations and roles

Every piece of data in ARGUS is scoped to an organisation (org). Users, operations, teams, assets, DJI docks, venues, webhooks, workflows, branding — all of it lives under exactly one org. If your account belongs to multiple orgs you switch between them; you never see cross-org data.

The org is the unit

Sign-in is global (one Firebase account), but everything you see after sign-in is filtered through an active org stored in OrgService.activeOrgId$ (persisted in localStorage as sar.activeOrg).
Firestore security rules enforce the scoping server-side: an admin of Org A cannot read or write data in Org B even with a forged request — the rules check your membership document at orgs/{orgId}/members/{uid}.
Teams, operations, and assets all carry orgId and are queried with that filter.

Role hierarchy

ARGUS defines five built-in org roles, ordered by decreasing privilege (src/app/core/data/model/org.ts):

Role	Label	Colour	Summary
`superadmin`	Super Admin	red	Full tenant-level control: create orgs, manage plan, manage custom roles, impersonate.
`admin`	Admin	amber	Manage this org’s users, assets, docks, venues, workflows, webhooks, branding.
`manager`	Manager	cyan	Manage users (invite, assign roles), create/edit operations, lead teams.
`operator`	Operator	green	Create and run operations, fly assigned drones, post on PTT, author reports.
`observer`	Observer	grey	Read-only across operations the user is added to.

The conceptual commander / operator / analyst / admin / guest taxonomy maps onto this list:

Commander / team lead → manager (or admin if they run configuration too).
Drone operator → operator. Analyst / spotter → observer or operator.
Admin → admin or superadmin.
Mission guest → not a role — an invite to one op.

Custom roles

On Command and Sovereign, superadmin creates custom roles at /admin/roles. Custom roles pin specific permissions and are matched by customRoleId in the orgRoleGuard alongside built-ins. The preset venue_creator gates /admin/venues for non-admin users.

Roles are additive across orgs, not within one

Your membership document in a given org has one role. You can’t be both admin and observer in Org A. But you can be admin in Org A and observer in Org B — each membership is stored separately, and switching the active org switches which role applies.

roleAtLeast(role, minimum) (from org.ts) returns whether a role meets or exceeds a minimum bar — used throughout the app for permission checks.

Switching orgs

From any page, click your avatar in the top bar. The dropdown header shows the active org name and your role badge in that org. Below that, Switch organisation lets you pick a different membership. The switch updates activeOrgId$, re-loads nav permissions, and the dashboard re-renders with that org’s operations.

Creating an organisation

superadmin-only. Go to /admin/org → New organisation and fill in Name, slug, Plan (guardian / tactical / command / sovereign — limits enforced server-side: max users, streams, retention, SSO, AI copilot), and Primary admin (first member, auto-promoted to admin).

Self-service creation for non-superadmins is aspirational; customers sign up on the marketing site which provisions server-side.

Per-org settings

Once you’re an admin (or higher) of an org, these surfaces are yours to configure:

Branding (/admin/org) — org name, logo, accent colour, custom subdomain.
Venues (/admin/venues) — indoor maps, geofenced areas, drone landing pads.
Assets (/admin/assets) — aircraft, vehicles, dogs, people, cameras, FOBs.
DJI fleet (/admin/dji) — cloud-paired docks and their aircraft.
Workflows (/admin/workflows) — repeatable mission templates and automations.
Webhooks (/admin/webhooks) — HTTP callbacks for mission events, detections, HMS.
Users + invites (/admin/users) — membership, roles, invitations, password resets.
Subscription (/admin/subscription, superadmin only) — plan + billing.