r/filemaker

Our most recent migration involved a long-time client for whom we built a CRM/invoicing system years ago.

It started originally as a simple UI — like really simple — line items expressed through repeating fields, and evolved over the years as FileMaker rolled out fresh features... like portals.

One of the things that has long been frustrating in FileMaker Layouts have been the limits of sliding. Items can slide left or slide up, and there are distinctions for "all objects above", "only objects directly above", not to mention the ability to "resize enclosing part".

That kind of dynamic positioning may have felt innovative, even breakthrough in a pre-web world, but it's been a minute since the 90s when HTML introduced notions of objects that don't just slide, but cascade in all kinds of ways, including, but hardly limited to positioning.

Over the years, as FMP evolved, our client's invoicing system grew into a 7-table relational db handling itemized entries, employee hours, notification tracking. It includes many-to-many relations set up to handle payments (multiple payments to one invoice / multiple invoices to one payment), and many-to-many self-join to track complex customer relations.

Here are some of the challenges where FileMaker really shows its limitations:

• The wonder that once was sliding doesn't extend to portal rows. A line item with a lengthy discription or comments won't grow to meet or shrink to conserve space.

• A layout with multiple portals — eg Itemized Line items and Hourly Billings — will not easily slide up / disappear layout objects depending on the portal row count.

• A many-to-many self-join requires 2 portals to fully perform. (tl;dr In other words if Contacts A & B relates to Contacts C & D each, Contact C can't represent the A & B connection in the same portal)

It's not that there aren't a myriad of ways to develop workarounds — sub-summaries layout parts, merge fields, conditional formatting can all help — but for this particular client no combo of features really satisfied their needs.

We found ourselves increasingly leaning on FM's Web Views to handle the more sophisticated requests. Web Views, FileMaker's HTML integration, are almost genius, almost the be-all end-all solution to all our dynamic UI challenges, but for their limitations: They can't slide and resize based on their internal content, they're a little sluggish when it comes to UI/UX, communication from their Web View front end to your FMP DB is as smooth as leftover oatmeal.

It's not that you can't cajole FMP to get the job done, it's that when you finally do (leaping for joy at your own ingenuity) it nonetheless feels jerry-rigged and fragile, one client request away from a pandora's box meltdown.

In the land of open source those problems have concrete, definitive solutions:

• Portals you wished would appear or disappear based row counts do just that. (e.g CSS and/or JS)

• Portal rows that in FMP can't grow or shrink, do that effortlessly in HTML (e.g. <table/tr/td> <flex> <grid> etc)

• The many-to-many self-join portal challenge is, in open source SQL, a clear and decisive query (e.g. Union)

That's the trajectory: You begin with poprietary-source FileMaker's pricy and limited walled garden which at first offers an amazing playground of features. Over time this proves itself increasingly limited as your needs and expectations grow.

The problem is the longer you stay on the FileMaker platform, the greater the technical debt when it's finally necessary to leave.

Making gregarious use of the FileMaker Web View can be very useful: Re-creating your layout using HTML in a Web View is a great way to discover A) the power of HTML, B) The limitations of FMP Layouts, all while remaining safely anchored in the more limited but more user-friendly FMP Layout.

It was precisely this kind of a transition has made our long-standing client very satisfied. They'd been increasingly chafing at FMP licensing options, and forever grumbling about Claris sales team. In fact they're quite happy to pay us far more than Claris's licensing fees to finally give them what FileMaker never quite could: Exactly the UI/UX they want — directly, without the jerry-rigging, and without having to wait 30 years for FileMaker to ultimately ignore most if not all feature requests

All this points to a key distinction: Claris isn't in the business of satisfying its customers. It's in the business of satisfying its bottom line, and at this point in time those things are not intrinsically intertwined. Claris's current leadership sees its path to success less through customer satsfaction than PR. That's why we're seeing all this hoopla around their shoe-horning of AI vector data into a container field (that can't be indexed), while their layout dynamics remain inferior to HTML3. It's why the portal relation editor after all these years remains stubbornly limited (i.e. based strictly on "and" logic with with no "or" and no parenthetical hierarchy)

The things that once made FileMaker spectacular — cutting edge innovation, combining ease of use with relational databasing, paired with robust feature evolution — has over time given way to a sales culture that assumes they don't have to earn customers when it perceives them as vendor-locked.

It didn't have to be this way. It's just the path Claris's current leadership has chosen. By all means, jump FMP onto the AI bandwagon, but remember there are decades of feature requests that have been ignored, and that load has stacked up large enough that we are slowly migrating away.

I’ve been building out a FileMaker solution that started simple but has gradually grown into something much more complex, and I’m starting to notice the usual performance trade-offs that come with that growth.

Most of the structure is still fine, but I’m seeing slower response times when working with layouts that have multiple relationships, scripted workflows that chain several steps together, and portals pulling from larger datasets. It’s not breaking anything, but the responsiveness isn’t as smooth as it was early on.

I’ve been tightening scripts, reducing unnecessary calculations, and being more intentional with relationships instead of adding them freely as the solution expands, but I still feel like there’s more I could improve on from an architectural point of view.

Outside FileMaker, I’ve also been handling a lot of document work lately and briefly used UPDF for some PDF editing tasks , it made me think more about how performance and structure matter across different tools, especially when files or workflows start getting heavier.

For those who’ve built larger FileMaker systems, what approaches have worked best for you when it comes to maintaining speed and stability over time?

Do you focus more on early optimization, or do you usually refactor once performance starts becoming noticeable?

As part of an upgrade to FMP v22 (2025) I have a script that works fine for ME, but not fine for less privileged users. It used to work fine in the old version of FMP. It would be helpful to watch it via the script debugger, but when I'm signed in as the problem accounts I don't have access to the script debugger. When I'm signed in as ME, the problem doesn't happen The problem seems to require the lower privs. How can I temporarily enable the script debugger for those lower priv accts? Or do I need to write to a log file?

* I have been stuck using FMP v6 for a super-long time, so I'm very familiar with that, but just now expanding my world with the sudden leap from v6 to FMP v22(2025). Just so you know. Thanks.

qui permettraient de lier une base mysql avec des données FileMaker de manière automatique je n’ai qu’une licence FileMaker 17 advance 5 postes et n’ai pas accepté au passage de l’abonnement annuel de passer à FM18 quelqu’un peut m’aider ?

Is there a way to open a drop-down on key stroke? I have a list of customers when I start typing in the customer field I would like the drop-down menu to open and start filtering as I start typing their name then I can click on the correct customer when I see it is this possible?

Hi all, apologies for the noob question but I’m a bit overwhelmed trying to learn FileMaker while simultaneously seeking specific answers. I’m trying to build an interactive customer database that shows multiple records in each customers file. Basically, I’m doing on-site testing of various items at locations all over the state, anywhere from 5 items to 100 items per location. Each item I test needs an individual form with the customer name, make/model, and applicable test results. Ideally, I’d like a customer database with a button of sorts that will open up my testing form where I can add as many records as needed and have them all organized within that customer’s file. Here’s where I’m at:

- i’ve created the customer database layout with a list of customer names in a portal which then shows their information. In that information, I have the button I’d like to use for the jump to the testing layout.

- I’ve created the testing layout that I’ll be using for each piece of equipment I’m testing.

I guess my question is what my next step of research should be. Should I be looking at creating a relationship between the two layouts? Should I be looking at how to create a button script? Both?

Any input is appreciated. Thanks!