Skip to content

Services

This page gives a business-first overview of The Self Service Hub services.

Use it to understand:

  • what each service is responsible for
  • which business rules it enforces

Shared Terms

  • Seat: A unit of access assigned to a user.
  • Group: The customer account context where seats are managed.
  • Invite: A request flow to connect a user to a seat.
  • JWT: JSON Web Token used to carry authenticated user identity and permissions.
  • Sidecar: A companion service that protects service APIs before requests reach business logic.

How Services Work Together

  1. A user interacts with the Self Service Hub frontend.
  2. The frontend calls service APIs for seats and billing.
  3. Authorizer sidecars validate service-to-service access.
  4. Services call adapters for external or legacy systems.
  5. Seats data is synchronized from UserDB and other external adapters on a fixed schedule.

Service Overview and Business Rules

Self Service Hub Frontend

What it does

  • Provides the user-facing self-service experience.
  • Shows seat management and member workflows.
  • Exposes billing and subscription information through integrated service calls.

Frontend Access Matrix

Feature toggles can also control some frontend links and pages, depending on the rollout state.

Feature Flags by Platform

Statista 4:

  • enable-billing-management
  • enable-seat-allocation-activity-log
  • enable-members-page

Statista 3 (monolith/legacy):

  • enable-billing-management-monolith
  • enable-members-page-monolith
  • enable-seat-management

JWT Permission Resolution

Permission resolution happens upstream in the SSO flow and is then propagated in JWT claims.

  1. The user identity is resolved in the SSO layer.
  2. Account, product, and relationship data are evaluated to determine effective seat permissions.
  3. Effective permissions are added to token claims.
  4. The frontend reads these permissions to decide which links and pages are visible.
  5. Services enforce the same permissions on API calls.

Seat-related permissions used by SSH:

  • manage:seats - allows group-level seat management flows.
  • manage:own_seats - allows self-service seat flows for the current user.

Upstream permission logic (from SSO user permission resolution):

  1. Existing extraPermissions from the user are loaded first.
  2. If the user has a master-user chain, permissions are aggregated from parent users (up to 5 levels).
  3. Additional seat permissions are then added when the following rules match.
  4. In SSH, these upstream permissions are interpreted as:
    • SEATS_ADMINISTRATOR -> manage:seats
    • SEATS_USER -> manage:own_seats

Rule for manage:seats:

  • deleted = 0
  • deletedTool = 0
  • idAccountStatus = 2 (active)
  • idProduct = 15 (Pro A)
  • isMasterSlaveConnectionActive = 0
  • isMaster = 1

Rule for manage:own_seats:

  • idProduct is in [1, 23]
  • idMasterUserProduct is null or 15 (Pro A)

If hierarchy resolution exceeds five levels, permission resolution stops and the user is treated as not resolvable for login.

The table below summarizes feature access and visibility by permission and user state.

Feature Variation Who sees it Visibility rule
Seat Management Admin Page Seats Admins User JWT permission has manage:seats
Seat Management Members Page - Active Group Seats Users in a group User JWT permission has manage:own_seats and an active group membership
Seat Management Members Page - Domain Access Seats Users not in a group yet User JWT permission has manage:own_seats, has domain-based group access, and has a disconnected state
Seat Management Members Page - Upsell (No Group) Seats Users without a group and no domain access User JWT permission has manage:own_seats but no group access
Billing and Subscription Main Page Users with billing access enable-billing-management is enabled and isKeylightUser is true (from userinfo)

Seats Allocation Service

What it does

  • Acts as the core service for seat lifecycle and group-level seat operations.
  • Provides group metadata, activity logs, and seat assignment APIs.

Business rules

  • Available seats can be negative when a group is over capacity.
  • Seat admins do not count towards seat usage.
  • User self-connect flow maps to group context based on email domain.
  • Users can disconnect a seat only after 3 months from the activation timestamp.
  • Seats imported during sync/migration use a backdated activation timestamp (3 months in the past), so those users can disconnect immediately.
  • Synchronization from UserDB and other external adapters runs on a fixed delay and defaults to every hour.
  • Missing local group or user records trigger on-demand migration from external systems.

Billing Management Service

What it does

  • Provides subscription and invoice data for the current user.
  • Integrates with a remote order and billing API.

Business rules

  • Overdue invoices are available as a dedicated view.

UserDB Adapter

What it does

  • Provides a modern API over legacy user database operations.
  • Supports user lookup and user creation flows used by other services.

Business rules

  • UserDB is the source of truth for user identity and group membership data used by seats flows.
  • User creation requires email, password, and referenceUserId.
  • New users can be linked to a group account during creation.

Authorizer Sidecar

What it does

  • Guards internal service endpoints with a pre-shared secret check.
  • Proxies authorized requests to the target service.

Business rules

  • All requests except /health require Authorization with a valid secret.
  • Supports one active secret plus optional rotated secrets.
  • Unauthorized requests are rejected before reaching protected services.
Last updated: March 31, 2026 at 15:17
By: Rafael Robles