Permission Configuration.
A single role-based control panel for 54 permissions — designed so an admin can operate the platform's most dangerous surface with confidence rather than fear.
At a glance.
"Permissions are dangerous to get wrong. So the design job wasn't just showing 54 toggles — it was making sure no one flips the wrong one without knowing who it affects."
What it is, why it exists.
As HireBound grew from small teams to larger agencies and enterprises, "who can do what" stopped being something you could handle informally. A recruiter shouldn't be able to delete sequences; a vendor should see almost nothing; an admin needs broad control but not owner-level authority. The platform needed real role-based access control — and, just as importantly, a way for customers to see and manage that control themselves.
Permission Configuration is that surface: a single screen where an admin picks a role, sees exactly which of the 54 permissions it holds, and toggles access resource by resource — with the changes staged as a draft until deliberately saved.
The design challenge was taming genuine complexity without dumbing it down. Fifty-four permissions across many resources is a lot of surface area. The interface had to make that scannable, safe to edit, and consistent enough that an admin never has to relearn the pattern from one resource to the next.
The rules that shaped the system.
The mandate: give customers granular, self-serve control over access — powerful enough for enterprise needs, safe enough that a mistake doesn't quietly hand someone the keys.
One Grammar for Every Resource
Every resource (Sequence, Bot, Template, Openings…) exposes the same four action tiers: Create, Read, Manage, Manage All. This consistency is the backbone of the screen.
An admin learns the model once and applies it everywhere, instead of decoding a different control per feature.
Manage vs Manage All
The single most important distinction in the model is scope: Manage lets you act on your own resources; Manage All lets you act on everyone's. Surfacing this as a distinct, explicit tier — rather than burying it — is what lets roles be shaped precisely.
A recruiter can manage their own openings without inheriting authority over the whole team's.
Structure over Complexity
Fifty-four permissions grouped into resource categories, each with a live X/Y progress badge (green when fully enabled, amber when partial) and Select All / Deselect All bulk actions.
An at-a-glance read of each category's state and a fast way to set it, instead of hunting through a flat list.
Safe by Default
The Owner role is locked and non-editable. Every change is staged as a draft with Reset to Last Saved and an explicit Save Changes commit. Each role shows its assigned-user count so an admin knows how many people a change will touch.
Owners always retain full access, and no permission change is ever one accidental click from going live.
How 54 permissions are organized.
Fifty-four permissions is only tractable when they're organized. The IA collapses the surface into a four-level hierarchy — the same shape for every resource, so learning one is learning all of them.
Resource Categories
Top-level grouping (Sequences, Openings, Templates, Admin, …). Each category shows a live X/Y progress badge.
Individual Resources
The concrete resources inside a category — the actual things a permission gates.
Actions
The uniform four-tier grammar: Create · Read · Manage · Manage All. Same shape for every resource.
Permission Scope
The raw scope string exposed on every toggle — auditable and verifiable, not a black box.
The scope string is the ground truth — it's what the API enforces. Surfacing it in the UI closes the gap between what an admin thinks they're granting and what the system actually grants.
Owner → Admin → Recruiter → Vendor.
Four core roles arranged as a hierarchy that mirrors how real agencies delegate — from untouchable ownership at the top to the thinnest sliver of vendor access at the bottom.
Owner
Ultimate authority over the account.
Owner is a system role. The lock is the UI-level guarantee that owners can never be restricted — even accidentally.
Admin
Run the account without owner-level authority.
Recruiter
Do the day-to-day work on their own or shared openings.
Vendor
External collaborators with the thinnest access surface.
The assigned-user count sits on the role itself so an admin sees the blast radius of a change before opening it.
Create · Read · Manage · Manage All.
Every resource exposes the same four action tiers. This is the grammar that makes 54 permissions learnable — decode it once, apply it everywhere.
Create
Bring a new resource into existence.
Read
See a resource without changing it.
Manage
Edit, update, or delete resources you own.
Manage All
Edit, update, or delete any resource of this type.
Manage vs. Manage All.
Grants authority over resources the user owns. A recruiter with Manage on Openings can edit and close the openings they created — and only those.
Recruiter with Manage on Openings → edits their own req, cannot touch a peer's.
Grants authority over every resource of that type, regardless of owner. This is the tier that turns a role into an operational admin for that resource.
Admin with Manage All on Openings → can reassign, close, or delete any req in the account.
Collapsing Manage and Manage All into a single "Manage" toggle would silently grant cross-user authority whenever an admin meant only self-ownership. Making the two tiers explicit is the difference between a safe permission model and a leaky one.
What we learned, card by card.
Agency Access Hierarchy
Mapped how agencies actually delegate: owners at the top with untouchable authority, admins running the account, recruiters doing the work on their own or shared openings, and vendors with the thinnest sliver of access.
The four-tier hierarchy wasn't a design invention — it was already how agencies described their teams. Any role model that fought that shape would fight the customer.
Drove both the default role set (Owner / Admin / Recruiter / Vendor) and the Manage vs. Manage All distinction.
Permission UI Failure Modes
Reviewed how permission screens commonly go wrong across enterprise SaaS.
The default failure mode is a flat, undifferentiated list of dozens of toggles that no one can scan and everyone misconfigures — the interface itself becomes the security hole.
Motivated the category grouping, per-category X/Y progress badges, and bulk Select / Deselect All actions.
Cost of a Wrong Toggle
Recognized that permission changes are high-stakes and hard to notice after the fact — a wrong Manage All is invisible until someone acts on it.
Speed of change was working against safety. There was no confirmation, no diff, no visible consequence — one click and it was live.
Produced the safety layer: locked system roles, the draft/save model with Reset to Last Saved, and surfacing assigned-user counts so the consequence of a change is visible before it's committed.
Auditability Requirements
For enterprise and compliance conversations (DPDP, customer security reviews), "trust us" isn't enough — the access model needs to be verifiable from the outside.
Buyers wanted to inspect exactly what a role could do, not read a marketing description of it.
Exposed the raw scope string on every permission (r:openings:read, w:admin:openings:assetsTransfer) so the model is transparent and reviewable.
Draft, review, commit — or reset.
Every high-stakes action is wrapped in the same deliberate flow: edits stage as a draft, the admin sees what will change, and nothing goes live until an explicit commit.
User edits permissions
Toggle any of the 54 permissions on a role.
Draft Changes
Edits are staged, not applied. The UI marks the role as having unsaved changes.
Review
Assigned-user count is visible on the role — the admin sees exactly how many people this change will touch.
Save Changes
Explicit commit — the only path from draft to live.
Reset to Last Saved
One-click bail-out. The draft is discarded and the role returns to its committed state.
Owner is a system role with all 54 permissions and no edit affordance — full access is guaranteed at the UI layer, not just the backend.
Every edit is a draft first. The role's live behavior does not change until Save is pressed.
The single explicit commit action. No auto-save, no ambient persistence — the admin decides when it goes live.
Reset to Last Saved discards the entire draft. There is always a one-click way back to the known-good state.
Visible on every role — 213 Recruiters, 10 Admins, 6 Owners. The blast radius is surfaced before the change, not discovered after.
Together these turn every permission edit into a deliberate, reversible action — the interface refuses to let an admin change access without seeing who it affects.
Contribution and business outcomes.
Designed a single control surface for 54 permissions
Replaced informal or hard-coded access with self-serve RBAC across all roles.
Established the four-tier action grammar
Create / Read / Manage / Manage All, applied uniformly to every resource — the consistency that makes the screen learnable.
Made Manage vs Manage All an explicit tier
First-class scope distinction that enables precise role-shaping (own resources vs. all resources).
Structured the complexity
Resource categories, colour-coded X/Y progress badges, and Select All / Deselect All so a large permission set stays scannable and fast to edit.
Built the safety model
Locked Owner role, draft/save with Reset to Last Saved, and up-front assigned-user counts so admins see a change's blast radius before committing.
Surfaced raw scope strings
Every toggle displays its underlying scope so access is transparent and auditable — useful for the customer's own security reviews.
Made HireBound enterprise-ready — granular RBAC is a hard requirement in security reviews and larger deals.
Reduced the risk of access misconfiguration — the single most common and costly permission-UI failure — through safe-by-default patterns.
Cut support load by making permission management self-serve for admins instead of an engineering/support ticket.
Strengthened the compliance story (DPDP / enterprise security) with a transparent, auditable access model.
Scaled cleanly with the customer base — the same screen serves a 6-person owner group and a 213-recruiter workforce without redesign.
Learned, improved, next.
Permission Configuration took the platform's most dangerous surface — who can do what — and made it something an admin can operate with confidence rather than fear. The win wasn't showing 54 toggles; it was the grammar, the structure, and the guardrails around them.
Good permission systems are invisible when designed well, and only become noticeable when they fail. The discipline underneath — one consistent model, grouped for scannability, staged for safety, and transparent enough to audit — is what a customer feels as "we trust this," long before they can articulate why.
That's what turns raw access control into something an enterprise will actually trust — and the same grammar, structure, and safety patterns become the template every future admin surface at HireBound is built on.