Skip to main content

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.

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.

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:
Only the person who submitted an order should be able to see it.
Admins should have full access to all client details. Regular users should only see their own.
Anyone can browse the product catalog, but only managers can add or update listings.

Customizing permissions manually

We are in the process of releasing a new permissions page. Yours may look different to the version described below.
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.
Managing permissions for your data
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.
RuleWhat it doesGood for
All UsersAnyone can perform this action, even without signing inPublic data like a product catalog or blog
Creator OnlyA person can only access records they createdPersonal data like orders, messages, or form submissions
Entity-User Field ComparisonA person can only access a record if a field on that record matches their account detailsAssigning records to specific people, like tasks or tickets
User Property CheckOnly people with a specific account property can perform this actionRole-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.
Permission risks detected on a data table
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 recommendations panel

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.