> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superdev.build/llms.txt
> Use this file to discover all available pages before exploring further.

# Row Level Security

> Learn how to use the Row Level Security in Buildy

RLS is a feature that allows you to control user access to every entity in your database.

### How to use RLS?

You can set RLS for each entity by going to the "Entity" section, and clicking on the "Security" button.

#### Adding Security Rules

When you want to control access to an entity, you can add a security rule using the "Security" button in the Entity section. This opens the **Add Security Rule** dialog:

<div className="flex justify-center">
  <img src="https://mintcdn.com/superdev-579090d2/p3UmgHwb7a8TslT7/add-security-rule.png?fit=max&auto=format&n=p3UmgHwb7a8TslT7&q=85&s=e040dc27843a4aa33c7aa12c6b4904c9" alt="Add Security Rule" className="rounded-lg" width="300" data-path="add-security-rule.png" />
</div>

Here's what each option means:

* **Rule Name**:\
  Enter a descriptive name for your rule (e.g., "Admins Only Read", "User Can Edit Own Posts").
* **Access Type**:
  * **Read Access**: Controls who can view records.
  * **Write/Delete Access**: Controls who can create, update, or delete records.
* **Rule Type**:
  * **No Restrictions**:\
    All users can access records (default, open access).
  * **Creator Only**:\
    Users can only access records they created.
  * **Entity-User Field Comparison**:\
    Compares a field in the entity with a user property (e.g., only users whose `department` matches the record's `department` can access).
  * **User Property Check**:\
    Checks if a user property matches a specific value (e.g., only users with the role "admin" can access).
* **Description (optional)**:\
  Add any notes or context for this rule.

Once you've configured your rule, click **Add Rule** to apply it.

## Examples

### Example 1: Blog Posts (Admin Create + Creator Edit)

**Scenario**: Users can view all blog posts, only administrators can create new posts, and users can edit/delete their own posts.

**Setup**:

1. **Read Access Rule**:
   * Rule Name: "Public Read Access"
   * Access Type: Read Access
   * Rule Type: No Restrictions
2. **Create Access Rule**:
   * Rule Name: "Admin Can Create"
   * Access Type: Write/Delete Access
   * Rule Type: User Property Check
   * User Property: `role`
   * Expected Value: `admin`
3. **Edit Access Rule**:
   * Rule Name: "Creator Can Edit"
   * Access Type: Write/Delete Access
   * Rule Type: Creator Only

**Result**: All users can see all blog posts, only administrators can create new posts, and users can edit/delete posts they created.

### Example 2: Company Documents (Department-Based)

**Scenario**: Employees can only access documents from their own department.

**Setup**:

* Rule Name: "Department Access Only"
* Access Type: Read Access
* Rule Type: Entity-User Field Comparison
* Entity Field: `department` (field in the documents table)
* User Property: `department` (user's department from their profile)

**Result**: A user with `department: "Engineering"` can only see documents where the document's `department` field equals "Engineering".

### Example 3: Admin Panel (Role-Based)

**Scenario**: Only administrators can access sensitive user management data.

**Setup**:

* Rule Name: "Admin Only Access"
* Access Type: Read Access
* Rule Type: User Property Check
* User Property: `role`
* Expected Value: `admin`

**Result**: Only users with `role: "admin"` can view the user management entity.

### Example 4: Project Management (Combined Rules)

**Scenario**: Project team members can view projects, but only project managers can edit them.

**Setup**:

1. **Read Access Rule**:
   * Rule Name: "Team Member Read"
   * Access Type: Read Access
   * Rule Type: Entity-User Field Comparison
   * Entity Field: `team_id`
   * User Property: `team_id`
2. **Write Access Rule**:
   * Rule Name: "Manager Edit Only"
   * Access Type: Write/Delete Access
   * Rule Type: User Property Check
   * User Property: `role`
   * Expected Value: `project_manager`

**Result**: Team members can see projects from their team, but only users with the "project\_manager" role can edit or delete them.

> **Tip:** You can combine multiple rules for fine-grained access control. For example, allow all users to read, but only creators or admins to edit or delete.