Field-level permissions

Learn how to use field-level permissions to control which users can read, update & create data in Noloco apps.

What are Field-Level Permissions?

Field-level permissions go beyond record-level permissions to provide precise control over specific fields within a table. They determine whether a user can Create, Read, Update, or Delete (CRUD) individual fields, giving you granular control over data access.

Key Capabilities:

• Prevent record creation for specific roles

• Make fields read-only for certain users

• Hide sensitive fields completely from specific roles

• Control field visibility across different user types

Field Permission Types (CRUD)

Create Permissions

Controls whether users can create new records in a table.

Common Use Case: Only admins can add new records while other roles can view/edit existing ones.

Read Permissions

Controls whether users can see specific fields.

Common Use Case: Hide sensitive information like salaries or internal notes from certain roles.

Update Permissions

Controls whether users can modify field values.

Common Use Case: Make status fields read-only for certain roles while keeping them visible.

Delete Permissions

Controls whether users can delete records (table-level setting).

Step-by-Step Configuration Guide

Setting Up Field-Level Permissions

Step 1: Access Table Permissions

1. Navigate to the Data & API tab

2. Hover over your target table (e.g., "Properties")

3. Click the permissions icon 🛡️

4. Ensure permissions are enabled for the table

Step 2: Configure Create Permissions

To prevent specific roles from creating records:

1. Open the permission settings for your table

2. Find the Create section for the target role (e.g., "Agent")

3. Toggle off the Create permission for that role

4. Click Save to apply changes

Result: Users with that role will no longer see "Add New Record" buttons or be able to create records via forms.

Step 3: Configure Update Permissions

To make specific fields read-only:

1. In the permissions settings, locate the field you want to restrict (e.g., "Status")

2. Find the target role (e.g., "Agent")

3. Disable the Update permission for that specific field

4. Click Save

Result: The field appears to users but cannot be edited - it becomes read-only.

Step 4: Configure Read Permissions

To hide fields completely from certain roles:

1. Locate the sensitive field (e.g., "Price", "Internal Notes")

2. Find the target role (e.g., "Client")

3. Disable the Read permission for that field

4. Click Save

Result: The field is completely hidden from users with that role throughout the entire app.

Practical Examples

Example 1: Real Estate Agent Portal

Scenario: Agents should only update property details but not change listing status.

Setup:

• Create: Disabled for "Agent" role

• Status field Update: Disabled for "Agent" role

• Other fields Update: Enabled for "Agent" role

Result: Agents can edit property details but cannot add new properties or change their status.

Example 2: Client Portal

Scenario: Clients should see project information but not internal pricing or notes.

Setup:

• "Internal Price" Read: Disabled for "Client" role

• "Internal Notes" Read: Disabled for "Client" role

• Other fields Read: Enabled for "Client" role

Result: Clients see project details but sensitive internal information remains hidden.

Example 3: Student Management System

Scenario: Students can view their grades but cannot edit them; teachers can edit grades.

Setup:

• "Grade" Update: Disabled for "Student" role

• "Grade" Update: Enabled for "Teacher" role

• "Grade" Read: Enabled for both roles

Result: Students see their grades but cannot modify them; teachers have full access.

Testing Field-Level Permissions

Using "View as User" Feature

1. Access the testing tool:

   • Look for the 👥 icon in the build toolbar

   • Select a user with the role you're testing

2. Verify Create permissions:

   • Check if "Add New" buttons appear/disappear as expected

   • Try to access create forms

3. Test Update permissions:

   • Open a record and check which fields are editable

   • Look for read-only field indicators

4. Confirm Read permissions:

   • Verify hidden fields don't appear anywhere in the app

   • Check both list views and detail pages

Testing Checklist

• Create test: Can restricted roles create new records?

• Read test: Are sensitive fields hidden from restricted roles?

• Update test: Are read-only fields properly protected?

• Navigation test: Can users access records they shouldn't see?

• API test: Do restrictions apply when accessing data via API?

Advanced Field Permission Scenarios

Conditional Field Access

You can combine field-level permissions with record-level permissions for sophisticated access control:

Example:

• Users can only see records assigned to them (record-level)

• Within those records, they cannot edit the status field (field-level)

Multiple Roles with Different Field Access

When users have multiple roles, field permissions are additive:

• If any role grants field access, the user gets that access

• This allows for flexible permission inheritance

Permission Rule Priority

1. Explicit Denials: Specific "deny" rules override general "allow" rules

2. Role Specificity: More specific roles can override general role permissions

3. Field Inheritance: Field permissions inherit from table-level permissions

Common Field Permission Patterns

Pattern 1: Read-Only Fields for External Users

Internal Role: Full CRUD access
External Role: Read-only access to specific fields

Pattern 2: Status Field Protection

Admin Role: Can update status fields
User Role: Cannot update status fields (read-only)

Pattern 3: Progressive Access Levels

Viewer Role: Read-only access
Editor Role: Read + Update access  
Admin Role: Full CRUD access

Troubleshooting Field Permissions

Field Still Editable Despite Restrictions

Possible Causes:

• User has multiple roles, and one role has update permissions

• Permission rule isn't saved properly

• User role assignment is incorrect

Solutions:

1. Check all roles assigned to the user

2. Review permission rules for each role

3. Test with users who have only one role

4. Verify permission rules are saved and applied

Hidden Fields Still Appearing

Possible Causes:

• Permission caching issues

• User viewing app in builder mode

• Incorrect role assignment

Solutions:

1. Refresh the app or use incognito mode for testing

2. Ensure you're testing in live mode, not build mode

3. Verify the user's role in the user table

4. Check for recent permission rule changes that need time to propagate

Performance Issues with Complex Permissions

Optimization Tips:

• Keep permission conditions simple when possible

• Use indexed fields for permission filtering

• Monitor query performance with complex field permission setups

• Consider role consolidation if you have too many permission rules

Best Practices

Security

• Start restrictive: Begin with minimal access and add permissions as needed

• Layer security: Combine field-level with record-level permissions

• Regular audits: Review permissions as your app and team evolve

• Test thoroughly: Always test permissions from the user's perspective

User Experience

• Clear feedback: Use helper text to explain why fields might be disabled

• Consistent patterns: Apply similar permission patterns across related tables

• Progressive disclosure: Show advanced fields only to users who need them

• Error handling: Provide clear messages when access is denied

Maintenance

• Document rules: Keep track of permission logic for future reference

• Version control: Test permission changes in staging before production

• Monitor usage: Track which permissions are actively used vs. redundant

• User feedback: Gather input on permission usability from actual users

Pro Tip: Field-level permissions work best when combined with record-level permissions and page visibility rules for comprehensive access control.