Adalo Join Collections

Alternative to Relationship Property. Otherwise known as a join table, a junction table, or linking table.

What is a Join Table?

A join table (also called a junction table or linking table) is a database design pattern used to manage many-to-many relationships efficiently. Instead of storing multiple relationships directly on one table, you create a separate table that only stores the IDs connecting two records.

---

Traditional Coding Approach (SQL)

In a SQL database, for our example of Tasks and Users, if you have Tasks and Users with a many-to-many relationship, you'd structure it like this:

Tasks Table:
- id
- name
- description
- due_date
Users Table:
- id
- name
- email
Task_Assignees Table (Join Table):
- task_id
- user_id

When you need to find all users assigned to a task, you'd query:

SELECT users.* FROM users
JOIN task_assignees ON users.id = task_assignees.user_id
WHERE task_assignees.task_id = 123

---

Adalo Join Collection (No-Coding required)

In Adalo, you create collections in a similar way, but instead of SQL queries, you use Lists, filtering, and MagicText. This requires that data is available on the screen via Link Action from screen with Parent Data.

1. Create a join collection (e.g., "Task Assignees")

   • Name (Default Text Property)

   • Task ID (Number Property storing the ID)

   • User ID (Number Property storing the ID)

     • 

2. Filter it in your List instead of using relationship properties

   • Add a List Component that shows "Task Assignees"

     • 

   • Filter by Task_ID = current task>ID (on screen via Available Screen Data)

     • 

   • Or filter by User_ID = Logged in User>ID to find all records for a Logged in User.

     • 

---

Why This Matters in Adalo

Instead of your Tasks collection having direct relationship properties (which load all connected and additional related data at once), you're storing just text IDs. This means:

• Faster initial load: No heavy relationship data pulling through

• More flexible queries: Show by task, by user, or by any filter without loading everything

• Better performance at scale: Your app stays responsive even with thousands of records

The trade-off: You're doing a bit more planning and setup to ensure data flows through your app as intended, but you gain significant performance improvements.

---

Best Practices

• Start simple: Use direct relationships for small datasets and simple one-to-many connections

• Monitor performance: As your app grows, watch for slowdowns and switch to join collections

• Use consistent naming: Name join collections clearly (e.g., TaskAssignees, UserWorkouts)

• Store IDs as text: In join collections, always store IDs as number properties for flexibility

• Add additional data: Include optional properties like "Role" or "Type" to categorize relationships. Can be used for filtering if needed.

• Test thoroughly: Join collections require more filtering and require that data is loinked to screens correctly, so test all scenarios