FileMaker 2025 includes a whole host of new features — plenty of glitzy headline items like AI integration and Claris Studio. But two additions that haven’t received nearly as much attention are the new GetRecordIDsFromFoundSet function and the “Go to List of Records” script step. Used together, they fundamentally change how we can store, pass, and recreate found sets, and they unlock workflows that simply weren’t practical before. Two use cases stand out.
Cleaning Up Navigation Without Relationship Bloat
Many FileMaker developers rely on a familiar technique: create a relationship between a global text field and a primary key, load that global field with a list of record IDs, then use the relationship to navigate to a specific group of records. It works, but it creates problems over time.
Relationship graphs become cluttered. Global fields multiply. Schema complexity increases and performance can suffer. In larger FileMaker solutions, that structural overhead adds up fast.
With FileMaker 2025, you can now accomplish the same result without the extra relationship or the global field. Instead of relying on schema to hold navigation state, you store found sets directly as record IDs and reconstruct them on demand.
The Back Button FileMaker Users Have Always Wanted
FileMaker developers have been asking for a true back button for a very long time. I’d say since the first release, but FileMaker actually predates the web browser — so let’s call it since FileMaker 3.0.
There have been ways to approximate browser-style navigation in the past, but they were rarely simple or performant. They required complex scripting, fragile assumptions, and constant maintenance. As one of my colleagues often says, the juice wasn’t worth the squeeze.
Until now.
Thinking in Stacks Instead of Screens
Before diving into FileMaker specifics, it helps to step back and think about how navigation actually works at a conceptual level.
The simplest model is two stacks of information — similar to two stacks of pancakes. One represents where the user has been (the Back stack); the other represents where they can return to (the Forward stack). Each “pancake” is a snapshot in time: the current layout, the full found set, and the current record.
Every time the user navigates somewhere new, a snapshot is created and pushed onto the Back stack. Clicking Back moves the current snapshot onto the Forward stack and restores the previous one. Navigating to a brand-new location discards the Forward stack entirely — a long-established browser convention that prevents “Forward” from leading somewhere that no longer makes sense.
Capturing a Snapshot in FileMaker
Each snapshot is stored as a single JSON object containing three things: the layout name, the IDs of every record in the found set, and the record ID of the current record.
JSONSetElement ( “” ; [“layout” ; Get ( LayoutName ) ; JSONString] ; [“ids” ; GetRecordIDsFromFoundSet ( JSONStringRanges ) ; JSONString] ; [“current” ; Get ( RecordID ) ; JSONNumber] ) |
The key piece here is GetRecordIDsFromFoundSet. This FileMaker 2025 function allows us to capture the entire found set in a form that can be stored, passed, and later reconstructed.
The most efficient format is JSONStringRanges. Instead of storing every record ID individually, consecutive IDs are compressed into ranges — so IDs 3, 4, 5, and 6 become 3-6. This reduces the JSON payload size and keeps navigation fast.
When the Snapshot Runs
The snapshot is captured automatically using an OnRecordLoad script trigger. Every time the user navigates normally, the system records where they’ve been. The one important exception: when the user clicks Back or Forward, the snapshot script is intentionally bypassed so the navigation stacks can be managed manually. Those scripts require a bit more logic to keep everything properly aligned.
One Small Schema Change
FileMaker exposes Get(RecordID) function, but it doesn’t expose that value as a searchable or navigable field. The fix is straightforward: each table that participates in navigation needs a calculation field that simply returns the record ID. Once that field exists, you can reliably jump back to the exact record the user was viewing when the snapshot was taken.
How the Back and Forward Buttons Work
The Back and Forward scripts each do three things:
- Recreate the found set using the new Go to List of Records script step, passing in the previously captured record IDs.
- Manage the stacks: going back moves the current snapshot to the Forward stack; going forward moves it back to the Back stack. The current location is removed each time to keep the stacks accurate.
- Jump to the right record: after the found set is rebuilt, the script determines where the target record sits and navigates directly to it using Go to Record. This uses GetRecordIDsFromFoundSet a second time, combined with a simple position calculation.
Getting Up and Running Quickly
Implementation is straightforward:
- Create the recordID calculation field in each table involved in navigation.
- Copy the three scripts: CaptureState, BackButton, and ForwardButton — into your solution.
- Attach CaptureState to the OnRecordLoad script trigger.
- Add a button bar with Back and Forward buttons to the relevant layouts.
From there, refine the behavior as much or as little as you like.
Sample File
We’ve included a fully working sample file that demonstrates the entire approach — stack management, script triggers, and navigation buttons. Copy it directly into your own solution and adapt as needed.
If you’d rather not tackle this yourself, or if you’re looking for help designing, optimizing, or modernizing your FileMaker systems — reach out to us. We’re always happy to help you get more performance, stability, and usability out of your FileMaker solutions.
