Platform Console

What this achieves

The Platform Console is the administrative surface for the staff who run Humavera itself, not for the administrators of any company using it. It manages the customer workspaces on the platform, the subscription packages they can buy, and the rollout of features across them.

This is not a tenant surface

If you administer your own company’s workspace, this section is not for you and you will not see it. It belongs to Humavera platform staff, not to any role inside a customer’s workspace.

It also does not give access to any company’s HR data. The console manages workspaces as accounts — their plan, their status, their entitlements — and the platform boundary is enforced by default: a request for a company’s employee data is denied to the platform role rather than being permitted on trust.

Example: platform staff can see that HC Corp is on a given plan and how many seats it uses. They do not open Priya Raman’s employee record or read anyone’s payslip.

Tenant lifecycle

A workspace can be created, locked, suspended, and reactivated. Suspension revokes access immediately rather than deleting anything, so a company in a billing dispute keeps its data and loses the ability to reach it until the account is settled.

Example: a suspended workspace keeps its records intact. Nothing is destroyed by suspension and reactivating restores access to the same workspace, which is what makes it a safe intermediate step.

Subscription packages

Packages are composed here: which modules and features they include, per-employee limits, and pricing. A package can be built, activated, cloned, and deprecated.

Cloning is how a package changes without disturbing existing customers — a new version is created rather than an active package edited underneath the companies already on it. Deprecating retires a package from sale without removing it from those already subscribed.

Negotiated arrangements are supported alongside the standard packages, including manually assigned packages and custom credit allocations for enterprise agreements.

Plan-change reviews and demand signals

Downgrade requests arrive in a review queue for approval or denial, so a plan change that would reduce a customer’s entitlements is a decision rather than an automatic outcome.

The console also collects demand signals: sales inquiries and prospect leads, and requests from customers for payroll support in countries not yet covered, aggregated so the roadmap reflects real demand rather than anecdote.

Feature flags and rollout

Features can be released gradually rather than switched on for everyone at once.

Option	Description
Global	On or off for the whole platform.
Plan tier	On for customers on particular plans.
Allowlist	On for named workspaces.
Percentage	On for a consistent proportion of workspaces, so a given workspace does not flicker between states.

Example: a new capability is enabled for a handful of named workspaces first, then widened by percentage once it holds up.

Platform-wide communication

System announcements and a changelog broadcast to every workspace, which is how planned maintenance and new releases reach customers.

What happens next

Platform work sets the boundaries a customer’s administrators then work inside. A package decides which sections a workspace can open, a feature flag decides whether a capability is available to it, and both surface to the customer in their own settings — where locked sections and plan comparisons are explained.

In this section

Customer workspaces:

Plans, packages, and credits:

Sales and demand:

Rollout and communication:

The training directory:

Platform configuration:

Check platform-wide settings