User Access
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.
Click me to expand
🔗 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.
User
Team Admin
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:
  1. 1.
    Hiring Manager
  2. 2.
    Interviewer
To do this;
Navigate to the Settings tab > User Roles
From here, we will create two custom roles as follows;
Interviewer: click to expand
Hiring Manager: click to expand

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
Click to expand
Follow the Steps below using the Screenshot above as a guide
  • Navigate to the Data & API tab
  • Hover over the Collection to access the Permissions icon 🛡
  • Select the Permissions icon
  • Enable Permissions
  • Select '+ New'
  • Configure your Permission
    1. 1.
      Name it something memorable
      • I titled mine 'Positions Permission - Hiring Manager'
    2. 2.
      Choose the User Role(s) this permission will be applied to
      • In this scenario, this permission will be unique to the 'Hiring Manager' role
    3. 3.
      Decide if the role should have access to all records or only some records
      • In this scenario Hiring Manager Users should only have access to records where they are the associated Hiring Manager contained in the linked field on Position records
    4. 4.
      Determine the field-level permissions
      • In this scenario, we want Hiring Manager Users to be able to Read, Create and Update Position records where they are the Hiring manager.
    5. 5.
      Press Save
Permission setup for Interviewers
Click to expand
Follow the Steps below using the Screenshot above as a guide
  • Navigate to the Data & API tab
  • Hover over the Collection to access the Permissions icon 🛡
  • Select the Permissions icon
  • Enable Permissions
  • Select '+ New'
  • Configure your Permission
    1. 1.
      Name it something memorable
      • I titled mine 'Interviewer - Positions Permission'
    2. 2.
      Choose the User Role(s) this permission will be applied to
      • In this scenario, this permission will be unique to the 'Interviewer' role
    3. 3.
      Decide if the role should have access to all records or only some records
      • In this scenario Interviewer Users should only have access to records where they are the associated Interviewer contained in the linked field on Position records
    4. 4.
      Determine the field-level permissions
      • In this scenario, we want Interviewer Users to be able to Read, and Update Position records where they are the Hiring manager. However they will not have the ability to create Position Records.
    5. 5.
      Press Save
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 🧐 🔍
Click to expand
Follow the Steps below using the above Screenshot as a guide
  • Navigate to the 'view as another User button 👥' next to the Edit mode toggle
  • Select the User with the Role you wish to test with
  • Verify the records displayed are correct and working!
There you have it - You have all the knowledge to configure robust Permissions 🎉
Copy link
On this page
Introduction to Permissions 🛡
Levels of User Access
1️⃣ API/Database layer - Permissions
2️⃣ UI Layer - Visibility Settings
3️⃣ UI Layer - Collection Filters
How to Configure a Permission in 2 Steps👩‍💻
Step 1: User Role 👤
Step 2: Create a Permission 🛡
Testing 1..2..3...