# Managing data permissions

> Control who can create, read, update and delete records in each table.


Each table has four permissions: **create**, **read**, **update** and **delete**. Describe what you want in the chat and Draftship writes the rules:

| You say | Rule |
|---|---|
| "Anyone can submit, only I can read submissions" | create: everyone · read/update/delete: admins |
| "Users only see their own items" | everything limited to the creator |
| "Public posts, but only the author can edit" | read: everyone · update/delete: creator |

## Defaults

Tables without their own rules allow anyone to create and read records, and only the creator to update or delete them. Anonymous records (no signed-in user) can only be changed by admins.

## What the rules look like

Rules live in each table's schema file. See [Security rules](/docs/developers/backend/security) for the full format.

```json
"rls": {
  "create": true,
  "read": { "user_condition": { "role": "admin" } },
  "update": { "user_condition": { "role": "admin" } },
  "delete": { "user_condition": { "role": "admin" } }
}
```

## Hiding single fields

Sometimes records should be public but one field should not, like the email on a guestbook note. Field-level rules ("fls") hide a field from everyone who doesn't pass its rule, and can also block who may set it:

```json
"fls": {
  "author_email": {
    "read": { "$or": [{ "created_by": "{{user.email}}" }, { "user_condition": { "role": "admin" } }] }
  },
  "status": {
    "write": { "user_condition": { "role": "admin" } }
  }
}
```

Hidden fields are removed before filters run, so they can't be guessed with queries. `created_by` can be hidden the same way. The [security scan](/docs/security/running-a-security-scan) adds these rules for you with **Apply fix**.

## Check the result

Use the **Data** tab to see what's stored, and test your app signed out and as a second user to confirm that each person sees only what they should.