Permisly Turns Permission Rules Into a Reviewable Model

A permission spreadsheet can look complete until someone asks a practical question: can a manager edit a deal owned by someone in the same group, if the deal is still open, while hiding its sensitive fields? A grid of roles and actions is not well suited to that answer. It records the rule, but often leaves the relationship and condition in a note that people have to interpret during a meeting.

That is the problem Permisly is aimed at. It is a web-based design layer for access control, not an identity provider or a runtime permissions system. The intended work happens before implementation, when product, security, and engineering still need to agree what the rules mean.

A permission model with more than two dimensions

Permisly describes access through roles, resources, actions, and the actor's relationship to a record. The example on its page uses a Manager working with Deals. The manager has full access to their own records. Records from the same group can be edited only while their status is Open. Records from another group are view-only, with sensitive fields hidden. A superior's record is unavailable.

That example is more useful than a generic “Manager can edit” row because it shows where the decision changes. The product treats scopes such as own record, same group, other group, and superior's record as part of the model. Field-level exceptions and conditions sit alongside the permission rather than in a separate comment column.

This makes Permisly relevant to teams dealing with relationship-based access control, often shortened to ReBAC, or with applications where role-based access control needs additional conditions. It can also give a team somewhere to discuss field-level permissions without immediately expressing every rule as application code.

From model to review call

The core workflow has three stages. First, a team builds a hierarchy of roles, resources, actions, and relationship scopes. The page presents this as a structure that can be read one role at a time, rather than as one large matrix.

Next, the model can be sent for review. The developer describes an approval flow in which a lead can review, edit, and approve the design, with changes made visible. That is a useful distinction from passing around a spreadsheet attachment, although the supplied information does not establish how detailed the change history is.

Finally, Presenter mode is meant for grooming calls. It turns a rule into plain language, such as a manager having full control over their own deals, conditional edit access within their group, and redacted fields elsewhere. A read-only share link lets others follow along without logging in, according to the product description. The free plan includes one RBAC workspace, while paid upgrades add workspace capacity and approval or sharing features depending on the plan.

You can see Permisly's permission modelling workflow in the product's own example. The page also describes CSV import with best-effort mapping, PNG export, custom permission states and colours, and inheritance with overrides. Inheritance is presented as a way to avoid creating separate roles for every regional or organisational variation, a common route to role explosion.

Where it fits, and where it stops

Permisly is not the system that authenticates users, evaluates requests in production, or applies policies to an API. Its own positioning is explicit: this is not IAM. The output is a shared design and review artefact for a later implementation. That boundary is important. A signed-off model still has to be translated accurately into the application's authorization layer, and the supplied material does not claim that Permisly performs that deployment.

It also appears best suited to teams willing to model access deliberately. A simple application with one or two roles may not need a separate visual layer. Conversely, a complex model may still require decisions that the example does not settle, such as how multiple roles merge, how conditions are evaluated, or how the design stays aligned with changing code. The page raises multiple-role merge rules as something teams should document, but does not describe an automatic answer.

The web-only platform is another practical constraint. There is no desktop or mobile application in the stated platform list. That may be fine for a distributed review process, but it makes browser access part of the working setup.

Who should use it

Permisly is aimed at product owners, security and GRC teams, engineering leads, and implementation partners who need to explain authorization rules aloud before engineers build them. It is particularly plausible for multi-tenant software where access depends on ownership, group membership, record status, or which fields a person is allowed to see.

It is not a replacement for IAM, policy enforcement, testing, or code review. It is a place to make a complicated access control model legible and get agreement on it. If the current problem is that people cannot agree what “Manager can edit” really means, Permisly addresses that gap. If the problem is enforcing an already-agreed policy in production, this is the wrong layer.