1. Turn the request into an observable result
“Improve the contact screen” is too broad to test. For this walkthrough, the request is: “Show the contact’s preferred name on the entry screen, while keeping the legal name on invoices.” It sounds like a label change, but it may involve a new field, a layout change, searches and document rules.
Write three acceptance checks: the preferred name can be entered and reopened; the legal name remains available; existing invoices still display the legal name. Also write what is outside scope, such as replacing names in every historical export. This short boundary prevents an apparently helpful edit from becoming an unreviewed data migration.
2. Establish a recoverable starting point
Confirm who can authorize the change and whether the file is local or hosted. Create an appropriate backup and a separate development copy. Do not filesystem-copy an open database. For hosted work, use the established backup or maintenance process.
Record the filename, FileMaker version, relevant plug-ins and external dependencies. Keep credentials out of notes and public screenshots. Open the development copy and confirm that you can reach the contact and invoice workflows before changing anything.
A backup filename alone is not a recovery plan. Know which copy is the baseline and how you would return to it without overwriting newer business records.
3. Follow the data through the workflow
Find the table and field that currently hold the legal name. Inspect the contact layout’s table occurrence, its field bindings, the save/navigation actions and the invoice layout’s source. List the places where the requested preferred name should appear and where it should not.
Use a Database Design Report when available to inspect references. Filesoft DDR Explorer can help navigate fields, layouts and scripts in the imported XML reports. Its findings describe those reports; they are not proof that the live file has no other dependency. Dynamic field names, external systems and runtime behavior require separate review.
Use the existing guides on field references and script review for the detailed inspection. This article combines those steps into a change plan rather than repeating the individual techniques.
4. Record the current behavior
| Check | Before the change | Expected afterward |
|---|---|---|
| Open a contact | Legal name is visible | Legal name remains; preferred name is additional |
| Save and reopen | Existing values persist | Both intended values persist |
| Find by legal name | Known contact can be found | Existing search still works |
| Export invoice | Legal name appears | Legal name still appears |
| Contact with no preferred name | Existing screen works | Screen remains understandable |
Use fictional records, including a long name and an empty preferred name. Capture only the screens needed to compare the result. If the baseline already fails a check, record it separately so you do not mistake an existing problem for a regression.
5. Implement the smallest complete change
Only after the mapping is clear should you decide whether the request needs a new field, a calculation or simply a layout change. A preferred name should not silently overwrite a legal name just because that is the easiest field to reuse.
Update the intended layout and any genuinely required scripts or validation. Keep unrelated redesign work separate. Review access privileges if the new field should have different visibility, but do not grant broader access merely to make development convenient.
Run the original checks again and compare the invoice PDF, not only the entry screen. Where the change affects multiple layouts or platforms, name those targets explicitly and test them separately.
6. Hand over a decision, not only a file
Document what changed, what stayed outside scope, which checks passed, and which checks still need review. Include any data-migration step and the conditions for returning to the prior version. A replacement file does not automatically contain the newest records from the file people are using.
Download the customization review checklist. Use it to record evidence rather than ticking boxes from memory. Native visual and interaction checks need a person to exercise the actual file; a structural report alone cannot establish those results.
Finished result: a small, explained change with a known baseline and repeatable checks. If you cannot identify where the invoice gets its name, stop the implementation and finish that investigation first.
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.