Docs

Access Explorer

What this screen is for

Access Explorer answers one question: can this user do this thing, and if not, why? It resolves a username against a permission and tells you the outcome, so you never have to work it out by reading roles and policies yourself — or, far worse, by asking the user to try it and see.

It is the tool every other Settings page sends you to when something is denied.

Before you start

Access Explorer is admin-only. It is gated separately from the rest of Settings: holding platform-settings.*.read gets you into Settings, but the Access Explorer entry appears only for administrators.

If it is not in your submenu, you are not an administrator. Ask one to run the lookup — it takes them a few seconds.

Opening it

  1. Settings in the sidebar.
  2. Access Explorer at the bottom of the submenu.

Direct URL: /platform-settings/access-explorer

The interface

📸 Screenshot Placeholder: Access Explorer after a lookup. Mark: (1) the username field, (2) the permission field, (3) any scope selectors, (4) the results panel showing allowed or denied.

# Control What it does When you’d use it
1 Username Who you are asking about Every lookup
2 Permission The exact permission string Every lookup
3 Scope The cluster or environment to test against Any permission that can be scoped
4 Results Whether it resolves as allowed or denied The answer

Permission strings are matched literally. platform-settings.user.create and platform-settings.users.create are different strings, and the second one will report denied for everybody. Copy the string from the page that named it rather than typing it from memory.

Walkthroughs

Find out why a user cannot do something

  1. Settings › Access Explorer.
  2. Enter the username exactly as it appears in Users.
  3. Enter the permission string. The page that reported the problem names it — a 403 response includes it in the message.
  4. Set the scope if the permission is scoped: the cluster or environment they were actually trying to use.
  5. Read the result.

Confirm a change worked

After granting access, look the user up again before telling them it is done. This costs seconds and catches scoping mistakes, which are otherwise invisible.

Verify a denial is intentional

Before an audit or an offboarding, check that the permissions you believe are denied really are. A denial you have confirmed is worth considerably more than one you assumed.

Scenario

A developer reports “permission denied” and cannot say more than that.

  1. Ask them for two things: the exact URL they were on, and the error message. A Fenwave 403 names the required permission and the username it resolved — that is your input, and it saves guessing.
  2. Settings › Access Explorer, enter the username and that permission.
  3. Set the scope to the cluster or environment they were working in.
  4. Read the outcome:
    • Denied, unscoped too → they genuinely lack it. Find the right role, or create one.
    • Denied here, allowed without scope → the permission is granted but the policy does not cover this cluster or environment. Widen the statement deliberately, to that scope only.
    • Allowed → they have it, so the failure is elsewhere. The usual cause is the session permission cache: ask them to reload. If it persists after a reload, stop treating it as a permissions problem and look at the feature itself.
  5. After any change, look them up again to confirm.

Step 4’s third branch is the one worth internalising. “Allowed here but failing there” almost always means a stale session, and chasing it as a permissions problem wastes a lot of time.

When it doesn’t work

Symptom Cause How to check Fix
Access Explorer is not in the submenu It is admin-only, separate from the Settings gate — Ask an administrator to run the lookup
Every lookup returns denied The permission string is wrong Compare it against the string on the relevant page Copy it exactly; matching is literal
Result says allowed, the user still cannot act Session permission cache — Ask them to reload the page
Result differs depending on scope The policy is scoped to particular clusters or environments The policy statements Expected — widen the scope only where intended
User not found Username differs from the record Users Use the exact username

Next