Lists in Adalo, from data to layout
Connect an Adalo list to the right collection, prove its records, add filters safely, debug empty results, and choose a native or custom list deliberately.
We checked current official documentation, captured the relevant screens, and compared the workflow with dated Adalo forum reports. Source links and limitations are below so you can judge the evidence directly.
Choose the collection under “What is this a list of?”, prove the unfiltered records, bind each field to Current [record], and only then add one filter at a time. Use a native list unless the layout truly requires a custom one.
Treat a list as a query before treating it as a design element. Connect it to the correct collection, prove the expected records appear, bind repeated fields to the current record, and only then add sorting and one filter at a time. Use AND when every rule must pass and OR when any rule may pass. Prefer a native list when it can support the layout, and enforce private data with Collection Permissions rather than trusting a visual filter. This sequence separates data, access, query, and layout failures.
The intended outcome
A list that shows the intended collection, presents useful fields, opens the right detail record, and handles an empty result.
Requirements
- A collection with sample records
- A screen that can access the data
- Understanding of Magic Text
Step by step
- 01
Add the lightest suitable list
Start with a native list that can express the row. Adalo’s current performance guidance reserves custom lists for layouts the native choices cannot support.
- 02
Choose its collection
Set “What is this a list of?” to the collection whose records should repeat.
- 03
Bind the visible fields
Select each text or image inside the list and use Current [record] Magic Text to display the correct property.
- 04
Add one filter at a time
Prove each custom filter alone, then combine them deliberately: AND requires every rule, while OR allows any rule to qualify.
- 05
Sort and link
Choose a stable sort, then link the repeated item or button to a detail screen while passing Current [record].
- 06
Design the empty state
Explain why no records are visible and provide the most useful next action.
The underlying logic
A list repeats one design for every record returned by its query.
Filters decide which records enter the list; visibility decides whether one component appears.
Collection permissions decide whether the data may be returned at all; a visual filter is not an authorization boundary.
Custom and nested lists increase layout freedom but add query and rendering work.
Data model
| Collection | Important properties | Relationships |
|---|---|---|
| Items | Name, Description, Status, Created Date | Belongs to one owner and optionally one category |
| Categories | Name, Sort Order | Has many items |
What changed?
- Current documentation supports multiple list filters with explicit AND or OR behavior.
- The refreshed guide now distinguishes empty data, empty filtered results, and empty relationships, with a repeatable query-debugging ladder.
Start with the query
Treat the list as a query before treating it as a visual component. Prove the right records are returned, then style the repeated row.
Use a fixed diagnostic ladder when a list is wrong: confirm sample records exist, remove every filter, verify the collection, bind one plain-text property from the current record, restore one filter at a time, and only then restore the final row design. Each step changes one variable, so the first failure identifies the layer to investigate.
Filters, conditions, and permissions
Filters refine groups of records. Conditions control whether an action runs or a component appears. Collection Permissions control who can read or change the underlying records. Mixing those responsibilities makes debugging unnecessarily hard—and relying on a visual filter for privacy leaves the data rule in the wrong layer.
Relationship filters require both sides of the comparison to contain the expected records. Current Adalo documentation says logical relationship comparisons are limited to one-to-many shapes; many-to-many needs a different query shape or a join collection. When a relationship may be empty, test that state explicitly rather than assuming it behaves like text or false.
A useful empty state
An empty list is not always an error. Distinguish no data yet, no match for the current filters, and data the current user is not allowed to see. Give each state one accurate explanation and a recovery action such as clearing filters, creating the first record, or returning to a broader view.
Performance discipline
Adalo’s current performance guidance recommends native lists over custom lists when practical and warns that lists inside lists can become expensive. Each extra filter, nested relationship, and repeated component adds work, so keep rows lean and move secondary information to a detail screen.
Use a stable sort property so records do not jump unexpectedly between visits. Test long names, missing images, a realistic larger dataset, and an intentionally empty collection; those cases expose layout, query, and accessibility failures that ideal sample data hides.
Common failure modes
The list is empty
Temporarily remove custom filters. If records appear, restore filters one at a time and verify their data types and values.
Every item shows the same content
Use Current [record] inside the list rather than screen-level or logged-in user data.
Search misses obvious results
Text equality is case-sensitive; the Contains operator is less strict and better suited to ordinary text search.
A user sees records they should not access
Fix Collection Permissions and the relationship to Users first. A list filter changes presentation; it does not replace database access rules.
Testing checklist
0 of 9 checked on this device
Current limitations
- Deep relationship filters, custom rows, and nested lists can create performance costs.
- Component filters shape the visible result; they do not replace Collection Permissions.
Screenshot evidence
These captures document what Adalo currently publishes and what builders are reporting. They support the written guidance, but they are not a substitute for an end-to-end test in your own app.
What the Adalo community is reporting
These are concise editorial summaries of public forum posts—not endorsements or independently reproduced results.
Improved Filtering Logic
The changelog says list, count, and dropdown filters were made more consistent and added checks for empty relationships, files, images, and locations.
Boundary: The post says affected apps require a rebuild; existing published builds may not inherit the behavior automatically.
Adalo system · March 2024Sources and status
This page was last reviewed on Aug 16, 2026. Its current status is Verified from current public evidence.
Verification owner: Adalocado editorial. Next review: Nov 12, 2026.
Changelog
Added native-list performance guidance, explicit AND and OR behavior, and the Collection Permissions security boundary.
Added a six-stage query debugging ladder, empty-state taxonomy, relationship-filter boundary, and resilient row testing guidance.
Added current official screenshots and Adalo’s filtering changelog as public evidence.
Did this solve your problem?
Never deal with an Adalo problem again.
Rehost becomes the monthly team behind your app. Fixes, releases, integrations, and ongoing changes have an owner.
See monthly managementBring us the messy version.
Describe what you expected, what happened instead, and what you already tried.
Ask Adalocado 💬
