1. Give the choices stable identities
A category picker should make the next choice easier. It also creates a question: what happens to an item already selected when someone changes the category? This desktop FileMaker Pro exercise makes both behaviors visible.
Use a new, disposable file. Create Categories with CategoryID and CategoryName; Items with ItemID, CategoryID and ItemLabel; and Entries with EntryID, CategoryID and ItemID. Use Text fields and manually enter unique, nonblank IDs for this small exercise. Keep all three tables in the same file.
Use category A, “Office,” and B, “Workshop.” Add these items. The category-qualified labels deliberately distinguish the two notebooks.
| ItemID | CategoryID | ItemLabel |
|---|---|---|
| A1 | A | Office — Notebook |
| A2 | A | Office — Folder |
| B1 | B | Workshop — Notebook |
| B2 | B | Workshop — Gloves |
Enter categories and one entry E01 manually. Import the CSV only into Items as new records, with its first row treated as headings. This is not an importer for a Filesoft product.
2. Separate eligible choices from the chosen item
Base the entry layout on the Entries occurrence. Create two occurrences of Items: EligibleItems and SelectedItem. Relate Entries::CategoryID to EligibleItems::CategoryID. Separately relate Entries::ItemID to SelectedItem::ItemID.
The first path answers “which items belong to this category?” The second answers “which item is stored on this entry?” Keeping them separate lets you detect an old choice without concealing its identity.
Entries::CategoryID = EligibleItems::CategoryID
Entries::ItemID = SelectedItem::ItemIDPlace the entry’s category and item fields on the layout. Add read-only displays of SelectedItem::ItemLabel and SelectedItem::CategoryID, plus a plain edit-box copy of Entries::ItemID for inspection. The diagram is a relationship plan, not a native screenshot.
3. Configure the two pickers
Create a Category choices value list using Categories::CategoryID as its first field and CategoryName as its second. Include all values. Assign it to Entries::CategoryID as a pop-up menu showing the second field.
Create Item choices using EligibleItems::ItemID first and ItemLabel second. Select Include only related values starting from Entries. Assign it to Entries::ItemID as a pop-up menu, showing the second field. The first field supplies the key even when the menu displays a label.
On E01, choose Office. Expect A1 and A2 as the eligible items. Choose Office — Notebook and inspect the plain ID field: it should hold A1. Switch to a fresh entry with Workshop and verify B1 and B2. If every item appears, inspect the value list’s starting occurrence before changing the data.
4. Expose the old-selection problem
Return to E01 with category A and item A1. Change only its category to B. Open the item picker and inspect the stored ItemID separately. A different menu is not proof that A1 was removed or changed.
Use the SelectedItem fields to explain the mismatch: the entry now says B, while its selected item belongs to A. Do not infer the stored key solely from the text the pop-up displays. Different control settings can make that text misleading.
For this exercise, use an explicit clear and reselect policy. After changing category, clear ItemID manually, then choose a matching item. Expect B1 after choosing Workshop — Notebook. The manually guided practice does not yet enforce this policy for every data-entry route.
5. Turn the policy into a separate implementation task
A finished app must apply its rule when the category changes and recheck the category/item pair before accepting an assignment. A script should verify that the item exists, read its actual category, and reject a mismatch. Define whether a blank item represents an unfinished draft or an invalid record.
A field trigger can help the interface, but imports, other layouts and scripts also need an integrity policy. Do not claim the dropdown itself prevents invalid assignments. For an automated clear action, show the user that their earlier selection has been removed; do not silently substitute the first eligible item.
Keep historical requirements separate. If existing entries must retain a former classification, design that explicitly rather than applying a new-entry rule indiscriminately to old records.
6. Test the result rather than the menu alone
| Case | What to verify |
|---|---|
| A selected | A1 and A2 eligible; stored key matches choice |
| B selected | B1 and B2 eligible |
| A1, then category B | Old key inspected; clear and reselect deliberately |
| Blank category | No category-specific choices; draft policy explicit |
| Unknown category C | No matching items; no invented default |
| Rename A1 label | Stored A1 identity unchanged |
Download the selection review checklist ↓
Commit the repaired entry, navigate away and return. Reopen the practice file and check that E01 stores category B and item B1. Repeat with the normal account intended for the app.
Finished result: a category-sensitive picker, a visible explanation of stale selections, and a written policy to enforce during implementation. Record your FileMaker version and actual outcomes; this generic desktop walkthrough does not establish Go or WebDirect behavior.
References
Use a practice copy and verify the result in your FileMaker version. Product requirements and platform support remain specific to each product.
Filesoft counts page loads and selected resource and practice-download clicks in aggregate. These aggregate counts contain no practice data or visitor identifiers. Browser privacy signals and the site’s analytics-off preference disable these counts.