Permissions Quick Start

Quick start guide for setting up permissions in Noloco apps

Get up and running with secure user access control in your Noloco app. This guide helps you choose the right approach and implement permissions quickly.

When Do I Need Permissions?

Use permissions when you need to:

• Restrict data access to specific user groups

• Control who can edit sensitive information

• Build client or partner portals with limited access

• Create multi-tenant applications

• Hide confidential data from certain users

Quick Decision: If you're building an internal team tool where everyone should see everything, you might not need complex permissions. For client portals, partner access, or multi-tenant apps, permissions are essential.

Permissions vs Visibility vs Filters

Choose the right approach for your security needs:

Method	Security Level	Use Case	Where to Configure
Permissions	🔒 High - API/Database level	Secure data access control	Data & API tab
Visibility Rules	🔓 Medium - UI level only	Hide pages/components	Build mode > Visibility tab
Filters	🔓 Low - Display only	Show subset of data	Build mode > Configuration tab

Quick Rule of Thumb:

• Use Permissions for sensitive data that must be secure

• Use Visibility Rules to improve user experience by hiding irrelevant UI elements

• Use Filters for data organization and user convenience

5-Minute Permission Setup

Step 1: Plan Your Access Model (1 minute)

Ask yourself:

• Who are your user types? (e.g., Admins, Agents, Clients)

• What data should each type access?

• Should users see only their own records or all records?

Step 2: Set Up User Roles (2 minutes)

1. Go to Settings > User Roles

2. Create roles for each user type:

   • Admin (full access)

   • Agent (limited access)

   • Client (restricted access)

3. Assign roles to your users

Step 3: Configure Table Permissions (2 minutes)

For each sensitive table:

1. Go to Data & API tab > hover over table > click 🛡️

2. Enable permissions if not already on

3. Add permission rules for each role:

   • Choose role

   • Set record access (all vs filtered)

   • Configure field permissions (CRUD)

4. Save each rule

Common Permission Scenarios

Scenario 1: Client Portal

Goal: Clients only see their own data

Setup:

1. Create "Client" role

2. Add record-level permission: Client Company equals User's Company

3. Hide internal fields: disable Read permission on sensitive fields

Scenario 2: Agent/Team Access

Goal: Team members only see assigned records

Setup:

1. Create "Agent" role

2. Add record-level permission: Assigned Agent equals Logged in User

3. Prevent creation: disable Create permission for agents

Scenario 3: Multi-Tenant App

Goal: Each tenant sees only their organization's data

Setup:

1. Create "Tenant User" role

2. Add record-level permission: Organization equals User's Organization

3. Configure field access per tenant needs

Testing Your Permissions

Quick Test Process:

1. Use "View as User" (👥 icon in build toolbar)

2. Select test user with restricted role

3. Navigate the app - can they see what they should?

4. Try restricted actions - are they properly blocked?

5. Test with different roles to ensure each works correctly

Red Flags to Watch For:

• Users can see records they shouldn't

• Sensitive fields are visible to wrong roles

• Users can create records when they shouldn't

• Permission rules don't seem to apply

Next Steps

Once basic permissions are working:

1. Add field-level permissions for granular control - Field-Level Permissions Guide

2. Set up visibility rules for better UX - Page Visibility Guide

3. Learn advanced patterns - Record-Level Permissions Guide

4. Test thoroughly - Testing as Other Users

Quick Troubleshooting

Problem: Users can't see any records after enabling permissions Solution: Make sure you've created permission rules for each user role

Problem: Permissions don't seem to work Solution: Check user role assignments and verify rules are saved

Problem: Some users see too much data Solution: Review record-level permission conditions and test with "View as User"

Problem: Fields are still editable when they shouldn't be Solution: Check field-level update permissions and user role assignments

Important: Always test permissions thoroughly before deploying to production. Use the "View as User" feature to verify each role's access is working as expected.