# Field-level permissions

{% embed url="<https://www.youtube.com/watch?v=6RNXrnIPPk4>" %}

## What are Field-Level Permissions?

Field-level permissions go beyond [record-level permissions](https://guides.noloco.io/users-and-permissions/user-roles-and-permissions/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](https://guides.noloco.io/users-and-permissions/user-roles-and-permissions/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

{% hint style="info" %}
**Pro Tip**: Field-level permissions work best when combined with [record-level permissions](https://guides.noloco.io/users-and-permissions/user-roles-and-permissions/record-level-permissions) and [page visibility rules](https://guides.noloco.io/pages/page-visibility-rules) for comprehensive access control.
{% endhint %}