How do you share an Adalo list read-only with selected users?
Keep one owner on each list, add selected viewers through a second user relationship, and enforce read-only access with Collection Permissions.
Short answer
Create two separate relationships from Lists to Users: one Owner relationship and one many-to-many Shared With relationship. Add viewers with an Update action, filter the list for the owner or a shared viewer, then restrict updates and deletion to the Owner with Collection Permissions.
The intended outcome
Each list has one owner, selected users can view it, unrelated users cannot retrieve it, and only the owner can change or delete it.
Use separate relationships for ownership and sharing. The Owner relationship identifies who controls the List, while Shared With identifies the users who may read it. Add shared users only after the List exists, because current Adalo documentation says many-to-many relationships cannot be set in a Create action. Apply the same access rule in two places. The list filter should return a record when the logged-in user is its Owner or is contained in Shared With. Collection Permissions should allow those relationships to view the record while reserving Update and Delete for Owner. Interface visibility remains useful, but it does not replace the database permission rule. Test the workflow as an owner, a viewer, and an unrelated user. A correct result gives the viewer access without edit rights and prevents the unrelated account from retrieving the record at all.
Requirements
- A Users collection with authentication enabled
- A Lists collection with representative records
- Two test accounts plus one unrelated account
- Permission to change the Lists collection schema and permissions
Step by step
Step 1: Create separate owner and viewer relationships
Add an Owner relationship where one User can own many Lists and each List has one Owner. Add a second Shared With relationship where Lists and Users can relate many-to-many.
Step 2: Save the owner when creating a list
On the Create List action, set Owner to Logged-in User. Leave Shared With empty unless the creator must also be present in that relationship for another part of the app.
Step 3: Add a selected viewer after creation
Place the Share action where both Current List and the selected User are available. Update Current List and set Shared With to Add Current User. Adalo does not set a many-to-many relationship in a Create action, so this must be a later Update action.
Step 4: Show lists to owners or shared viewers
Filter the Lists component with OR logic: Owner is Logged-in User, or Shared With contains Logged-in User. Keep the two branches explicit so owners do not disappear when they are not also in Shared With.
Step 5: Set database-level view access
Open Collection Permissions for Lists, set View to Some Logged In Users, and enable the direct Owner and Shared With relationships to Users. Confirm the permission screen expresses both relationships before treating the records as private.
Step 6: Keep changes owner-only
Set Update and Delete to Some Logged In Users through the Owner relationship only. Also show edit, delete, share, and unshare controls only when Current List Owner is Logged-in User.
Step 7: Support unsharing
Add an owner-only Update Current List action that removes Current User from Shared With. Return the user to a refreshed list and confirm the removed record is no longer returned.
The underlying logic
The Owner relationship represents authority, while Shared With represents view membership. Keeping these meanings separate makes permission rules and interface conditions easier to audit.
The OR list filter controls which records the interface requests. Collection Permissions provide the separate database boundary that prevents an unrelated user from retrieving or changing a record.
A direct many-to-many relationship is suitable for a simple viewer list. A Share or Membership collection is clearer when each share needs a role, invitation state, expiration date, or audit metadata.
Data model
| Collection | Important properties | Relationships |
|---|---|---|
| Users | Email, display name | Owns many Lists and can be related to many Lists through Shared With |
| Lists | Name and list-specific fields | Belongs to one Owner and has many Users in Shared With |
What still needs checking?
- This is a forum-native Answer with no original Adalocado video. Current documentation now explicitly states that many-to-many relationships must be changed after record creation and recommends join collections when relationship load grows.
Common failure modes
Create the List with its Owner first, then use a separate Update Current List action to add each viewer because Adalo does not set many-to-many relationships during Create.
Confirm that the user was added to Current List Shared With, the list filter uses contains Logged-in User, and View permission includes the Shared With relationship.
Condition those controls on Current List Owner being Logged-in User, then verify that Update and Delete permissions also use only the Owner relationship.
Check that Create List saved Logged-in User as Owner and that the visible list uses OR rather than requiring both Owner and Shared With conditions.
Testing checklist
0 of 12 checked on this device
Current limitations
- Collection Permissions currently use direct or two-level relationships to the Users collection, so verify the exact permission paths available in the current builder.
- Many-to-many relationships add load cost and cannot be set during record creation. Use a Share or Membership collection when the number of relationships grows or each share needs its own fields.
- This workflow was corroborated from current official documentation and an accepted forum solution, but it was not reproduced in a live builder project.
What the Adalo community is reporting
These are concise editorial summaries of public forum posts, not endorsements or independently reproduced results.
Share list with other users
The accepted answer separates one owner relationship from a many-to-many sharing relationship, adds viewers with an Update action, and filters records by the logged-in user's membership.
Boundary: The forum reply does not describe Collection Permissions, so the read-only security boundary comes from current official documentation and must be tested with separate accounts.
MartaG (question) and Yongki (accepted answer) · June 2023
Sources and status
This page was last reviewed on Sep 9, 2026. Its current status is Documented from current sources.
Verification owner: Adalocado daily AI publisher. Next review: Nov 9, 2026.
Changelog
Automatically posted from a solved Adalo forum topic; corrections are monitored on the live site.
Automatically organized and maintained by the Adalocado editorial team under the editorial and verification policy.
Report this answer.
Automated Answers still pass evidence and publication checks, but they can be wrong, outdated, unclear, or missing an important boundary. Send the exact correction and the editor will check the live page.
Did this solve your problem?
One-click check
We’ll handle the tech. You can exhale.
Bugs fixed. Updates shipped. Publishing handled.
$97/mo for your first 3 months.
Cancel anytime. That’s about 90% off the usual cost. 🤯
- Bug fixes and troubleshooting
- App updates and integrations
- Publishing and store releases
Bring us the messy version.
Describe what you expected, what happened instead, and what you already tried.
