Permissioning
Access Levels protect your data
One of the most important but often overlooked features a back office platform should have is the ability to establish access levels.
It’s not rare for a startup to happily start using a platform on its earlier days, only to become frustrated later on. As the company grows, it finds out that what worked for a small team won’t work when it grows to dozens, or even hundreds of people. Sometimes, problems arise from people messing with the data accidentally. Other times, troubles come in the form of someone getting hold of information they shouldn’t be privy to.
There are workarounds, of course. Some companies create spreadsheets that only the management has access to, or that most employees can’t edit at all. Maybe, if they’re using some sort of SaaS platform already, they’ll try to apply the same kind of logic and create separate workspaces for their important information.
This, of course, is not the ideal solution. It often comes at the cost of splitting data into separate tables or implementing safety steps that slow down processes through grinding bureaucracy. Data becomes unreliable. A manager has to spend precious time sorting information just to send it to a team member that can’t fetch it themselves.
So this company usually faces two options:
- Leave data open and unprotected in order to keep processes agile;
- Create bureaucratic layers of protection in order to increase security.
jestor, however, presents a third option: full control over your data.
How permissioning works
Permissioning is the act of creating access levels that dictate what a user can see or do in jestor. And, sometimes more importantly, what they can’t see or do.
This is done through two different levels of permissions:
Platform Level: whether a user can add new users or change access levels, as well as create new tables or dashboards.
Tab Level: which tables, dashboards or pages a user has access to, as well as what they can do inside them.
Regarding the Tab Level permissions, there’s also a wide array of different parameters you may set for a user:
Filters: conditions a record has to satisfy in order to be shown to a user. In other words, you can specify the rules that dictate whether a user has access or not to a record (such as “type” is “Active” or “amount” is greater than “1000”.
Excluded fields: fields/columns that a user won’t be able to see. As far as they’re concerned, these fields don’t even exist.
Readonly fields: fields/columns whose values a user won’t be able to edit.
Structure management: whether a user can create, edit or delete fields.Create or delete: whether a user can create or delete records.
Permissioning in action
Let’s go through an example to show how permissioning works. Here’s a jestor account through the lens of an Admin user.
As you can see, this user has access to all sorts of tabs. They can even add new users using the menu, should they want to.
Now, let’s access the same jestor using a user that:
- Can’t add users or change access levels;
- Can’t create tables or dashboards;
- Only has access to the Clients table, in which:
- They can only see clients attributed to them by the “Owner” field;
- They can only see clients that have “Amount” lesser than “1000”;
- They can’t see the “Amount” field;
- They can’t change the “Name” field.
It’ll look something like this:
As you can immediately see:
- Add Users and Templates are not available on this user’s menu;
- They can’t create fields on this table (there’s no + icon on the table header).
If we click on the + icon on the menu itself, it’ll not give this user the option to create a table or dashboard, only choose the tabs they’d want on the menu. Also, they only have access to the Clients table and to the Reports page. Every other table or dashboard is not available to them.
Note that the field “Amount” is not present in this table, and that if this user tries to edit a client name, they won’t be able to:
Finally, only one record appears on this table: one that satisfies both the “Owner” is the user and “Amount” is lesser than “1000” conditions. This is what an Admin user would see on the same table:
What’s cool about the filters is that they work even if the user has no access to a bit of information the filter applies to. For example, we’re filtering for “Amount” even though this user doesn’t know this field exists. This is very useful for temporary conditions: you may filter for “Owner” and exclude this field from a user access level. This way, they’ll only have access to that record as long as the manager wants them to.
Why is this so important?
If you try to maintain data security without having these kinds of granular access levels, you’ll end up having to create workarounds and auxiliary structures that split or copy the information. For example, a Clients spreadsheet for the Sales team and a separate Clients spreadsheet with financial data. This can lead to all sorts of problems, such as having outdated information in one of the spreadsheets.
With permissioning controls, you can have one single source of information: and then limit what users can see or do with it. This way, you’ll always build the best possible structure without having to worry about how to share it. Access levels will work for the processes, not the other way around.
Also, this level of control empowers you to use jestor however you like it. If you wish to grant a client access to your jestor so they can send requests or check on their project, you can do it: they’ll only have access to what you want them to.
Learn more about permissioning
If you wish to understand more about how permissioning works, our documentation will tell you everything you need to know.