Skip to main content
An Organization is your top level on Netgraph Connectivity Platform. It is the box that holds everything you, as a customer, run on the platform — every Service Context, every administrator, every audit row, every webhook, the SAML federation that authenticates your admins and your end users. Inside an Organization you can run any combination of the four Services. Each is exposed as a Service Context — a self-contained configuration of that Service, scoped to one venue, one site, one fleet, or whatever boundary fits your operations. The Organization is the umbrella; the Service Contexts are the things that actually do work.

​
Two layers, two kinds of work

Organization (you, the customer)
├── Shared, Organization-scope concerns
│   ├── Administrators and their roles
│   ├── Admin Portal authentication (Form Login, SAML 2.0)
│   ├── Self-Service Portal authentication (Email Magic Link, SAML 2.0)
│   ├── Audit log (Change log of every administrative action)
│   ├── Webhooks (Organization configuration changes)
│   └── Organization Settings (name, slugs, language, MFA, dashboard access)
│
└── Service Contexts (one or more per Service)
    ├── Sign In Context(s) — guest / captive-portal venues
    ├── EntryPoint Context(s) — RADIUS deployments
    ├── EasyPSK Context(s) — Meraki Wireless Personal Networks
    └── Endpoint Manager Context(s) — managed Cisco ISE deployments
The work that happens at the Organization layer is mostly configure-once and review: invite the colleague who’ll run a venue, federate sign-in with your IdP, look at audit, subscribe to configuration-change webhooks. The day-to-day operational work — publishing a Sign-In Module, creating a Wireless Personal Network, moving an endpoint between groups — happens inside the relevant Service Context.
Service Contexts list with one row per Context, each showing the Context name and its Service Type badge

​
A Service is consumed as one or more Contexts

A Service is the kind of thing you can run; a Service Context is one running instance of it. The pattern is “as many Contexts of each Service as you need,” with no platform limit on how many of each you can have:
  • A property manager running guest Wi-Fi at three buildings might run one Sign In Context per building, each with its own Sign-In Modules, branding, and Sites.
  • The same property manager handing out per-apartment private networks runs one EasyPSK Context per multi-tenant property, each pointed at one Meraki SSID.
  • A retailer with one corporate RADIUS service runs one EntryPoint Context for the whole estate.
  • A network team supporting many Cisco ISE deployments runs one Endpoint Manager Context per ISE deployment they want to delegate.
Service Types and their in-product card labels at a glance:
ServiceContext type label in admin
Sign InSign In
EntryPointEntryPoint - RADIUSaaS (with sub-types per variant)
EasyPSK for Cisco NetworksMeraki - Wireless Private Network
Endpoint Manager for Cisco ISEISE Device Management
Setting up the Service Context itself — choosing a name, wiring it to your Meraki dashboard, defining your first Group, picking your first Sign-In Module — is documented in each Service’s quickstart. The Organization-level docs you’re reading now don’t repeat those flows.

​
Where each kind of administrative work lives

A few rules of thumb to keep the layers straight:
  • Inviting a colleague who’ll be a platform-wide administrator on your Organization → Organization scope. See Managing Administrators.
  • Inviting a delegated administrator who only needs to run one Sign-In venue, one EasyPSK property, one ISE group → that’s a Self-Service User on the relevant Service Context. See the Service’s own Managing Self-Service Users page.
  • Federating Admin Portal sign-in with your IdP → Organization scope. See Admin Portal authentication.
  • Federating the Self-Service Portal that residents, conference hosts, and group administrators use → Organization scope (one configuration shared by every Service’s Self-Service Portal). See Self-Service Portal authentication.
  • Reading the audit log of administrative changes across everything in the Organization → Organization scope. See Audit Log.
  • Subscribing to a webhook for Organization configuration changes → Organization scope, one event type. See Webhooks. For the per-Service event streams (sessions, DHCP, Service configuration audits), each Service Context has its own webhook configuration.
  • Configuring a Sign-In Module / EntryPoint variant / Wireless Personal Network / managed Endpoint Identity Group → inside the Service Context. The Organization docs only say the Service Context exists; the Service’s own docs say what to do inside it.

​
What a Service Context does NOT inherit

A Service Context inside your Organization inherits very little from the Organization itself. In particular:
  • No automatic admin propagation. An Organization administrator has access to every Service Context in the Organization, but a Self-Service User invited to one Service Context isn’t a Self-Service User on any other Context. Self-Service Users are always Context-scoped.
  • No automatic branding cascade. Each Sign-In Context configures its own branding, languages, and Sites. The Organization’s Language Settings affect the Admin Portal and define which languages an admin can choose for content; they don’t overwrite what’s already configured inside an existing Sign-In Context.
  • No shared per-Service settings. Two Sign-In Contexts side by side can run completely different Sign-In Modules with completely different Access Policies. There is no Organization-level “default Sign-In Module list.”
This is by design: each Service Context is a real operational boundary. A change inside one Context won’t surprise the team running another.

​
Where to go next

Quickstart

Day-one path through Organization Settings, your first administrator, federation, and adding the first Service Context.

Admin Portal vs Self-Service Portal

Two surfaces, two authentication configurations, two different audiences.

Administrator roles

The three Organization-scope roles and what each can change.

Sign In overview

Cloud guest Wi-Fi with self-service captive portals.

EntryPoint overview

RADIUS-as-a-Service for 802.1X, MAB, iPSK.

EasyPSK overview

Personal Wi-Fi networks on Cisco Meraki.

Endpoint Manager overview

Delegated administration on top of Cisco ISE.