Last week in this space, I shared some thoughts on Workflow as they related to the presentation I was honored to give at the 2017 FileMaker Developer Conference, held last month in Phoenix, AZ. In Part 2 of my post, I would like to share some of the key points specific to the FileMaker Script Triggers portion of my “Workflow Automation with Script Triggers” session.
When talking about script triggers, the best definition I found is that a script trigger specifies that a script runs when an event occurs. This then leads us to the question “What is the event?” In FileMaker, we know that a button, a menu item, or even another script can call a script. While those actions are technically script triggers (lower case “s” and “t”), they are not the events and Script Triggers (upper case “S” and “T”) we are talking about here and now.
The Script Triggers I am focusing on were first introduced with the release FileMaker 10 in January 2009. We started with 14 at our disposal and that number has grown to 25 as new ones have been added with subsequent releases of the FileMaker Platform. As you might guess, a lot has already been said about them to this point. There are a number of Knowledge Base articles at filemaker.com about Script Triggers. Also, if you are part of the FileMaker Community, you have access to Tech Briefs in the Resources area devoted to Script Triggers. With this wealth of knowledge already available to us, I am not going to go through each Script Trigger and discuss the minutia of each one. However, there are several broad questions that need answered as we move forward with the intent of automating our workflow.
First, “Where do Script Triggers operate?” There are three different areas in our FileMaker custom apps where Script Triggers operate – the Window level, the Layout level, and the Object level. As outlined in Part 1 of this post, we need to understand the physical process our client has asked us to automate. Once we know the physical steps that move us from one task to the next, we are able to translate those actions into the FileMaker space and select the appropriate Script Triggers for our automation. We may write the script one way if the event occurs when the user moves to a specific layout. If the script needs to execute when the user exits a specific field, we may write it a different way.
The second question we need to answer is “When does the script begin to run relative to the triggering event?” This is important because some script triggers run the script before the event is processed by the database engine while the remaining script triggers execute the script after an event is processed by the database engine. In those instances where the script is run before the event is processed, we have an extra level of control in our solutions. Using logic built into the script, we are able to cancel the triggering event and prevent the users from moving somewhere they shouldn’t go or doing something they shouldn’t do.
A quick example of this difference would be to look at the OnObjectEnter and OnObjectExit script triggers. Imagine if you will that we have placed a field on a layout with both of these script triggers defined for it. When entering this field by clicking the mouse inside its borders or by tabbing to it in the tab order, the database engine recognizes the triggering event and starts the script assigned to the OnObjectEnter script trigger. Because this is an “after-processing”, or post-event, trigger, the event has already occurred and been processed. The target field has focus as the script is running. We are unable to cancel the event, because the user has already entered the object before the script runs.
On the flip side, when exiting this field by clicking the mouse outside its borders or by moving to the next object in the tab order, the database engine again recognizes the triggering event and starts the script assigned to the OnObjectExit script trigger. Since this is a “before-processing”, or pre-event, trigger, the pending event has been acknowledged by the system but the action has not yet taken place. The OnObjectExit-triggered script is running but our field still has focus. If the script returns a True result, the triggering event is then processed, and the field is exited. If the result is False, the triggering event is cancelled and our field retains focus.
As noted above, this gives us a lot of power in our solutions since we can cancel events from occurring. But, as Uncle Ben likes to say, with great power, comes great responsibility. I’m sure you can see the potential peril. As we write scripts that include If/Else logic for pre-event Script Triggers, we must have a branch that results in an exit condition so we don’t get stuck. Luckily, FileMaker is looking out for us in case we forget. A pre-event script trigger will interpret an empty script result as “True” and process the event. That being said, I would strongly encourage you to explicitly declare all script results in any scripts that will be initiated by pre-event script triggers. I think it’s a good habit to get into since it removes any ambiguity from what is going on when you review the scripts at a later date.
With that tip, I also have one more recommendation. Do not try your initial testing without using FileMaker Pro Advanced and the available Script Debugger. The Script Debugger allows us to step through each script line by line. We can also skip steps or cancel the script all-together.
The third question we want to answer is “What is the timing of the script triggers?” When multiple script triggers are activated by the same event, the script triggers perform in a relative order, which may yield an unintended result if you’re not expecting it. Granted, this scenario is dependent upon the complexity of your solution as only those script triggers which are defined will be triggered by that same event. Still, it’s worth noting that it can happen.
For the other script triggers, the order is controlled by the triggering event. For these events, it all comes down to “Which came first?” This is another area where developing with FileMaker Pro Advanced is very helpful. While using the Script Debugger, we can see each of the scripts cue up in the Call Stack as we test our automation.
The final question is “What privileges does the script have when initiated by a script triggers?” The short answer is that it uses the existing privileges for the current user. If our script-triggered script is going to perform some action that the user doesn’t normally have permission to do, that action will fail. Depending upon the nature of the action, this failure could result in unintended and possibly catastrophic changes to the data. One option is to update the users’ privileges to give them the needed permissions to perform that action all of the time. The second option, which is much easier to implement, is to define the script in question to run with full access privileges.
To close out this article, here are several links to documentation you may find helpful:
