# Everything about FileMaker 2026 **URL:** \ **Category:** Floating Topics\ **Tags:** filemaker, announcement\ **Created:** [June 9, 2026, 4:18pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503 "2026-06-09T16:18:58Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![FabriceN](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/fabricen/32/2506_2.png) [@FabriceN](https://the.fmsoup.org/u/FabriceN)\ **Post date:** [June 9, 2026, 4:18pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/1 "2026-06-09T16:18:58Z")
Just my writeup > **[FileMaker 2026 is here! – 1-more-thing](https://www.1-more-thing.com/en/filemaker-2026-is-here/)** ---
**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\ **Post date:** [June 10, 2026, 10:04am UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/2 "2026-06-10T10:04:33Z")
There is such a huge amount of change in this version. It's a stand-out. ---
**Author:** ![FabriceN](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/fabricen/32/2506_2.png) [@FabriceN](https://the.fmsoup.org/u/FabriceN)\ **Post date:** [June 10, 2026, 11:05am UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/3 "2026-06-10T11:05:40Z")
and I didn't mention the small changes. There are really many. ---
**Author:** ![MonkeybreadSoftware](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/monkeybreadsoftware/32/361_2.png) [@MonkeybreadSoftware](https://the.fmsoup.org/u/MonkeybreadSoftware)\ **Post date:** [June 10, 2026, 11:33am UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/4 "2026-06-10T11:33:06Z")
@WimDecorte wrote a nice blog post: > **[FileMaker 2026 Executive Summary](https://www.soliantconsulting.com/blog/filemaker-2026-executive-summary/)** > > FileMaker 2026 ships persistent data, Standby Server, PDF steps & AI upgrades. Get our expert breakdown & plan your upgrade with Soliant. and I also wrote something: > **[FileMaker 2026 released](https://www.mbsplugins.de/archive/2026-06-10/FileMaker_2026_released/monkeybreadsoftware_blog_filemaker)** ---
**Author:** ![JasonMark](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@JasonMark](https://the.fmsoup.org/u/JasonMark)\ **Post date:** [June 10, 2026, 4:27pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/6 "2026-06-10T16:27:54Z")
Trying to wrap my head around the **GetPersistentData ( name ; instanceID ).** Right now I have a table called "settings" with a bunch of things like "startOfSchoolYear" "endOfSchoolYear" and "listOfHolidays" and "listOfSchoolDays". "listOfSchoolDays" is a slower calculation that removes weekends and holidays (including snow days which show up mid semester and change the last day of school) I go in nightly and fill these in in the settings table, and then when a user opens Filemaker it sets $$listOfSchoolDays to the item in settings. Am I right in understanding that **GetPersistentData ( name ; instanceID )** is "the modern" way to do that? And I could (for example) just a have a simple script that gets a list of them all and turns them all into $$globalVariables, or maybe something smarter than that which only makes "some" of them global variables. If it was as fast as a variable (which hopefully it will eventually become) it could replace them completely in these instances, right? ---
**Author:** ![MonkeybreadSoftware](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/monkeybreadsoftware/32/361_2.png) [@MonkeybreadSoftware](https://the.fmsoup.org/u/MonkeybreadSoftware)\ **Post date:** [June 10, 2026, 4:50pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/7 "2026-06-10T16:50:20Z")
GetPersistentData is not a global variable. You will still have setting tables. This is for embedding data in the structure like templates for CSS, HTML and JavaScript. Or maybe an base64 encoded logo. And you can't store secrets there as people will see them in Save as XML. if the user is supposed to update this, you may still use a field. ---
**Author:** ![JasonMark](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@JasonMark](https://the.fmsoup.org/u/JasonMark)\ **Post date:** [June 10, 2026, 5:04pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/8 "2026-06-10T17:04:04Z")
ok makes sense. ---
**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\ **Post date:** [June 10, 2026, 8:41pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/9 "2026-06-10T20:41:09Z")
There is a big overlap in the capabilities of persistent data and global variables. For that reason the use cases are also going to feel similar. When I first heard about them, it brought to mind Value Lists. They are also "global" within a file and they also do a task that could be done with tables. Admittedly the use case for Value Lists is narrow: present a set of records to the user. But in the background, it's a file-specific, global store. In your example you have to calculate school days every night. Is there any advantage in switching? The examples provided in the documentation is suggesting that they are intended to replace on-layout text objects or single record tables which store code for webviewers and add-ons. I can imagine scenario where the developer provides themselves with DEV\_ONLY layouts that provide them with tools to view and add persistent data as a initialisation or periodic update. > **[ListPersistentDataIDs](https://help.claris.com/en/pro-help/content/listpersistentdataids.html)** > **[GetPersistentData](https://help.claris.com/en/pro-help/content/getpersistentdata.html)** ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [June 30, 2026, 6:28pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/10 "2026-06-30T18:28:57Z")
Although first load speeds will be relatively slow (some indications are 7x slower first load, then cached), this could be used a a global variable across all sessions (unlike a traditional global that is session specific). May not be the best or most appropriate use case, but it is a possibility. I'm sure new use cases will appear to go with this new capability. ---
**Author:** ![jwilling](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/jwilling/32/256_2.png) [@jwilling](https://the.fmsoup.org/u/jwilling)\ **Post date:** [June 30, 2026, 9:22pm UTC](https://the.fmsoup.org/t/everything-about-filemaker-2026/5503/11 "2026-06-30T21:22:41Z")
I think my general rule for Persistent Data is: Use Tables+Fields for _data_ and Persistent Data for _schema_. So very much in line with what @MonkeybreadSoftware said. If i configure a webviewer widget, i'm happy to store the html/css/js in persistent data. Or if i version my software releases, I could store the release version string in persistent data ("2.0.1" eg). Or an app logo, that is the same for all copies of the file. I most likely won't use this feature for deployment or customer-specific information/data, or configuration/settings. Tables are fine for that.