Self-Service Portal

The Self-Service Portal lets an organization delegate well-defined, owner-level tasks to the people closest to the equipment or the relationship, without granting them access to the Administration Portal or to the underlying network systems. It is the mechanism that lets access administration scale without concentrating every task on a central team.

At a glance

Audience

Delegated end users: group leads, residents, hosts, vendors, site managers

Portals

Classic or new; the organization sets its Default Portal, and a user can switch

Sign-in

Email magic link by default, optional SAML 2.0, or SAML 2.0 only

Covers

Owner-level tasks within a single service context

Access

Granted per person or to a Self-Service Team; terms of use and a privacy notice can be required first

Boundary

No access to the Administration Portal or other contexts

Purpose and audience

The portal is for delegated end users who carry out a narrow set of tasks within a single service context. Common audiences include a group lead who manages their own group, a resident or unit owner who manages their own connection, an event host who manages their own attendees, and a vendor or contractor who manages their own devices. Each delegated user sees only their own scope.

What it covers

The exact tasks depend on the service context the user is delegated into. Across the services, self-service typically covers managing one’s own group, devices, or units, inviting and managing the users within one’s own scope, viewing connected devices and recent activity, and retrieving reports relevant to that scope. The portal is mobile-first and responsive, suited to occasional, focused use.

Delegation normally stops at the group. In EasyPSK it can go one level up: a Site manager role covers one or more sites, and its members create and maintain the groups of those sites in the portal, within the permissions the administrator switches on for the role. See EasyPSK Self-Service.

Two portals

The portal exists in two versions, the classic one and a new one. The organization chooses its Default Portal, the one users land in after signing in, and a user can switch between the two from the portal itself. Both share the same sign-in and the same permissions.

Sign-in

The Self-Service Portal authenticates separately from the Administration Portal. Sign-in uses an email magic link by default, with optional SAML 2.0 single sign-on against the organization’s identity provider. Once SAML 2.0 is enabled and configured, the organization can turn the email magic link off and run the portal on SAML 2.0 only; links already sent by email then stop working, and the setting can be reversed at any time. Self-service sign-in does not carry administrative role mapping; a delegated user receives only the scope they were granted in the relevant context. See Identity and Authentication.

Access is granted to a person by email address or email pattern, or to a Self-Service Team, a named list of email addresses the organization keeps and binds to a policy, a group, an onboarding rule or a role; see Teams. Self-service users and teams can also be provisioned over SCIM. Where a service carries terms of use and a privacy notice, the user accepts them before anything else in the portal, and again when a new version is published.

Boundaries

Delegated users never reach the Administration Portal, another organization, or another context. They cannot change organization-wide settings, and they cannot exceed the permissions defined for their role in their context. This keeps delegation safe to extend widely.

Related sections

• Roles and Administration Levels: how delegated permissions are defined.
• Administration Portal: where delegation is configured.
• Tenant and Organization Structure: the scope a delegated user is bound to.
• Teams: Self-Service Teams, the named lists of end users that access can be granted to.