- Row Level Security (RLS): Controls which records users can access.
- Field Level Security (FLS): Controls which fields within records users can access.
Permission types
Each security level has different permissions you can set. For each permission, you define who is allowed to perform the action.Row Level Security (RLS)
create- Add new recordsread- View recordsupdate- Modify recordsdelete- Remove records
Field Level Security (FLS)
read- View the fieldwrite- Create or modify the field
Permission values
Each permission accepts one of the following values:true- Allow all usersfalse- Block all users{<condition>}- Allow users matching the condition
Condition syntax
When using{<condition>} as a permission value, you can define rules that check user attributes or roles.
1. Entity-to-user comparison
Compare record fields to the current user’s values.
Entity fields you can reference:
created_by- Email of user who created the recordcreated_by_id- ID of user who created the recordentity_name- Name of the entity typeapp_id- App IDenvironment- Eitherprodordevis_sample- Whether it’s sample datais_deleted- Soft delete flagdeleted_date- When it was deleteddata.*- Any field from your entity schema’s properties
{{user.email}}- User’s email{{user.id}}- User’s ID{{user.role}}- User’s role{{user.data.*}}- Additional user fields you define
user_condition.
User fields you can check:
email- User’s emailid- User’s IDrole- User’s roledata.*- Custom user fields
$or, $and, $nor, $in, $nin, $all
Example:
Row Level Security (RLS) example
Addrls at the entity level:
Field Level Security (FLS) example
Addrls to individual field properties:
Complete example with security
Here’s an entity schema with both RLS and FLS:Deploying security rules
Security rules are part of your entity schema. After adding or updating security rules, deploy usingentities push. Security rules are also deployed automatically when you run the deploy command to deploy your entire project.

