Solved on the forum

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.

Docs checkedIntermediateReviewed Sep 9, 2026
THE 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.

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.

Completeness87%
Index decisionIndex now
Evidence basisAccepted forum solution plus current Relationships, Filtering, and Collection Permissions documentation; no hands-on builder reproduction
WHAT YOU’LL HAVE 🎯

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.

BEFORE YOU START 🧰

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
BUILD IT 🛠️

Step by step

  1. 01

    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.

  2. 02

    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.

  3. 03

    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.

  4. 04

    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.

  5. 05

    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.

  6. 06

    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.

  7. 07

    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.

WHY IT WORKS 🧠

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.

COLLECTIONS AND RELATIONSHIPS 🗃️

Data model

CollectionImportant propertiesRelationships
UsersEmail, display nameOwns many Lists and can be related to many Lists through Shared With
ListsName and list-specific fieldsBelongs to one Owner and has many Users in Shared With
EVIDENCE CONTEXT 🔎

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.
IF IT DOESN’T WORK 🧯

Common failure modes

Shared With is missing from the Create action

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.

A shared user still cannot see the list

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.

A viewer can see edit controls

Condition those controls on Current List Owner being Logged-in User, then verify that Update and Delete permissions also use only the Owner relationship.

The owner cannot see a newly created list

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.

BEFORE YOU MOVE ON ✅

Testing checklist

0 of 12 checked on this device

BOUNDARIES 🚧

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.
BUILDER REPORTS 🗣️

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
VERSION NOTES 📝

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.

VERSION HISTORY 🕰️

Changelog

  1. Automatically posted from a solved Adalo forum topic; corrections are monitored on the live site.

SPOT SOMETHING FUNNY? 🕵️

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.

Report a problem
MONTHLY APP MANAGEMENT · BY REHOST

Rehost becomes the monthly team behind your app. Fixes, releases, integrations, and ongoing changes have an owner.

See monthly management
FixesHandled
ReleasesHandled
Next changesHandled
YOUR PROBLEM IS DIFFERENT? 🤔

Bring us the messy version.

Describe what you expected, what happened instead, and what you already tried.

Ask Adalocado 💬