One of the hardest parts of development is knowing when something is actually finished. The more complex a system becomes, the easier it is to overlook small but critical details.
Is there some edge case that I haven’t taken into consideration? Is there something simple that I’m forgetting? Wouldn’t it be amazing if there was some sort of checklist to help know if something is ready to sign off on?
Step 1: Start With the User Story
Before writing any script, I verify the underlying requirement is clear.
After reading a user story, the team knows why they are building, what they’re building, and what value it creates.
A simple user story format works well:
Template
As a [persona], I want to , so that [benefit].
Example:
As an inventory manager, I want to receive stock into the system so that inventory levels remain accurate.
Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
In order to confirm everything works later, we will need to identify some pre-requisites?
- What will be the expected workflow?
- Are there any edge cases that need to be identified?
- Are there specific privilege sets that will be used?
A good story also includes acceptance criteria, such as:
- Inventory quantity increases correctly
- A transaction record is created
- The user receives confirmation of success
These criteria become the basis for testing later.
Step 2: Does it work?
Before reviewing the code itself, I confirm the script actually solves the intended problem.
Checklist:
- All user story requirements are met
- Acceptance criteria are satisfied
- Edge cases are tested
- Script works across expected workflows
If the script fails any of these tests, it is not finished.
Step 3: Error Handling
FileMaker scripts must assume that things will go wrong.
Common issues include:
- failed finds
- missing records
- deleted related data
- privilege restrictions
Minimum error handling includes:
Set Error Capture [ On ]
Then checking:
Get ( LastError )
Critical steps that should always be checked include:
- Perform Find (watch for 401)
- New Record
- Delete Record
- Import operations
- External script calls
- Go To Related Record
If an error occurs, the script should handle it gracefully rather than silently failing.
Step 4: Data Integrity
Many FileMaker issues arise not from logic errors but from data structure mistakes.
My checklist includes verifying:
- Primary keys use Get(UUID)
- Foreign keys are populated correctly
- Unneeded foreign keys are removed
- Transactions are used when multiple records are created or modified
Transactions are particularly important when multiple steps must succeed together. If any step fails, the entire operation should be rolled back.
Step 5: Script Organization
A finished script should be easy for another developer to understand.
Checklist:
- Script is placed in the correct module folder
- Naming conventions are consistent
- Complex logic includes comments
- Variables are clearly named
- Duplicate scripts are eliminated
Organization may seem cosmetic, but it dramatically affects long-term maintainability.
Step 6: Privilege and Context Testing
Scripts behave differently depending on user privileges and layout context.
Before finishing a script I test:
- multiple privilege sets
- different layouts
- unexpected navigation scenarios
This helps catch problems such as:
- restricted field access
- blocked record creation
- layout-dependent behavior
Step 7: Performance Check
Finally, I verify that the script runs efficiently.
Checklist:
- Loops minimized
- Finds optimized
- unnecessary commits removed
- temporary data removed
Even small inefficiencies can become significant when a script runs thousands of times.
Final Script Test
Before declaring a script complete, I run the full workflow from start to finish:
- create records
- modify records
- test errors
- confirm user messages
If everything works under realistic conditions, the script passes the checklist.
At that point I can confidently say:
This script is done.
