Everyone can do everything to start

In the beginning, all team members have access to all actions and all data. As you grow from a couple of people, this becomes a liability. As your platform’s feature set grows, this also means an increased number of actions that everyone can perform.

But basic user permissions are useful

Eventually, it becomes beneficial to implement access controls and permissions.

The most common purpose of gating actions behind permissions is to control the flow of information. For instance, you might not want everyone to have access to personal or financial information.

In the early stages, however, the more important benefits are to reduce errors and to make a simpler, more focussed interface.

With an increase in features, the likelihood that someone might make a mistake by doing something they aren’t in charge of increases.

For training

Training difficulty is directly proportional to the number of actions that need to be explained.

By using permissions, you only show and explain actions relevant to the trainee’s job.

To clean up pages for a specific job

Permissions also facilitate building focussed interfaces that can use technical jargon or numbers. If everyone has access to a page, it needs to be easy to understand by everyone. Which means it can’t be overly detailed or technical.

To improve processes

Testing out new processes is easier if you can test it with a limited subset of users.

As an example, consider issuing refunds. If everyone can create refunds, that means a junior team member could issue one to keep a customer happy. They might not consider alternative ways of solving the issue. It might mean that finance might not know that a refund needs to be processed. The junior team member might not be aware of the entire process for refunds.

The first implementation is simple

You add a setting that contains a list of emails. Those users then have the permission and therefore can see and perform the action.

You’re not likely to end up with more than ten.

Once you start building domain-specific dashboards, you can continue to use these permissions to hide entire pages rather than individual actions.

On top of which you can build a complete solution

A full-fledged implementation that you aren’t likely to need till much later is more complex. It would be built by having roles that contain multiple permissions. You should organize permissions into a tree structure where selecting the root selects all the leaves as well. At this point, you’re likely to need permissions for each action. More sensitive fields might also be restricted.

After grouping permissions into roles, users can get assigned multiple roles. The sum of all the permissions in the roles would be the permission the user has.

Soft permissions

It’s also useful to have “soft” permissions that allow the user to act, but an informational or warning popup will be shown. The popup should have a brief explanation of how the feature works, the process behind it, and who might be contacted for further information.

But don’t go too detailed in the beginning

The biggest potential pitfall when building the first version is going overboard and making it too detailed. Prematurely adding detailed permissions creates additional work in managing and maintaining them without the proportional benefit.