Skip to main content
The Services page is the first thing you see when you sign in to the Organization Admin Portal. It lists every Service Context in the Organization, what Service Type each one is, and how to add or remove Contexts. The actual configuration of a Service Context — Sign-In Modules, EntryPoint variants, Wireless Personal Networks, managed Endpoint Identity Groups — happens inside each Context’s own admin and is documented in each Service’s own quickstart. This page covers only the lifecycle from the Organization’s perspective.
Service Contexts list table populated with one Sign In, two EntryPoint, one Meraki, one ISE Device Management Context

​
What each column tells you

ColumnWhat it means
NameThe Context’s display name. Click to open that Context’s own admin.
Service TypeWhich Service this Context is — Sign In, EntryPoint (with variant), Meraki - WPN, ISE Device Management.
ActionPer-row menu — Remove <context name> (only available to admins with Organization Owner or Organization Context Manager).
The page supports text search by Context name. Sorting is available on every column.

​
Adding a Service Context

Click Add Service Context to open the Service-card picker. You see four cards, one per Service:
Add Service Context picker showing four cards: Sign In, EntryPoint - RADIUSaaS, Meraki - Wireless Private Network, ISE Device Management
Picking a card hands you off to the chosen Service’s setup wizard — that’s where you give the Context a name, wire it to upstream infrastructure (your Cisco Meraki dashboard, your Cisco ISE deployment), define your first Group, and so on. Those flows are fully documented in each Service’s quickstart:

Sign In quickstart

Set up cloud guest Wi-Fi with self-service captive portals.

EntryPoint quickstart

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

EasyPSK quickstart

Set up Personal Wi-Fi networks on Cisco Meraki.

Endpoint Manager quickstart

Set up delegated administration on top of Cisco ISE.
A few cross-cutting things to know before you go:
  • There is no platform limit on how many Contexts of each Service you can have. Most Organizations end up with multiple Sign-In Contexts (one per venue) and one or two of each other Service.
  • A new Context inherits very little from the Organization itself. Settings like Active Languages and the Self-Service Portal token lifetime apply broadly, but each Service Context configures its own branding, modules, and operational policy independently.
  • Adding a Service Context is audited at the Organization scope with a Created action — see Audit Log.

​
Opening a Service Context

Click the Context’s name in the Services list to navigate into its own admin. The left navigation changes to that Service’s surface (Sign-In Modules, EntryPoint Groups, Meraki - WPN tabs, etc.) and the breadcrumb shows the Organization → Context path. The Organization-level navigation (Organization Settings, Audit Log, Webhooks, Authentication, Administrators) stays accessible through the Organization picker at the top of the left navigation; switch back to Organization scope from there.

​
Removing a Service Context

Pick Remove <context name> from the row’s action menu. The platform asks for confirmation before deleting the Context.
Removing a Service Context deletes everything inside it — Sign-In Modules, EntryPoint Groups, Wireless Personal Networks, managed Endpoint Identity Groups, Self-Service Users, audit rows scoped to that Context, webhook configurations defined inside that Context. The deletion is not reversible. Audit rows scoped to the Organization (e.g. the original “Created” event for the Context) are kept.
Practical guidance before removing:
  • Tell the Context’s day-to-day admins first. The Context’s own administrators and Self-Service Users lose access the moment the Context is deleted; they should know what’s coming.
  • Disable any webhook subscriptions inside the Context first. Webhook subscriptions configured at the Context scope are removed with the Context, but if a downstream system was relying on the stream you’ll want a clean shutdown.
  • Capture anything you’ll want as a record. There is no CSV export from the Audit Log, so if you want a snapshot of what was in the Context (Sign-In Modules, Wireless Personal Networks, etc.), use the Service’s own export surfaces or the REST API before removing the Context.

​
Renaming a Service Context

A Context’s name is changed inside the Context itself, not from this list. Open the Context, find its own settings page (typically Configuration at the Service level), and update the name there. The change is reflected in the Services list on the next refresh and audited at both the Organization scope and the Context scope.

​
Where to go next

Organization and Services

The two-layer model — Organization-scope vs Context-scope work.

Audit Log

Review every Context creation, configuration, and removal.

Webhooks

Stream Organization-scope events; per-Context webhooks live inside each Context.

Managing Administrators

Decide who can add or remove Contexts.