Reducing Remote Calls in FileMaker 2025

This blog post was written in collaboration between Karl Jreijiri, Mislav Kos, and Mark Baum.

FileMaker 2025 has introduced many changes and new features. We were curious to see the impact these changes have on the remote calls made from the FileMaker Pro client software to the FileMaker Server. Understanding how the code we write results in remote call traffic is an important part of designing performant applications.

The new features that we investigated from the standpoint of remote calls include:

• A new function: GetRecordIDsFromFoundSet ( type )
• A new script step: Go to List of Records
• A new option for the Replace Field Contents script step
• A change to the scope of the Insert Text script step

Remote Calls: The Fast or the Furious?

One of our goals as FileMaker developers is to decrease the number of remote calls to speed up response times in our clients’ applications. A remote call consists of a request for information made from a hosted FileMaker client application to the FileMaker Server where it’s hosted, and the return of that information from the server to the client. The time it takes for this round-trip process, known as Round Trip Time (RTT), significantly impacts performance.

RTT includes both the latency (one-way delay) of the request traveling from the client to the server and the latency of the response returning from the server to the client. Now that many – if not most — applications are hosted in the cloud, these calls are impacted by the user’s internet connection. Most users have great download bandwidth, but upload bandwidth is often not as good, and latency, the time it takes for a packet to travel to the server and back, matters just as much. This means that while server responses usually arrive quickly, sending large or frequent requests can be slow. Both limited upload bandwidth and high latency will increase RTT and hurt performance. While we can’t directly reduce RTT, minimizing the number of remote calls is a key strategy to improve overall application responsiveness.

Remote calls are made frequently under a wide range of circumstances: for example, when you load a layout or execute various script steps. If the information needed for these operations isn’t cached on the client machine, the information needs to be retrieved from the server as one or more remote calls. Depending on how long each round-trip call takes and how many calls your system needs to make, your users will either have a fast, high-performing application, or they’ll end up frustrated – sometimes even furious – during mission-critical tasks.

So, how do the changes in FileMaker Pro 2025 help? Let’s go through them one by one.

New Function: GetRecordIDsFromFoundSet ( type )

This function captures the internal record IDs from the current found set of records (for full details, see Capturing and Recreating Found Sets in FileMaker Pro 2025 [NEED LINK TO BLG-623]).What used to be a complex, multi-step process – making lots of remote calls – now can be accomplished by referencing this function, which requires no information from the server to return its result.

For example, one technique involves adding a “List of” Summary field to each table and then evaluating that summary field. If the found set is large, it’s likely that the field values needed are not entirely cached on the client machine and must be retrieved, i.e., downloaded from the server using remote calls. Another technique uses the While and GetNthRecord functions to iterate through the found set, building a list of all record IDs. Again, not all the record information might be cached. The bottom line is that both techniques get bogged down as the found set starts to grow.

In contrast, the new function queries internal record IDs without the need to contact the server at all. No remote calls are needed because the FileMaker Pro client keeps track of these IDs locally. Here’s how that happens:

The first time a layout is loaded, all the record IDs for that layout’s table are downloaded to the client (if they haven’t been already). Thereafter, these record IDs are maintained on the client, getting updated whenever any user adds records to or deletes records from the table in question. This process happens in the background and has been highly optimized over the years.

Because the GetRecordIDsFromFoundSet function doesn’t need to query the server, it’s impressively fast. Of course, it’s limited to returning internal record IDs rather than primary keys or any user-defined field, but the performance tradeoff is worth it.

New Script Step: Go to List of Records

The Go to List of Records (GTLOR) script step works as a companion to the GetRecordIDsFromFoundSet function. I’m looking forward to the community discovering a range of uses for this step, but the most evident is the recreation of found sets based on results returned by the function. Until now, FileMaker Pro developers have used two main techniques for recreating a found set of records based on a list of record IDs:  using the Go to Related Record step using a multikey on the relationship match or by performing a Find consisting of multiple requests, one for each record ID to be found. (We wrote about these techniques and others in this blog post.) The remote call associated with these techniques can be verbose in both directions: complex requests for information made to the server, and large amounts of data returned (especially when wide tables are involved).

Furthermore, both approaches return a set of records in creation order (unless the GTRR relationship is sorted, in which case that order is used). If a different record order is desired, the Sort Records step must be performed, which impacts performance further. But Go to List of Records allows you to specify a series of record IDs in any order you choose, including the order returned by the GetRecordIDsFromFoundSet ( type ) function.

Our testing showed this new technique to be very fast: <200ms for 70K records.

Interestingly, all ID list types—retrieved from GetRecordIDsFromFoundSet ( type )—performed at similar speeds. Some of the types make it possible to return the list of IDs using ranges, e.g., 1¶3-5 instead of 1¶3¶4¶5. We expected that using ranges would be faster, but that doesn’t seem to be the case. Using ranges is still preferred, though, because large found sets will result in large lists of ID values. Storing those values in a variable will be less performant than storing the same values represented as ranges.

New Script Step Option: Replace Field Contents

Now, when you use the Replace Field Contents script step, you skip triggering any auto-enter options associated with the field in question. This can improve performance since only the field in question is changed, and potentially complex auto-enter calculations are not evaluated. One useful application of this option is to change data without updating any modification account or timestamp fields, which could be useful for post-deployment data updates or transformation.

Change to Script Step: Insert Text

The Insert Text script step now has a limit of 250,000,000 characters, a considerable increase over the previous 30,000. Why do we care about this? The Insert Text script step is commonly used to place static content, such as JavaScript and HTML data, within scripts instead of storing them in tables. Previously, developers had to split large content into chunks. Now they no longer need to do this.

This is a convenience for developers, but large volumes of static text increase the file size, resulting in:

• Bigger scripts
• Bigger clones
• Bigger save-a-copy-as-xml and DDR files.

Whenever a script is changed and then saved, the script has to be sent back to the server. And when that script is unusually large, typically due to high volumes of static text, the save operation becomes noticeably slower, especially when the developer’s connection isn’t great – making the editing process feel sluggish and interrupting the developer’s flow.

High volumes of static text can also slow down DDR or save-a-copy-as-xml analysis tools since they must process more information.

Below are screenshots of one save operation for a 4 MB script (4 MB of content in Insert Text). These screenshots come from FileMaker Remote Call Logs Analyzer. Note that it took 507ms to save the script.

When remote calls contain large payloads, they get split into chunks. Each chunk requires a separate remote call. The next screenshot shows us that saving the 4MB script actually resulted in 5 remote calls.

So, in terms of remote calls, this change in behavior doesn’t have a significant impact since it gets chunked one way or another.

It’s worth bearing in mind that large scripts also impact the user experience as they can take a long time to download. Fortunately, this only happens once per script as the script is cached thereafter. But it’s good practice to assess just how long that initial download takes under typical user network conditions and how that might feel to the user. And it’s important to resist the temptation to include ever-larger amounts of static text now that the limit has been raised.

Conclusion

Please consider experimenting with these new features and changes in FileMaker 2025 to learn how they might affect your coding strategies and reduce the number of remote calls in your applications. Let us know if you discover things we haven’t documented here, or if you find other ways to leverage these welcome improvements to FileMaker Pro.

Launching New FileMaker 2025 Features

Our team has hit the ground running with FileMaker 2025, helping our clients understand the best way to upgrade and the most impactful features to launch in their systems. Need help? Contact our team to talk with an experienced FileMaker consultant.

Don’t miss our other FileMaker 2025 blog posts. Our team is weighing in on critical changes and the best new features for your application.