# 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.

- Canonical URL: https://adalocado.com/guides/adding-styling-lists
- Verification: Verified from current public evidence
- Topic: Lists, Filters, and Search
- Skill level: Beginner
- Last reviewed: 2026-08-16
- Index status: index-now

## Short answer

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.

## 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

1. **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.

2. **Choose its collection**

   Set “What is this a list of?” to the collection whose records should repeat.

3. **Bind the visible fields**

   Select each text or image inside the list and use Current [record] Magic Text to display the correct property.

4. **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.

5. **Sort and link**

   Choose a stable sort, then link the repeated item or button to a detail screen while passing Current [record].

6. **Design the empty state**

   Explain why no records are visible and provide the most useful next action.

## Why it works

- 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 | Properties | Relationships |
| --- | --- | --- |
| Items | Name, Description, Status, Created Date | Belongs to one owner and optionally one category |
| Categories | Name, Sort Order | Has many items |

## Common failures

### 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

- [ ] The unfiltered list returns every expected sample record before filters are added.
- [ ] A selected row opens the matching detail record and preserves its identity.
- [ ] An empty result displays an explanation and a useful recovery action.
- [ ] Two users with different permissions can access only the records intended for each user.
- [ ] Unfiltered records appear first
- [ ] Every repeated field uses the current record
- [ ] The item passes the correct record to details
- [ ] Empty and loading states are understandable
- [ ] Filters remain performant

## 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.

## Community evidence

### [Improved Filtering Logic](https://forum.adalo.com/t/improved-filtering-logic/66848)

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.

## Sources

- [Adalo lists and forms](https://help.adalo.com/component-basics/connecting-lists-and-forms-to-a-database)
- [Adalo filtering](https://help.adalo.com/component-basics/conditions-and-filtering/filtering-in-adalo)
- [Adalo app performance](https://help.adalo.com/performance/optimize-app-performance)
- [Adalo collection permissions](https://help.adalo.com/database/collection-permissions)
- [Adalo forum changelog: improved filtering](https://forum.adalo.com/t/improved-filtering-logic/66848)

Markdown version: https://adalocado.com/guides/adding-styling-lists.md