# Debug an Adalo workflow with Codex using records and evidence

Give Codex a reproducible Adalo failure and a small evidence pack, then trace the record, filter, screen context, and action that cause the problem.

- Canonical URL: https://adalocado.com/guides/codex-adalo-debugging
- Verification: Documented from current sources
- Topic: Actions and Logic
- Skill level: Intermediate
- Last reviewed: 2026-10-26
- Builder and evidence scope: Visual builder conditions, relationships, and permissions documentation reviewed October 26, 2026; troubleshooting example not reproduced in a private app
- Verification owner: Adalocado editorial
- Next review: 2027-01-26
- Index status: index-now

## Short answer

Give Codex the expected result, exact reproduction steps, actual record values, and relevant builder settings. Ask for ranked hypotheses and one controlled check at a time. Confirm the failed layer before changing filters, relationships, permissions, or action order.

## Intended outcome

A repeatable way to diagnose a request that saves successfully but disappears from the user's list, with a small correction and meaningful regression checks.

Use Codex as an investigator with a concrete case. A small evidence pack and one controlled check usually move the work forward faster than asking for every possible reason an Adalo screen might be empty.

## Requirements

- A test app or staging copy with fictional records
- Two test users and a written expected result
- Screenshots or written settings for the relevant collection, list, navigation, and create action
- A Codex workspace for the reproduction notes and any integration code or redacted logs

## Step by step

1. **Write the failure as a short journey**

   For example: member A submits a support request, the app shows success, and My Requests stays empty. Record the environment, the exact taps, expected result, actual result, and whether a reload changes it. Avoid a broad description such as the database is broken.

2. **Capture the smallest useful evidence pack**

   Include the saved request ID, its owner relationship, its status, the signed-in test user ID, the list's source and filters, the create action, and the navigation target. Use fictional data and redact credentials. Keep both the visible label and the underlying record identity when comparing users.

3. **Ask Codex to rank possible causes**

   Have it distinguish a record not being created, a missing owner relationship, a mismatched filter, unavailable screen data, and denied data access. Require an observable check for each hypothesis and ask it to name the evidence it still lacks.

4. **Isolate the first failed boundary**

   Inspect whether the request exists in the database. If it does, compare its owner with the signed-in user, then inspect the list query and status value. In a fictional test dataset, remove one display filter at a time. Preserve access controls while diagnosing the query.

5. **Make the smallest supported correction**

   If the owner is missing, fix the create action to attach the correct user and create a new test record. Existing ownerless records need a separate deliberate cleanup. If the query is wrong, correct that query without redesigning the schema. Record the confirmed cause and the exact change.

6. **Repeat with a second user and a fresh session**

   Create requests under both accounts, change one status, reload, reopen details, and sign in again. Verify visibility and access separately. Ask Codex to update the regression checklist using the confirmed cause rather than keeping every initial hypothesis as an unresolved warning.

## Why it works

- A saved record, a list query, a selected screen record, and an action target are different boundaries. A failure after a successful save does not establish that creation failed.
- Testing one variable at a time lets evidence eliminate hypotheses. Changing permissions, filters, and navigation together makes a passing screen difficult to explain or trust.

## A reusable prompt for Codex

Help diagnose this Adalo failure using the attached evidence. Expected: member A submits a support request and sees that same request in My Requests. Actual: success is shown but the list is empty. I have included the create action, saved record fields, current user ID, list query, status filter, and navigation settings. Rank plausible causes, identify the evidence for each, and propose one controlled check at a time. Distinguish missing data, a mismatched relationship, filtering, record context, and permissions. Do not recommend relaxing access controls. If local integration code is involved, trace and test that code. End with the smallest confirmed correction and a two-user regression checklist.

After a check, return a precise result: request 214 exists, Owner is empty, and the list requires Owner to be the signed-in user. That result supports a create-action problem. A screenshot of an empty list alone cannot tell Codex which of those values is wrong.

## An example diagnosis from first symptom to cause

Suppose the database contains request 214 with the correct subject and an empty owner relationship. The list reads Support Requests where Owner is the signed-in user and Status is Open. The create action saves Subject and Status but never sets Owner. The list is behaving consistently with its query; the new record does not satisfy it.

The correction is to populate Owner during creation and verify a new record under member A. Keep the owner filter. For the existing ownerless request, establish its real owner before updating it. Assigning every historical record to whichever user is currently signed in would replace an empty list with an ownership error.

## Filters and permissions answer different questions

A filter answers which records this list should show. A permission rule answers which underlying data a caller may receive or change. Adalo documents those as different mechanisms. Use the right one for the failure you have actually confirmed.

In a test app containing fictional records, simplifying a query can isolate a display problem. It does not prove privacy. Test an unrelated account's direct record access as a separate check. In Ada-generated apps, examine the endpoint's audience and record scope rather than assuming a visual-list setting is the access rule.

## Use local checks where they can prove something

If the failure is in a server adapter or custom component, Codex can inspect that repository, run the relevant local checks, and return a patch. If the failure lives entirely in visual-builder settings, a unit test in an unrelated repository cannot verify the fix. The evidence must include the actual configuration and an app-level reproduction.

Keep a short regression note with the trigger, confirmed cause, change, and test results. That note becomes useful input when a later builder edit brings back the same symptom. It also lets Codex distinguish a returning defect from a different failure that happens to show the same empty screen.

## What still needs checking

- Original written diagnostic workflow; every suspected cause remains a hypothesis until a controlled check confirms it in the affected app.

## Data model

| Collection | Properties | Relationships |
| --- | --- | --- |
| Users | Fictional member A and member B; stable record IDs | Each member owns their submitted Support Requests |
| Support Requests | Subject; status; created date; stable record ID | Each request belongs to one submitting User |

## Common failures

### Codex repeats generic advice

Supply the actual filter expression, the saved record ID and owner value, and the active user ID. Ask which specific mismatch the evidence supports and which single check would distinguish the remaining causes.

### The list works only after all filters are removed

Restore filters one at a time in the test app and compare their actual values and types. A text name, a User relationship, an empty value, and a status record are different comparisons.

### A correction fixes new records but old requests stay missing

Inspect historical owner or status values. A corrected create action does not retroactively repair existing rows; plan a separate bounded cleanup with a backup and an explicit record mapping.

## Testing checklist

- [ ] Member A creates a support request, sees it in My Requests, and opens the same record from the list.
- [ ] Changing that request's status updates the intended record and moves it between the expected filtered views.
- [ ] Member B cannot read or update Member A's private request, including through a direct-record access attempt.
- [ ] An empty owner relationship is identified as bad data and is not fixed by weakening the access rule.
- [ ] A screen reload and a new sign-in preserve the corrected result without depending on stale component state.
- [ ] The reproduction identifies a user, record, action, and environment
- [ ] Each eliminated hypothesis has an observed result
- [ ] The correction addresses the confirmed failure without weakening access
- [ ] Fresh-session and second-account checks are recorded

## Limitations

- Codex can reason over supplied screenshots, settings, code, and logs; screenshots alone cannot prove a runtime record or permission rule.
- The diagnostic example is proposed guidance based on documentation, not a claimed repair of an inspected Adalo app.
- Preview checks and published web or native checks are separate; use the environment in which the failure actually occurs.
- The steps use visual-builder concepts; inspect the relevant generated endpoint definitions when debugging an Ada app.
## Sources

- [OpenAI: Prompting Codex and reproducing bugs](https://learn.chatgpt.com/docs/prompting)
- [Adalo: Conditions and Filtering](https://help.adalo.com/component-basics/conditions-and-filtering)
- [Adalo: Collection Permissions](https://help.adalo.com/database/collection-permissions)
- [Adalo: Relationships and available screen data](https://help.adalo.com/database/relationships)

## Changelog

- 2026-10-26: Created a Codex-assisted diagnostic method for an empty owner-filtered list, including evidence capture and regression checks.

## Related resources

- [Plan an Adalo app with Codex before building the screens](https://adalocado.com/guides/codex-adalo-app-planning)
- [Connect an external inventory to Adalo with a Codex-built adapter](https://adalocado.com/guides/codex-adalo-external-collections)
- [Create an Adalo pickup-slot component with Codex](https://adalocado.com/guides/codex-adalo-custom-components)
- [Lists in Adalo, from data to layout](https://adalocado.com/guides/adding-styling-lists)

Markdown version: https://adalocado.com/guides/codex-adalo-debugging.md