Skip to content

Permission Badge or Available-Action Chip

Interface signifier artifact — instantiates Latent Affordance Surfacing

Renders, inline on the object itself, which actions this particular user is actually allowed to take right now — so a permission you already hold stops being invisible.

A whole class of latent affordance is a right the user already has and doesn't know it — edit access they assume is read-only, an approval they're entitled to grant, a role that unlocks actions they never try. Permission Badge or Available-Action Chip surfaces exactly that: a small, standing UI element on or beside an object that reads the current user against the permission model and shows what they, specifically, may do with this object, right now. Its defining move is that it is per-user, per-object, and persistent — not a one-time notice and not a generic list of what the system can do, but a live signifier that puts each user's own eligibility on the surface they are already looking at. It answers "am I allowed to?" before the user even thinks to ask.

Example

In an enterprise collaboration suite, a teammate opens a shared document assuming they can only read it — so they email the owner asking for changes. In fact they were granted edit access weeks ago; the capability has been theirs and invisible the whole time. A permission badge in the document header reads "You can edit," and a row of action chips — Comment, Suggest, Edit — shows exactly what is live for this person on this file. For a document they truly can't edit, the Edit chip is absent or shown locked, so the badge tells the truth in both directions: it surfaces the granted right and honestly withholds the one not granted.

Nothing about the permissions changed; the badge simply made the user's own eligibility legible at the object, turning a right they already held into one they can see and use.

How it works

  • Resolve this user against the model. Read the current user's role and permissions for this specific object at render time — the badge is a projection of the live eligibility model, not a static label.
  • Show the granted actions as standing signifiers. Render the actions the user actually holds as visible chips or a role badge on the object, so the permitted affordance is perceivable exactly where it would be used.
  • Keep it live and honest. Reflect changes when roles change, and represent absent permissions truthfully rather than dangling actions that will fail — a badge that promises an action it can't deliver is worse than none.

Its distinguishing trait is the per-user, per-object, always-on reveal of already-granted rights — a persistent signifier of eligibility, not a transient message.

Tuning parameters

  • Granularity — a single role badge ("Editor") versus per-action chips. The badge is compact; chips are explicit about each capability at the cost of surface space.
  • Positive vs. negative display — show only what the user can do, or also show locked actions. Showing locked actions hints at what a role change would unlock but risks nagging or upselling.
  • Placement — on the object, in a header, or on hover. Directly on the object surfaces best; tucked away, the badge becomes another latent affordance.
  • Persistence — a standing badge versus an on-demand or dismissible one. Standing keeps eligibility continuously legible; on-demand keeps the surface calmer but can be missed.
  • Refresh fidelity — how promptly the badge tracks permission changes. Stale badges lie in both directions — promising a revoked action or hiding a freshly granted one.

When it helps, and when it misleads

Its strength is killing the "I didn't know I was allowed" class of latent affordance — it puts the eligibility model on the very surface the user is looking at, so a granted right stops depending on the user guessing they have it. It is especially valuable where permissions are invisible by default and vary sharply from user to user.

Its central failure mode is staleness: a badge out of sync with real permissions is worse than none, because it promises an action that then fails or hides one the user actually has. The classic misuse is badging as upsell — showing locked chips purely to nag the user toward a purchase or upgrade rather than to inform. And a badge announces that a right exists without explaining its terms. The discipline that keeps it honest is to drive the badge straight from the live permission model, render it where the action happens, and keep positive framing truthful rather than promotional.[1]

How it implements the components

Permission Badge or Available-Action Chip realizes the eligibility-signifier side of the archetype — surfacing the rights a specific user already holds:

  • permission_and_role_badging — it is this component: the on-object badge or chip that shows the current user's role and the actions available to them at a glance.
  • intended_user_and_eligibility_model — it reads that model per user and renders the result inline, projecting who-may-do-what onto the object itself.

It does not spell out the terms, limits, or consequences of a right — that fuller disclosure is the Eligibility or Rights Notice sibling; it does not surface a capability the user has no word to search for (Search and Autocomplete Suggestion); and it does not stage advanced actions behind a reveal (Progressive Disclosure Panel). A badge signals what you may do, not the fine print of what it means.

Notes

The badge and the Eligibility or Rights Notice divide one job: the badge is the persistent, glanceable signal that a right exists and is available to this user; the notice is the fuller disclosure of that right's terms, limits, and consequences. The badge surfaces the affordance; the notice explains it. Show the badge where the action lives, and let it open into the notice when the user wants the detail — and remember that a badge is only ever as honest as the permission model it reads from.

References

[1] Role-based access control (RBAC) governs which actions a user may take according to their assigned role. The permissions it grants are frequently invisible in the interface; this badge is the signifier that surfaces them. RBAC is named here as a real, standard access-control model; the example is illustrative. ↩