Why Self-Service Roles Matter: Configuration Guide

What is delegated administration in B2B SaaS?

Delegated administration transfers selected operational tasks from a SaaS provider to an authorized administrator at a customer organization. It reduces support work and gives customers faster control over their own users and access policies, while the provider retains global platform controls.

Delegation should never mean giving a customer administrator unrestricted access. Every administrative action must be authorized within an active tenant, checked again by the server, and limited to capabilities the provider intentionally made available.

Platform administrator vs. customer administrator

Platform and customer administrators operate at different scopes. The provider owns global capabilities and delegation boundaries; the customer administrator manages only the permitted configuration within their own organization.

Why self-service roles matter

Self-service roles let customers adapt access control to their teams while the SaaS provider retains the permission boundary:

• Customer administrators can respond to staffing and responsibility changes without opening a support ticket for every role update.
• Custom tenant roles can align approved permissions more closely with customer job functions than a small set of broad predefined roles.
• The provider continues to define what is delegable, while each customer organizes those allowed permissions inside its own tenant.

Guardrails for delegated administration

Delegated administration is safe only when authorization, tenant isolation, and recovery controls apply to the administrative actions themselves.

1. Scope every action to one tenant. Verify the administrator’s identity and active tenant before loading the target user, role, or setting.
2. Control what can be delegated. Separate assignable permissions from permissions that are always included or never available to customer-created roles.
3. Prevent privilege escalation. A customer administrator must not grant permissions they are not authorized to delegate or permissions the provider has marked non-delegable.
4. Revalidate at execution time. Do not rely only on what the interface displayed; check authorization again when the API request is processed.
5. Record an audit event. Capture tenant, administrator, target, before-and-after state, timestamp, and outcome.
6. Support revocation and recovery. Removing administrative access should take effect predictably. Define a controlled recovery path if a customer locks out all administrators.
7. Test cross-tenant negative cases. Verify that an administrator from one tenant cannot view or modify another tenant’s users, roles, or identity settings.

Frontegg’s delegation model

Frontegg separates provider-defined access primitives from tenant-local administration. The provider defines permissions and classifies their availability; an authorized customer administrator can then create a tenant role from the allowed permissions and assign that role within the customer organization.

SaaS provider
  → defines permission keys
  → classifies each permission as Assignable, Always, or Never
  → enables the Roles module and grants role-management permissions

Customer administrator
  → creates a role for the active tenant
  → selects only permitted permissions
  → assigns the tenant-local role to organization members

The Frontegg roles documentation defines the three permission classifications. Assignable permissions may be selected for a customer-created role, Always permissions are included automatically, and Never permissions cannot be used by custom roles.

The table below is illustrative; the permission keys demonstrate the boundary and are not a claim about Frontegg’s default catalog.

Delegated administration example

Acme’s organization administrator can invite a colleague and create an Analyst role from permissions the SaaS provider marked assignable. The administrator cannot add a platform-support permission, view Beta Corp’s users, or change Beta’s roles.

When Acme’s administrator changes the role, the application rechecks their authority at execution time and records the tenant, actor, target role, previous state, new state, and outcome. If the administrator later loses role-management permission, subsequent requests must fail even if an older browser screen still shows the controls.

How to configure self-service roles

A self-service role workflow starts with the provider’s permission model, treats role creation as one controlled step, and ends with tenant-bound verification.

1. Define granular permissions. Use stable permission keys that represent individual actions or capabilities.
2. Classify permission availability. Decide which permissions customer administrators may assign, which are always included, and which must never appear in customer-created roles.
3. Enable role management for selected administrators. Grant the minimum administrative permissions required to create, update, assign, or remove tenant roles.
4. Expose role management inside the organization workspace. Make the active organization and effect of each permission clear.
5. Validate every change server-side. Confirm tenant, actor, target, and permission boundaries when processing the request.
6. Test forbidden paths. Attempt to assign a non-delegable permission, modify another tenant, grant a role the actor cannot delegate, and continue after the actor’s authority is revoked.
7. Monitor and review changes. Use tenant-scoped audit events to investigate administrative actions and support periodic review.

Self-service role configuration with Frontegg

In the Admin Portal builder, teams can expose role management through the customer’s organization workspace. Frontegg’s Organization space modules documentation confirms that users with the required permissions can create custom roles and assign permissions when the Roles page is enabled. The documented role-management keys include fe.secure.read.roles, fe.secure.write.roles, and fe.secure.delete.roles.

The account-role API also requires tenant context when creating a role for a specific account. This keeps role administration tenant-local: an administrator manages allowed roles and users for their own organization, not platform-wide access or another customer’s configuration. For related implementation context, see authorization, SaaS multitenancy, and B2B user management.