How the product is organized

Most identity governance tools are organised the way they were built: a menu that grew an entry per feature until nobody could find anything. RapidValue is organised by what you came to do, and the shape is small enough to hold in your head — one pinned block that is yours, five task groups, and one rule that keeps it from drifting back into a menu.

My work — pinned, and always first

The top block is not a group you open. It is pinned above everything else and holds only what is waiting on you: your inbox of decisions, the requests you made, the reviews assigned to you, and the catalogue you can request from. A reviewer who never configures anything can work from this block alone and ignore the rest of the product entirely.

Above it sits a Pinned strip you fill yourself — hover any item in a group and star it — and the topbar carries a Recent list of where you have just been. Both exist for one reason: your own working loop should outrank somebody else's taxonomy. Neither can leak a surface you may not see; a pin to something your role cannot open is simply skipped rather than shown and refused.

What you land on depends on your role — an end user lands on their own home, an administrator or auditor on a posture overview. Navigation never grants anything; it only reveals what your permissions already allow.

The five groups

Directory — what exists. The catalogue of nouns: identities, non-human identities (NHI — a service account, token, AI agent or other non-person identity), accounts, entitlements, roles, and the business objects your organisation is described by: departments, cost centres, legal entities, applications. You come here to look something up, not to decide anything.

Governance — decide, and set the rules. Everything where a human judges or a rule fires: access reviews and approvals, separation of duties (SoD — preventing one person from holding a toxic combination of access), privileged access such as break-glass and just-in-time elevation, the joiner/mover/leaver lifecycle, external onboarding, roles and policies, ownership, and compliance. The largest group, because it is the product.

Insights — look. The read-only lenses: access posture, the executive risk dashboard, security posture, activity. Nothing here changes anything, which is precisely why an auditor can be given this group and nothing else.

Systems & sync — the machine room. Connecting systems and applications, imports and reconciliation, provisioning operations, and the rules that classify accounts. The implementing partner's daily surface.

Admin — configure the tenant. Governance settings, platform access, environment and connections, the data model, automation, and your subscription.

Throughout the product, the comparison between the access that should exist and the access that actually exists is labelled Expected and Actual. Insights is where you read that comparison; Governance is where you act on it.

The rule that keeps it coherent

Every surface claims exactly one home. A new page hangs under one group and one of its sections — never as a new top-level group, never loose. Some surfaces are tabs of a parent page rather than standalone entries, and a few are reachable only by deep link, but each still belongs to exactly one place.

That rule is what prevents the menu-growth failure. It is also why this shape can change without the product sprawling: when the grouping stopped matching how people actually worked, the grouping moved — the surfaces did not multiply.

Underneath, every surface shares one shell: the same page header, the same object layout for any object you open, the same conventions for loading, empty, error and permission-denied states, in every supported language. That shared shell is why moving from a lens to an operation feels like the same product rather than a new one.

Configuration has three homes, not one

A familiar failure in this category is the single enormous settings page. Tenant configuration is split by who decides, so the person who should not be changing something usually cannot even find it:

The split is deliberate, and worth noticing during an evaluation: it is the difference between a product one administrator operates and a product a business can own.

💡 For a buyer

The groups double as a capability map. My work shows how far self-service reaches, Directory shows what the product actually knows about, Governance shows what you can decide and enforce, Insights shows what you can prove, and Systems & sync shows how deep the integration goes.

Further reading

• Reconciliation Engine — the engine behind most of Governance
• Governing API Access
• Webhooks & Notifications