$ every product image on this site is an unretouched screenshot of the running platform — demo tenant, fictional people, captured live
🛒 Platform · Self-service

Access requests people
actually understand.

A request catalog scoped to what each user may see, approval chains you design visually, and delegation that keeps decisions flowing when someone's away.

Request access

A shop window, scoped per person.

Users request access from a catalog filtered by audience rules — they only see what they're allowed to request, and they ask for the application, not the four directory groups behind it. Application mining spots the group families that already behave like one app, so you can front them in a couple of clicks. SoD conflicts are checked before the request even reaches an approver.

  • Requestability cascades: system → application → type → entitlement
  • Applications front their directory groups — the raw groups stop being individually requestable
  • The review step resolves the landing account per item: uses the existing one, auto-creates it, or says plainly that it's missing
  • Multi-step approval chains with quorums (all / any / N-of-M)
  • Self-approval is auto-detected and auto-resolved — no rubber-stamping your own request
  • Every request is a visible pipeline: who approved, who it is waiting on by name — and it does not end at "approved". A final step shows the rollout per system, so "approved, waiting on Entra" is distinguishable from "waiting on my manager", and a failed rollout is visible to the person waiting on it, not only to the helpdesk
  • "Typically approved in…" is measured, not promised: the median of this tenant's own last ninety days. A tenant with too few settled requests to say anything honest gets no number at all — a made-up estimate is worse than none
  • What you cannot request tells you why: an item nobody may request shows the rule that blocks it, instead of silently not existing. What is simply not for you stays absent — the catalog does not advertise other people's access
  • Renewal is never silent: it asks for how long, and re-runs the exact approval the original needed

The person who asked hears the outcome. Submitting is not the last you hear. Approved mails when the request is actually, fully approved — a half-approved chain never claims otherwise. Rejected carries the reviewer's written reason, verbatim. And "your access is live" is sent when provisioning lands, not when a form was filled. Withdraw a request and the people who were asked to decide it hear that too, instead of deciding something that no longer exists.

app.rapidvalue.eu/access-request
the request catalog — scoped to what you may see
the request catalog — scoped to what you may see

Approvals & delegation

Who requested what, for whom — in words.

Approvers see the request in business language with the requestor, subject and remaining chain spelled out. Out-of-office? Delegate your queue for a period — decisions taken on your behalf stay visibly badged and separately auditable.

  • One inbox for approvals, reviews and exceptions
  • OOO and standing delegations, scoped by work type
  • "On behalf of" badge — the trail never loses who actually decided
  • Forty identical approvals are one call, not forty clicks — and each item still walks the exact path a single decision walks: quorum, the self-review block, the delegated-decision marker, the evidence snapshot
  • One standing view answers the question nobody could ask before: what has been waiting longest, on whom. Across approvals, certifications, drift and findings at once — not per campaign
  • Before a manager clicks, the pane answers what happens if they do — "approving extends access last used 94 days ago; rejecting revokes it" — in words, not ids
  • Delegation shows its work: an estimate of what will route to your stand-in before you switch it on, and a digest of everything decided in your name while you were away
  • A Monday-morning digest — your approvals, your reviews, what expires this week — on a schedule the tenant sets, with quiet hours that are actually honoured, and your own preferences sitting beside your own data on your profile, so the cadence of your mailbox is not only somebody else's decision

The approver gets told. The mail goes to the approver of the step that is actually theirs — the lowest one still pending, never the whole chain at once. It can carry a decide link: one link, never Approve beside Reject, and the link names the item and the recipient, never the decision. The page you land on is the point — who asked, what for, why it landed with you, and the SoD and high-risk warnings the in-app pane would have shown. Rejecting always needs a written reason. Per tenant, off by default. The same mail — and the same one link — now covers certification rounds: a review lands, the reviewer hears about it, and a deadline coming due is its own message, not a hope. And nobody has to chase: an overdue decision gets its nudge from a scheduled job, first once, then on a cadence — "reminders are automatic" is a sweep here, not a sentence.

Or in the channel you already watch. A tenant can point approvals and certification rounds at a Microsoft Teams or a Slack channel — a real Adaptive Card and a real Block Kit message, not a mail forwarded into chat. The card carries exactly one link, and that is enforced rather than promised: the renderer refuses to emit a card with more than one action, with an action that is not an open-url, or with the words approve, reject, deny, revoke or certify anywhere in it. Deciding happens in the product, where the chain, the SoD warning and the written reason live. Three kinds of message qualify — an approval that needs you, a review assigned to you, a deadline coming due — every attempt is logged with the link redacted out of it, and like the decide link it is per tenant, off by default.

…/approvals
the approvals inbox — in words, not IDs
the approvals inbox — in words, not IDs

One rule model, central defaults, local overrides

Define a chain once. Override only where it differs.

Reviewer chains are named, reusable objects with per-type defaults: approval rules, review rules and role formalization all resolve through the same registry — inline override first, then the named chain, then the default for that type, then the manager as the universal fallback. No rule can end up with silently nobody to decide.

  • Named chains with quorums (all / any / N-of-M), reused across every rule workbench
  • Per-type defaults — a rule without a chain still gets the right reviewer
  • Every workbench overrides locally, never by copy-paste
…/governance-settings · reviewer chains
approval chains per process and object type — the default, built-in and fan-out for each
approval chains per process and object type — the default for each

See self-service running on your own data.

A 30-minute kickoff connects your HR feed and one system — working POC the same day.

Bring your HR feed plus one system you trust us to read — that is all the kickoff needs. No NDA, no second call with a sales engineer, no procurement form.