> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base44.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Managing data permissions
Base44 automatically sets up data permissions as you build your app. You can adjust them at any time using the AI chat, or configure them manually if you need more control. If permissions are not set up correctly, the wrong people could view or change data in your app.
To set who can open your app and whether they need to sign in, see [Managing app access and roles](/Setting-up-your-app/Managing-access#setting-your-app-visibility).
***
## Using the AI chat to set permissions
You don't need to configure permissions manually. Tell the AI chat how your app should work in plain language, and it sets up the right rules for you. This works when you are first building your app and at any point later when your needs change. If it needs to update existing rules, it asks for your approval first.
**Here are some examples of prompts you can use:**
```text theme={null}
Only the person who submitted an order should be able to see it.
```
```text theme={null}
Admins should have full access to all client details. Regular users should only see their own.
```
```text theme={null}
Anyone can browse the product catalog, but only managers can add or update listings.
```
***
## Customizing permissions manually
If you want to review or fine-tune the permissions on a specific data table, you can do that from the table's **Permissions** page in your dashboard. The page opens in a read-only view showing your current rules. Click **Edit** to make changes.
Not sure what rules to set? Describe what you need to the AI chat in plain language and it configures the permissions for you. Manual configuration is there when you need more precise control.
**To customize permissions for a data table:**
1. Click **Dashboard** in your app editor.
2. Under **Data**, click the table you want to manage.
3. Click **Permissions** in the top right of the page. If there are permission issues, you see a warning icon on the button.
4. Click **Edit** to open the **Configure permissions** panel.
5. Check the boxes for the actions you want each rule to cover: **Create** (add records), **Read** (view records), **Update** (edit records), and **Delete** (remove records).
6. If you check a box for **Entity-User Field Comparison**, enter the field from this table to compare in **Entity field**, then choose the matching user property from the **User field** dropdown.
7. If you check a box for **User Property Check**, choose the user property from the **User property** dropdown and set the required value.
8. Click **Save**.
If a person matches any one rule, they get access. To add an additional Entity-User Field Comparison or User Property Check row, click **Add rule** at the bottom of the panel. You cannot remove a rule that is the only one covering an action. Add another rule for that action first, then deselect the one you want to remove.
The **Generated JSON (Preview)** section at the bottom of the page shows how your rules translate into the technical format Base44 uses behind the scenes. You do not need to understand it to use the permissions editor, but it can be useful if a developer asks you to share your permission configuration or if you want to verify exactly what rules are in place.
### Permission rule types
You do not usually need to add rules manually. The AI sets them up when it creates your data tables, and the **Permission recommendations** panel suggests fixes when something looks off. This section is here if you want to understand what each rule does before applying a recommendation, or if you need to fine-tune something specific.
| Rule | What it does | Good for |
| -------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| **All Users** | Anyone can perform this action, even without signing in | Public data like a product catalog or blog |
| **Creator Only** | A person can only access records they created | Personal data like orders, messages, or form submissions |
| **Entity-User Field Comparison** | A person can only access a record if a field on that record matches their account details | Assigning records to specific people, like tasks or tickets |
| **User Property Check** | Only people with a specific account property can perform this action | Role-based access, like admins only |
If you enable **All Users** for an action that already has specific rules, a confirmation dialog appears before those rules are cleared. If you enable a specific rule while **All Users** is active for that action, **All Users** is removed automatically.
### How Entity-User Field Comparison works
This rule checks whether a field on the record matches a property of the signed-in person's account. If they match, access is granted.
You set two things:
* **Entity field**: The name of a field that already exists on this data table. To find your field names, go to **Dashboard**, click the table under **Data**, and look at the columns listed there. Type the field name exactly as it appears. For example, `assigned_to` or `owner_email`.
* **User field**: The property from the signed-in person's account to compare it with, selected from a dropdown. For example, their email address.
**Example:** You have a Tasks table with an `assigned_to` field that stores the email of whoever the task belongs to. Set **Entity field** to `assigned_to` and **User field** to `email`. Now each person only sees the tasks assigned to them.
You can add multiple Entity-User Field Comparison rows if you need to match on more than one field pair.
### How User Property Check works
This rule checks a property on the signed-in person's account and grants access only if it matches a value you set.
You set two things:
* **User property**: The account field to check, such as **User Role**, **User Email**, or **Full Name**.
* **Required value**: The value it must match. For **User Role**, you can choose **Admin** or **User** from a dropdown. For other fields, you type the value directly.
**Example:** You want only admins to be able to delete records. Set **User property** to **User Role** and **Required value** to **Admin**.
You can add multiple User Property Check rows for different properties or values.
***
## Applying permission recommendations
If the AI detects a potential risk in your current setup, a **Permission risks detected** banner appears directly on the data table page. It shows a summary of the risk and the recommended fix. You can act on it in two ways:
* Click **Fix** to go straight to the recommendations and apply them in one step.
* Click **More details** to open the full **Permission recommendations** panel, where you can review the changes before applying them.
The **Permission recommendations** panel shows two sections. The **Risk** section shows your current rules and explains why they may expose data to unintended people. The **Recommended rules** section shows the suggested replacement along with a plain-language description of what they enforce.
Click **Apply recommendations** to replace your current rules with the recommended ones, or click **Cancel** to close the panel and keep your existing rules. You can also edit the rules manually after applying the recommendations.
***
## Permission examples by app type
Not sure how to set up permissions for your app? Use these common scenarios as a starting point. You can also ask the AI chat to review your setup and suggest the right rules.
A small group of trusted people all use the same app, such as a family shopping list or a shared home management tool.
* **App visibility:** Private. Invite the people who need access.
* **Require login:** Yes.
* **Permissions:** For data everyone shares equally, no restrictions are needed. For data that belongs to each person individually, such as personal notes or reminders, use **Creator Only** on Read, Update, and Delete so each person can only access records they created.
Anyone can visit the site, but the submissions they send should only be visible to you or your team.
* **App visibility:** Public.
* **Require login:** No.
* **Permissions:** For the form submissions table, use **All Users** on Create so anyone can submit. Use **User Property Check** on Read, Update, and Delete, restricted to your admin role, so only your team can view and manage the incoming messages.
A team or company uses the app internally, and some data should only be visible to managers or specific roles.
* **App visibility:** Workspace.
* **Require login:** Yes.
* **Permissions:** Use **User Property Check** to restrict sensitive tables, such as salary data or performance reviews, to a manager role. For general content like announcements or shared resources, use **All Users** on Read so the whole team can view it.
Each person logs in and manages their own data. They should only ever see their own records, never anyone else's.
* **App visibility:** Public or Workspace, depending on whether you want open sign-up or invite-only access.
* **Require login:** Yes.
* **Permissions:** Use **Creator Only** on Read, Update, and Delete for every personal data table. This ensures each person can only access records they created.
Anyone can browse the content, but only editors or admins can add or change anything.
* **App visibility:** Public.
* **Require login:** No, unless you want to gate certain content.
* **Permissions:** Use **All Users** on Read so anyone can view content. Use **User Property Check** on Create, Update, and Delete, restricted to your editor or admin role, so only your team can manage content.
Different companies, schools, or departments each use the app, but their data should stay completely separate from each other.
* **App visibility:** Public or Workspace, depending on your setup.
* **Require login:** Yes.
* **Permissions:** Use **Entity-User Field Comparison** to match a field on each record to a property on the signed-in person's account. For example, if each record has a `company_id` field and each user account has a matching `company_id` property, set Entity field to `company_id` and User field to `company_id`. Each person only sees records that belong to their company. For admin access within a group, combine this with a **User Property Check** on the admin role.
***
## FAQs
No. Base44 sets up permissions automatically when it creates data tables. You can ask the AI chat to update them at any time in plain language, or adjust them manually from each table's **Permissions** page. Before you publish, it is worth running a security scan to confirm everything looks right.
Open the affected table in your dashboard and check its **Permissions** page. If there is a **Permission risks detected** banner, click **Fix** to apply the recommended rules, or **More details** to review them first. You can also run a security scan from the **Security** tab for a full overview of issues across your app, or describe the problem to the AI chat and ask it to fix it for you. Once you have made changes, test your app in **Preview** mode by signing in as different roles to confirm access is working as expected.
Yes, changes take effect immediately. Before making changes, use **Preview** mode to test how your app behaves with the new rules. Sign in as different roles to confirm access is working the way you expect.
Yes. Add a custom field (such as `department` or `access_level`) to your User table and define values like manager or viewer. Then use **User Property Check** rules on that field to give each role the right level of access. You can ask the AI chat to set this up for you.
No. Permissions apply to entire data tables, not individual fields. If you need to limit what data is returned from a table, you can do that through backend functions, which let you filter or transform data before it reaches the app. You can ask the AI chat to help you set this up.
If your permissions were set up with rules that are too complex for the visual editor to represent, such as conditions using advanced operators, the editor falls back to a JSON-only view. You can still edit the JSON directly, or start fresh by checking a box in the matrix, which asks you to confirm before replacing the existing configuration.