Spreadsheet
Every cell collapses to the same “View”.
RoleViewEditDelete
AdminYYY
ManagerYYN
StaffYownN
No relationship. No field exception. No condition. The interesting cases get buried in a comment column nobody reads on the call.
RBAC design tool
See Your Permission Model. Get Buy-In. Present It Live.
Your access control lives in a spreadsheet. Permisly is a visual RBAC design tool for modeling roles, resources, and field-level permissions, getting sign-off before implementation, and presenting the hierarchy live in grooming. Not Okta — the design layer teams need before implementation.
Free includes one RBAC workspace. Solo and Pro add workspace capacity monthly.
Permisly PRESENTER
Approved
Manager · Record
Own record
ViewCreateEditDelete
Same group
ViewEditDelete
* Only while record status is “Open”
Other group
ViewEditDelete
* Read-only, sensitive fields hidden
Superior’s record
ViewEditDelete
In plain language. A Manager fully manages their own deals. In their group they can edit only while the deal is Open. Other groups are view-only with sensitive fields hidden. They cannot see a superior’s record.
Built for the people who have to explain access out loud.
Product ownersSecurity / GRCEng leadsImplementation partners
The problem
Why Your Permission Spreadsheet Is Broken
A flat grid answers “can Editor view?” It can't answer “can a Manager view a record created by their own Staff, but not one from another group, and only if sensitive fields are hidden?” That's not a formatting problem. It's a dimensionality problem. Permisly models the fourth dimension a spreadsheet can't: the relationship between the actor and the record, which is exactly what relationship-based access control is built on.
Permisly
The same actor, scoped by relationship.
ScopeViewEditDelete
Own recordFullFullFull
Same groupFullIf Open
Other groupRedacted
Relationship is a first-class axis. Conditions and field hiding sit next to the permission, not in a footnote three tabs over.
How it works
Model. Approve. Explain.
Design the RBAC model once. Send it for sign-off. Read it aloud on the grooming call without translating a permission matrix in your head.
01
Build the hierarchy
Roles, resources, actions, and relationship scopes, yours rather than a template that almost fits.
Role · ManagerResource · DealsAction · EditScope · Same group
02
Get it approved
Send a link. Your lead reviews, edits if needed, approves. You see exactly what changed.
Send link → Review → Approve → Signed off
03
Present it live
Presenter mode steps through one role at a time, in plain language, built to be read aloud on a call.
Team Lead / DealsView · FullEdit · Conditional
Features
What Permisly Replaces (Hint: Not Okta)
The fourth dimension
Relationship-scoped permissions
Access is not only role × action. It is role × action × relationship to the record, with own, same group, other group, and superior scopes, plus field-level exceptions attached to each scope.
Own recordView Create Edit Delete
Same groupEdit if Open
Other groupView, sensitive fields hidden
Inheritance with override
Set default permissions once at the parent role and override only where it differs.
Custom permission levels & colors
Define workspace-specific permission states beyond a generic 3-state grid.
CSV import
Import an existing CSV access model with best-effort mapping instead of starting from scratch.
Read-only share links
Zero-login viewer links so your whole team can follow along live on grooming calls.
Presenter mode
Read the model out loud. Don’t decode it.
One role at a time. Plain language. Built for the fifteen minutes on a grooming call when everyone is staring at you and the spreadsheet is already lying.
What you say on the call
“A Manager can fully manage their own deals. On deals in their group they can edit only while the record is Open. On everyone else’s deals they can view, but salary and notes are hidden. They cannot see a superior’s record at all.”
Pricing
Choose the workspace limit that fits your team
Start with one RBAC workspace for free, then add capacity as your access model grows. Every plan is priced around the workspaces you manage.
Free
$0forever
1 RBAC workspace
- 1 RBAC workspace
- Hierarchy and permission matrix builder
- Presenter mode and PNG export
Solo
$9per month
5 RBAC workspaces
- 5 RBAC workspaces
- Approval workflow
- Read-only share links
Recommended
Pro
$19per month
25 RBAC workspaces
- 25 RBAC workspaces
- Approval workflow
- Read-only share links
FAQ
Questions
Role-based access control means users have permissions based on their job (role), not individual rules.
Before engineering builds it. Catching mistakes in a grooming call is cheaper than refactoring production permissions.
A role is a job (editor). A permission is an action (edit posts). Roles group permissions.
They hide relationships, are hard to present live, and drift from code.
Restrictions beyond role × action, e.g. product.vendor_id = user.vendor_id.
It prevents role explosion. One admin role + conditions beats admin_US / admin_EU / admin_APAC.
RBAC uses roles; ABAC uses attributes. Most apps use RBAC plus field-level conditions.
Combine permissions from each role. Document the merge rule.
Start with one hierarchy
Start Free—No Card Required
No card for Starter. Open a workspace, import a CSV, or start from the Deals example on this page.
Start free