The first thing to state here is that there are many ways to handle scripts. There is no single best method. Yet, what I describe here has proven to be quite usable over time. It is experience and you can play with the suggestions to find your own best method.

Different styles of organizing

People are different, experience differs and there are logically many ways to handle scripts. Usually, you start by creating your first script, then a second one, a third one and so on. You end up with a long list of scripts. Here are some ways to cope with many scripts:

• Go with the flow. Let there be chaos. I don’t care.
• Use subdividers and/or folders to create a grouping of scripts.
• Use numbering of scripts to create a “logic” you can refer to.

One also could argue that the number of scripts can become a burden. I have seen and created solutions with hundreds of scripts. The organization of these scripts becomes essential to understanding the solution, solving questions, fixing bugs, and enhancing the functionality. The sheer number of scripts can be reduced by several methods:

• Create dynamic scripts, which work with parameters to do different things

Like: a single navigation script, which gets the name of the target layout as a script parameter.

• Combine different functions in a single script by using script parameters and IF-contexts.

Like: {IF script parameter = “A”, “do This”; else “do That”}.

The use of script parameters opens up many options. This is not a system by itself but a way to approach the complexity of many scripts.

Define the purpose of scripts

FileMaker does not define the purpose of scripts, how many there are, or how you should structure them. That is all up to you. Therefore, it is helpful to give the purpose of scripts some more thoughts. Deliberately understanding and using scripts for specific purposes helps to structure them.

Over time I learned to differentiate scripts for two purposes:

1. Simple scripts to perform basic tasks on current tables and layouts.
2. Workflows to combine complex tasks across multiple tables and layouts.

This differentiation is helpful to reduce redundancies. Simple scripts can, for example, create, print, find and show data from a certain page or table. Workflows can use these simple scripts during more complex operations.

This works if you already are on a layout with the appropriate table. For a more complex workflow, where you even might be on a different layout and table, you can still refer to that script, but with a little extra help.

These are concepts, not ready-made solutions. As ideas, they must prove themselves in more complex situations. As to what these things do: I can change basic scripts, and the renewed functionality is automatically used by more complex workflows. Therefore, it makes sense to me to keep basics and workflows separated, while workflows might refer to basic scripts (and usually do).

Modular approach

When thinking about scripts, one might consider a modular approach. That is, keep parts of an application focused within themselves, as far as possible. Though there is no specific concept of “modules” within FileMaker, think of logical entities like “Addresses”, “Projects” or “Sales Documents”. Anything that refers to a certain environment could be saved within a folder for that environment. Logically, groups are defined by tables and (frequently) layouts. Now organize scripts similarly. Grouping of scripts according to modules is sensible. It reduces the complexity of scripts by limiting basic scripts to certain environments. That is why basic scripts are truly “basic”. Only “workflow” scripts would venture out and combine things from multiple environments.

• As far as possible, limit yourself to one environment at a time.
• Keep things neat and clean (KISS principle: “Keep it simple stupid”, or “Keep it simple sustainable”).
• Shorter scripts are easier to maintain.
• Linking scripts to modules or function blocks is easier to understand, maintain and enhance.
• Name scripts according to their module and function.

Layout approach

For myself, the modular approach proved itself well, but I wanted to further simplify things. That is where I realized that basic scripts could be limited to single layouts. In FileMaker, each layout must have a table assigned. Why not create scripts on a “per layout” base? There are several advantages to this approach:

• Easy to find. If you are on a “Sales Details” layout, you just might find a script with the same name for anything on that layout.
• Limited in scope and thus easier to maintain.
• Basic functionality within that layout.

This is the method I use most today: basic scripts are per layout, while more complex workflows are handled separately. This is not rigid. It might be that on a single layout specific tasks can be quite elaborate and thus deserve their own extra script. Still, however, this extra script can be linked to a specific layout. Think, for example, of several printing options within a specific layout. It might be worthwhile considering a specific script for output options.

Combining scripts

Plenty of FileMaker applications I was privileged to look at had many scripts. Frequently, I noticed, there were loads of tiny scripts, each several lines only. There is nothing wrong with that approach, but the number of scripts can get extreme. How to cut down on scripts?

As I turned towards the concept of “scripts per layout”, as explained just before, I had a need for many smaller scripts, all for a single layout. That is precisely why many applications have small scripts, but multitudes of them. Today, I combine these smaller functions into a single script. That script has multiple purposes, not just a single purpose. To make a script more versatile, one can use script parameters when calling the script. You define both the script plus the function by using a parameter.

In the script, you build a series of IF-contexts. Each IF-request can have a specific parameter attached. When calling the script with that parameter, only the IF-context with that parameter will be executed. Multiple contexts with different parameters thus provide, within a single script, multiple purposes.

Three options are mentioned. They are all within the same script. Only a single option will be executed at once, and only when an available parameter has been handed over when calling the script.

A multipurpose script has several advantages:

• Reduce the number of scripts.
• Group small functions logically (in a single script, attached to a layout, for example).
• When using an IF-context consistently, these scripts will do nothing except if called with a parameter (= enhanced security).

Workflow scripts

Think of workflow scripts as complex tasks beyond some basics as “new record”, “delete record”, “print record” and other similar options. A workflow can create a report while gathering information from several tables and layouts. Thus, a workflow has multiple steps involved. That predefined workflow is what the script is about. It helps to solve more complex tasks with a single starting point, like building a part list, creating an email with an attachment, sending out a reminder for a payment and updating the reminder level. Things like that. Repetitive tasks with more complexity are perfect for this category of scripts.

Organizing scripts

We looked into several aspects of creating and organizing scripts within themselves. These were concepts only. Much more can be said, but nothing matters as much as your experience with your projects. This also is the approach I take with our starter files.

Working with AI

FileMaker developers increasingly work with AI tools. If you trust AI to do whatever it thinks is best, it can get messy. Therefore, project rules can be established. If you aim at easy readability, even if no AI is available, you could describe the preferred way to set up and write scripts. That can be something similar to this article or entirely different.

Think of scripts that are performed on a FileMaker server. That server works like a blackbox for any script. It is challenging to track what exactly is happening. Developers found multiple ways to define scripts in such a way as to provide feedback on the process «from within the blackbox of the server». When working with AI, similar care must be taken to improve the script for yourself or anyone else reading it later.