Good justifications write themselves

Your authorization system needs context about why users have access to resources. You might think this is just for compliance — user access reviews, audit trails, the usual checkbox exercises. But context matters more than that.

Access should be explainable. When you understand why someone has access, you can make confident decisions about managing it. It’s hard to know whether it’s safe to remove access if you don’t even know why it’s there to begin with. When you’re reviewing audit logs, meaningful context helps you quickly understand what changed and why.

The typical implementation is a “justification” field on access requests. A user wants Salesforce access via Slack, they get a text box. What do they actually write?

Please give me access to Salesforce

working on project Alpha

I’m a new SDR

asdf

This isn’t the context you’re looking for. This is users trying to get past your form validation so that they can get back to work. And this information decays: we canned Project Alpha two years ago (RIP) and Leo has been promoted to Account Executive. (Congrats, Leo!)

Some organizations try structured justifications with regex patterns:

bug #12345

Acme Inc. support ticket #ABC123

This works well when access is tied to specific work items. If the only reason an individual needs access is due to a specific bug or support ticket, this works great! But who says your ticket has sufficient context and isn’t just yet-another-text-box? Most access requests aren’t about one-off tasks — they’re for routine work that happens every day without a corresponding ticket number.

Most justification should be inferred. If someone works in Sales, of course they need Salesforce access. If they’re on the infrastructure team, they probably need AWS access. You already have this context — job titles, team membership, project assignments. Use it.

You’ll still need that freeform text field as an escape hatch for truly exceptional cases. But recognize it for what it is — a last resort that will generate lower-quality context than the inferred or structured justifications you can implement for most scenarios.

Good context doesn’t have to come from a literal justification field. When you’re doing access reviews or investigating changes, you should already have enough information to understand why access exists. If you don’t, fixing your role definitions and team mappings will serve you better than asking users to fill in more text boxes.

Context is essential for explainable access, but you have multiple ways to get it. Infer it from existing organizational data whenever possible. Use structured justifications for specific work items. Reserve freeform explanations for genuine exceptions. Design your permissions around these different sources of context, and you’ll spend less time chasing users for explanations that don’t actually explain anything.