Access to multiple Organizations
A single User can hold roles in one Organization or in several. Each invitation binds the account to one Organization with a specific role set; additional invitations add Organizations the account can reach, without changing the identity itself.- Sign in once with your platform credential (or through SAML).
- Pick the Organization you want to work in. You land in that Organization’s Admin Dashboard.
- Switch Organization from the same signed-in session whenever you need to work somewhere else.
Two role scopes
Every role binding sits at one of two scopes.Organization-scope
An Organization-scope role applies across everything in the Organization — every Service Context, every Organization-level surface (Administrators, Audit Log, Webhooks, SAML authentication, Common Settings, Compliance). Canonical Organization-scope role labels — Organization Owner, Organization Context Manager, Organization Member — and exactly what each one can do are covered in Administrators.Context-scope
A Context-scope role applies to one specific Service Context only. A Context-scope administrator can operate that single Context but can’t change Organization-level settings, can’t see other Services, and can’t see sibling Contexts of the same type. Context-scope roles are useful when you want to delegate the operation of one venue, one Meraki organization, one ISE integration, or one EntryPoint deployment without granting Organization-wide access. A User can hold both scopes at once — for example, Organization Member in Organization A plus a Context-scope role in one specific Sign-In Context in the same Organization.The Admin Dashboard reflects your roles
What you see in the Admin Dashboard after choosing an Organization is shaped entirely by the role bindings that apply to your User in that Organization.- An Organization-scope administrator sees the full left navigation — every Service live in the Organization, plus the Organization-level surfaces.
- A Context-scope administrator sees only the Service Context or Contexts they are bound to. Other Services, other Contexts of the same type, and Organization-level surfaces do not appear.
- A User with no bindings in an Organization cannot pick that Organization, and cannot reach its Admin Dashboard at all.
Sign-in mechanics
Invitation-based onboarding
The default way a User joins an Organization is by invitation. An existing administrator issues the invitation from the Administrators page; the invited person accepts, sets a credential on first sign-in, and the role binding is created at the same moment. Pending invitations stay visible on the Administrators page until accepted or revoked.SAML-federated sign-in
Organizations can federate administrator sign-in with an external identity provider by configuring SAML authentication on the Organization at the Admin Portal target. When SAML is enabled:- Invited administrators can sign in with their IdP identity instead of a local credential.
- New administrators can auto-provision on first SAML sign-in, inheriting a role set defined on the Organization’s SAML configuration. They do not receive an invitation email.
- The IdP’s attribute statements can override the default role set per individual User.
Removing access
Removing a User from an Organization’s Administrators page revokes every role binding that User held in that Organization. Active sessions end. Audit rows created under that User’s name stay on record — removal does not rewrite history. The User identity itself persists, because it is platform-scope. If the same User holds bindings in other Organizations, those are unaffected; the User keeps access to everywhere else they are bound.Related
Administrators
Canonical role labels, invitation flow, Pending Invite states.
Admin Portal authentication
SAML federation for administrator sign-in.
Object hierarchy
Where Users sit in relation to Organizations and Service Contexts.
Glossary
Quick definitions for terms used across the documentation.