Skip to content
Platform

Roles and Administration Levels

Access on the Netgraph Connectivity Platform is governed by role-based access control. Every administrator and every delegated end user acts within a defined role at a defined scope, and the platform enforces those boundaries on every action. Roles control what an identity can see and do; the platform does not rely on the user interface to hide capability that the backend would otherwise permit.

At a glance

Surfaces
Administration Portal (administrators) · Self-Service Portal (delegated users)
Organization roles
Owner · Context Manager · Member
Context scope
Administration assignable per service context
Self-service
Narrow, per-context permissions for owners, hosts, and residents

Roles are assigned at four nested scopes. Each scope contains the one below it, and a role is always evaluated against the scope it was granted in.

Platform OwnerPlatform Admin

Netgraph. Operates the platform and the partners on it.

PartnerMSP Portal

Owner and members, plus managed-organization managers. Sells and manages the organizations it serves.

OrganizationAdministration Portal

Owner · Context Manager · Member. The customer tenant; manages its settings and service contexts.

Service ContextAdmin + Self-Service

Administration: Owner · Group Manager · Member. Self-Service: User · Group Administrator. One running instance of a service (Sign In, EntryPoint, EasyPSK, Endpoint Manager).

The Platform Owner and Partner scopes are described in Tenant and Organization Structure and Partner Model. The sections below focus on the organization and context scopes that a customer administers.

Administration is divided across two separate portals with independent sign-in:

  • The Administration Portal is for administrators who configure the organization and its services.
  • The Self-Service Portal is for delegated end users who carry out a defined, limited set of tasks within a single service context.

The two surfaces authenticate separately and assign roles separately. A person may hold a role in one, the other, or both.

At the organization level, three roles define administrative reach across the organization and the service contexts it contains:

  • Organization Owner: full control of the organization, its settings, its administrators, and all of its service contexts.
  • Organization Context Manager: management of service contexts and their administration, without full control of the organization itself.
  • Organization Member: a scoped administrative role within the organization, limited to the contexts and functions granted.

Within each service context, administration can be assigned independently. A person can administer one context without gaining any access to another context in the same organization. This makes it possible to separate, for example, the administration of one venue’s guest network from another’s, or one service from another, while the organization retains a single consolidated view.

Within each service context the same set of role archetypes applies, regardless of which service it is:

ArchetypeSurfaceWhat it does
Context OwnerAdministration PortalFull configuration of the context, its access control, and its integrations
Group ManagerAdministration PortalManages the groups within the context
MemberAdministration PortalRead-only: statistics and audit
Group AdministratorSelf-Service PortalManages their own group: members, and where applicable the group key or endpoints
UserSelf-Service PortalViews their own access details

Sign In has a slightly wider set of context roles (for example a connector manager and a captive-portal manager) reflecting its broader configuration surface.

The Self-Service Portal is where day-to-day, owner-level tasks are delegated to the people closest to the equipment or the relationship. Typical delegated roles include a group lead managing their own group, a resident or unit owner managing their own access, or a host managing their own event. Self-service permissions are granted per service context and are deliberately narrow: a delegated user can carry out their assigned tasks and see only their own scope.

The role model is intentionally coarse-grained. Access is granted through clearly defined roles at the organization and context levels rather than through fine-grained per-screen permissions. This keeps administration auditable and predictable, and it makes the boundary between tenants and between contexts easy to reason about in a contractual or compliance context.

Next