1. Separate the label from the link
A name helps a person choose. An ID identifies a record. If a task stores only “Website refresh,” renaming the project or creating another project with that name can make the relationship ambiguous. In this exercise, the task stores ProjectID while the interface helps the user choose by name.
Work in a new practice file with Projects and Tasks tables. Give Projects a Text ProjectID and Text ProjectLabel. Give Tasks a Text TaskID, Text TaskName and Text ProjectID. Use three manually entered, unique IDs for this small exercise; a real design needs a reliable key-generation and validation policy.
| ProjectID | ProjectLabel |
|---|---|
| P-001 | Cedar — Website refresh |
| P-002 | North — Website refresh |
| P-003 | Cedar — Welcome pack |
Notice that the labels distinguish the two website projects. A label should help people choose the right record, not merely look shorter.
2. Connect tasks to projects
In Manage Database, create the relationship from Tasks::ProjectID to Projects::ProjectID. A task holds the key of its chosen project; several tasks may hold the same project key. Place TaskName and Tasks::ProjectID on a layout based on Tasks. Also place the related Projects::ProjectLabel on the layout as a read-only confirmation.
The confirmation is useful during testing: it tells you which project the relationship actually reaches. A menu that looks correct is not enough if the field underneath is bound to the wrong table occurrence.
3. Build the two-field value list
- Choose File → Manage → Value Lists and create a list named Project choices.
- Choose values from a field. Set the first field to Projects::ProjectID and the second display field to Projects::ProjectLabel.
- For this first version, include all values and show only the second field. Use distinct labels for all three practice projects.
- In Layout mode, select Tasks::ProjectID and assign the list to a pop-up menu in the Inspector. Return to Browse mode.
The first field supplies the stored value; the second supplies a readable choice. These are separate roles. Claris documents the two-field value-list options.
4. Prove that the ID is stored
Create task T-001, “Check opening paragraph.” Choose Cedar — Welcome pack. On a temporary plain edit-box copy of the Tasks::ProjectID field, verify that its stored value is P-003. The related label should show Cedar — Welcome pack.
Now change that project’s label to Cedar — Updated welcome pack. Leave its ID unchanged. The task should still refer to P-003, and its related label should reflect the renamed project. This is the behavior the design is intended to provide; verify it in your FileMaker copy before relying on it.
Choose North — Website refresh on another task and check for P-002. This catches the mistake of accepting the first similar-looking project name without checking the key.
5. Handle confusing and missing choices
- Duplicate labels: include a client or short project reference in the label. Do not assume two identical display values will be distinguishable in a second-field-only list.
- An empty list: confirm that Projects contains records, the fields contain values, and the value list points to the intended table occurrence.
- A visible ID: check the control style and display options. A plain edit box is useful for diagnostics but is not the finished chooser.
- Historical choices: decide what should happen when a project becomes inactive. Hiding a choice must not erase the existing relationship.
A filtered “active projects” list is a useful next exercise, but start with the all-projects list so you can separate relationship errors from filtering errors.
6. Keep selection and validation separate
A convenient chooser is not a complete integrity rule. Decide whether a task may have no project, what happens if a project is deleted, and which users may change the selection. Test those rules separately. Do not enable cascading deletion merely to make this example work.
Finished result: two tasks connected to different projects by ID, a readable chooser, and a rename test that preserves the relationship. Keep the plain ID display in the practice file until you understand the result.
References
Use a practice copy and verify the result in your FileMaker version. Menu wording and platform behavior may differ.
Filesoft counts page loads and selected resource and practice-download clicks in aggregate. These counts contain no practice data or visitor identifiers. Browser privacy signals and the site’s analytics-off preference disable these counts.