User Roles & Permissions
Keep tight control over user access levels using User Roles & Permissions
Introduction to Permissions 🛡
Enabling Permissions unlocks huge value in your Noloco app building experience.
Whether you're building an Internal Tool, a Client Portal or a Partner Portal, it’s absolutely critical to maintain tight control over who has access to what information.
Permissions let you control what your users can see, and how they can interact with data in your apps. You can use permissions to:
Limit which pages the users can access
Limit which records a user can read, edit, create or delete
💡 Let’s say you’re building a Recruitment app to help manage open positions, candidates, and job applications. You’ll likely have to store confidential data, such as their salary amount, and applicant reviews, that only certain types of users should see. You’ll want to secure the sensitive data without making life harder for recruiters, hiring managers, and interviewers logging in to the app.
With Noloco's flexible, user role and permissions model, it’s easy to decide which data can be accessed by what type of User. You can balance security and convenience and still make sure all users can easily access the data they need.
In this support guide we're going to detail exactly how to use permissions, when to use them and where you can use them.
Who can use this feature?
🛡 Permissions are available on all plans. Advanced Permission functionality such as; Field Level Permissions (CRUD) & adding custom User Roles are available on the Team plan and above.
Levels of User Access
There are 3 different features to control access levels within your Noloco app
API/Database layer - Permissions
UI Layer - Visibility Settings
Collection Filters
In this guide we're going to walk you through how you can control access at the database layer using Permissions & User Roles. However, let's first outline the 3 different features and where they are configured.
1️⃣ API/Database layer - Permissions
⚙️ Configured from the Data & API tab
Collections Access to collection-level data is the simplest thing to control. By setting permissions on a particular collection, you can prevent a group of users from accessing records of that collection (Start & Pro plan) and from creating, viewing, editing, any fields of that object (Team and Enterprise plan).
Through the use of Roles, you can manage the collections that users can or cannot access along with the field permissions they have for each collection.
For example, you can create a permission applied to Users with the 'Hiring Manager' role whereby they can only view Position records that they are associated with.
🔗 This is made possible by creating a link between the target collection(s) and your Users (See more in User Lists).
Fields You can restrict access to certain fields, even if a user has access to the Collection.
For example, you can make the salary field on the 'Position' collection invisible to interviewers but visible to hiring managers and recruiters.
2️⃣ UI Layer - Visibility Settings
⚙️ Configured in the Portal when in 'View Configuration' edit mode under the 'Visibility tab'
Using Visibility settings, you can define visibility rules for each page and section on each page.
Define rules by:
Internal vs Client (External)
User Role(s)
Custom visibility rules
3️⃣ UI Layer - Collection Filters
⚙️ Configured in the Portal when in 'View Configuration' edit mode under the 'Configuration tab'
Using Filters on your Collection in the front-end Portal. You have the option to configure what Logged in Users can/cannot see. In the above screenshot, Logged In Users will only see records they are linked to - similar to how you can setup a permission rule.
Although you can configure the visibility of data using filters on the user interface, the use of Permissions works at the API level. That means any permissions you specify apply even if you query or update the data via API calls. Therefore, the security of your data is protected regardless of how users get to it.
How to Configure a Permission in 2 Steps👩💻
Walkthrough of how to configure User Access using Permissions (database layer)
⚙️ Configured from the Data & API tab
Step 1: User Role 👤
The first step is choosing or creating the User Role the permission will be applied to.
By Default, Noloco creates two out of the box roles ready for use: Team Admin & User.
The 'User' role is designed to be your default external user role. (such as your Clients or Partners logging in to use your app)
Whereas, the 'Team Admin' role is designed to be your default internal user role given to Users that need access to everything in your app (such as your employees or other members of your team building Noloco)
These roles are available to use on all Plans of Noloco.
Learn more about the difference between Internal Users vs Clients here.
However, for businesses or organisations that may have different types of Internal users & external users logging into your Noloco app, you may want to create custom roles to apply the correct permission level to them.
Note: Additional custom roles are available on the Team & Enterprise Plan only.
Once you have chosen the role(s) the permission will be applied to you can proceed to 🔗Step 2 - Create a Permission.
⚡️💡Configuration Scenario: Creating Custom Roles for a Recruitment app💡⚡️
For this support guide's configuration scenario, we're going to create two new custom roles:
Hiring Manager
Interviewer
To do this;
Navigate to the Settings tab > User Roles
From here, we will create two custom roles as follows;
Step 2: Create a Permission 🛡
Hiring Managers Andy, a hiring manager, should be able to access recruiting records related to his open positions, but shouldn't have access to other recruiting records.
Interviewers Melissa is an engineer who interviews candidates for highly technical positions. She should only be able to view & edit the positions to which she's assigned as an interviewer. Also, she shouldn't be able to view salary values for any of the positions, as that’s sensitive information that has nothing to do with her job.
Permission setup for Hiring Manager
Follow the Steps below using the Screenshot above as a guide
Permission setup for Interviewers
Follow the Steps below using the Screenshot above as a guide
Great work! You've created your first permission 🎉
Testing 1..2..3...
Lets now test that our configuration works using the 'view as another User' function 🧐 🔍
Follow the Steps below using the above Screenshot as a guide
There you have it - You have all the knowledge to configure robust Permissions 🎉
❔🤔FAQs User Role & Permissions
Question❔If a user role doesn’t have any permissions for a particular collection, does this mean they simply can’t access at all? Or is it the other way around and they can can access everything?
Answer ✅ If permissions are enabled for a particular collection, and a particular user role hasn't got any permission rule setup, then they won't be able to access anything.
Question❔If a role is attached to 2 different permission rules on the same collection, which rule is used?
Answer ✅ Permission rules are additive, as such, if a role is associated with two rules, both rules will be applied. If a filter is used in either (or both) rules, the user will be able to see the logical AND of that filter. I.e. both filters are applied. For field permissions, if any of the rules gives certain permissions to a field, users with that role will have that permission. For example, a base rule might give all user roles no access to update a status field. But a Manager role might have another permission rule that gives them access to update the status field. Then all managers could update the status field.
Question❔If a user role has the “access all data” option checked as true, is it worth adding that role to collection level permissions (given they can access and edit everything anyway)?
Answer ✅ For a role that has "access all data" you won't be able to add the role to any permissions, because permissions don't apply to those roles
Question❔When setting up a User Role, what does the "Modify App" selector do?
Answer ✅ This indicates that Users of this role are considered a Builder👷, however Users with such a role must also be added as a Collaborator to complete their Builder User setup. I.e They receive access to all builder privileges of a builder, such as access to builder tools.
Question❔When setting up a User Role, what does the "Team Member" selector do?
Answer ✅ This will mark Users with this role as an internal user and gives them internal views of all modules (Messaging, File Sharing & Billing)
Question❔When setting up a User Role, what does the "Access All Data" selector do?
Answer ✅ This will mark Users with this role as a Data Admin. This awards them with access to the App & Data tab from the admin sidebar
Last updated
