How to set up login and user permissions in Adalo
Adalo handles authentication through the Users collection: add signup and login screens, mark the screens that require a logged-in user, and filter every list by Logged-in User so people only see their own records. Roles are just a property on the User record that you check with visibility rules and screen redirects.
Authentication in Adalo is quick to switch on and easy to leave leaky. The part that needs attention is not login, it is making sure the data behind each screen is filtered to the right person.
Set up signup and login
Adalo's Users collection is a normal collection with email and password built in.
- Add a signup Form and a login Form from the component library.
- Set where each Form sends the user afterwards.
- Turn on password reset in app settings so you are not resetting accounts by hand.
Protect the screens
Mark every internal Screen as requiring login, not just the first one.
- A logged-out visitor gets redirected instead of an empty dashboard.
- Set the app entry Screen so logged-in users skip marketing screens.
Filter data by the logged-in user
Every list of personal data, orders, messages, documents, needs a filter tied to Logged-in User.
- Without it, users see each other's records once real data arrives.
- Hiding a component is not the same as filtering the data behind it.
- Filter the List first, then hide whatever else needs hiding.
Add roles without a second collection
Add a role property, Text or True/False, to the User record and drive visibility from it.
- is_admin, or role = "owner" | "staff", on the User record.
- Use it in visibility rules and conditional navigation.
- Never let users edit their own role property through a Form.
- Check the role on the screen and on the data, not only a button.
- Keep the number of roles small, two or three covers most apps.
Common mistakes and how to diagnose them
A logged-out user can open an internal screen by deep link.
- Likely cause:
- The screen is not marked as requiring a logged-in user.
- Fix:
- Set the login requirement on every internal screen, not only the first one.
Users can see each other's records.
- Likely cause:
- A list with no Logged-in User filter, or filtering only in the UI with visibility rules.
- Fix:
- Add the relationship filter to the list itself so the records are never fetched.
Signup succeeds but the app looks empty.
- Likely cause:
- New accounts have no related records and no empty state was designed.
- Fix:
- Create starter records on signup, or design a proper first-run empty state.
Password reset emails never arrive.
- Likely cause:
- Reset not enabled, or the email landed in spam.
- Fix:
- Enable it in settings, test with a real inbox, and tell users which address it comes from.
Real example: a two-sided booking app
Clients and providers used the same app. A single role property on the User record decided which home screen they landed on after login, and every booking list was filtered by the relationship to Logged-in User on both sides.
The one thing that had to be locked down: the profile form originally included the role property, which meant any client could promote themselves to provider. Removing it from the form was a one-minute fix to a serious hole, worth checking on your own app right now.
When you need an Adalo expert
Plenty of Adalo issues are straightforward to fix yourself with the steps above. It usually pays to bring in an experienced Adalo developer when the problem sits deeper in the build:
- Your app has teams, organisations or client accounts where several users share data but must not see other groups.
- You need single sign-on, social login or an external identity provider.
- Sensitive data is involved and the app must hold up to a security review.
- You are migrating existing users into Adalo without forcing everyone to reset their password.
Related guides
How to structure collections for an Adalo app
Field types, relationships and naming rules that keep an Adalo app fast to filter, easy to change, and painless to connect to an API later.
How to debug an Adalo app
A repeatable way to find why an Adalo list is empty, an action does nothing, or a form saves the wrong record, checked in the same order every time.
Adalo app launch checklist
What to verify before you submit an Adalo app: data, accounts, permissions, empty states, uploads and external collections.
How to set up a custom action in Adalo
Create an Adalo custom action step by step: method, URL, headers, body with magic text, and how to use the response on the next screen.
Frequently asked questions
Does Adalo have built-in authentication?
Yes, the Users collection plus signup, login and password reset components handle it without any external service.
How do I make sure users only see their own data?
Filter every list by a relationship to Logged-in User. Visibility rules alone still fetch the data.
Can I have admin and normal users?
Yes. Add a role property to the User record and drive visibility and navigation from it.
Can users log in with Google?
Not natively for every plan and build type; social login usually needs an external identity setup.
How do I delete a user account?
Delete or archive the User record, and decide up front what happens to the records related to it.
Is Adalo authentication secure enough for real apps?
The login mechanism is fine. Most real-world leaks come from unfiltered lists and editable role propertys, not from Adalo itself.
Webnux Tools is an independent product by Webnux Ltd. It is not affiliated with, endorsed by, or sponsored by Adalo, Inc. Adalo is a trademark of Adalo, Inc.