FileMaker DevCon 2019 is done, over, kaput. The FileMaker & JavaScript training session we led during the conference brought over 100 people together to learn the basics of JavaScript inside of FIleMaker. It was a long day of learning and stumbling and success, and many of the attendees found a lot of value in it.

But it was only six hours. It went fast–probably three hours in total. Also a lot of people couldn’t attend. That was too bad.

Never fear: We’ve spent the last month redoing the entire session. We’ve put together countless videos that walk through almost every part of the session (I did skip some of the mistakes I made during the actual training session 🙂 I did make some new ones. Don’t worry. ). Anyone now can ‘attend’ the session by reviewing the following pages and information and following the videos and downloading the playground file.. This is good. There are videos that describe what we did in the session (sans the mistakes).

You can now watch the FileMaker and JavaScript training session at your leisure. You can rewind, fast forward, skip, and pause the videos as you work through the examples. Isn’t that awesome?

You can view the entire syllabus here as well as get the training session files. And here’s the details about each of the groups of videos.

The Basics of JavaScript (inside FileMaker)

There are 27 different exercises in the JSPlayground file to learn some JavaScript. This wasn’t a masters course in JavaScript, but the exercises that we went through represent the type of JavaScript that we might use in FileMaker.

Go through the exercises, follow along with us as we explore some JavaScript.

Oh, and there’s plenty of resources available in the file. Review this video to learn more about the JS Playground file.

Setting up an Integration

In the next section of the training session we worked on integrations. We explored how to take a JavaScript library and set it up to work with FileMaker data. We also customized the Integrations.

We spent our time on C3 JS and the DataTables library. It was a good time, and we walked away with some good sense of how to work with any JavaScript library.

Work with the FM WebViewer Bridge

In the final hours of the session (we were pretty brain-shot), we took a look at how to work with the FileMaker WebViewer Bridge. We saved the best for last. The functionality of this API works like magic and solves a lot of web viewer problems.

We spent our time working with DataTables and the C3 Charting library (yes, the same ones as before).

We did, however, start by looking at a cool progress bar.

In these videos we explored how to write FileMaker scripts that trigger JavaScript functions which call the library’s API methods to change the web viewer’s state without the refresh.

You can also get to the DataTables and the C3 examples we used with the Bridge

A Few More Notes

  • You need to download the FileMaker and JavaScript Training Session materials. You can find those here.
  • As you work through the videos you might have questions. Please reach out at and we’ll be glad to help you through what you need.
  • We are thinking of offering a webinar where we can work together on some of the items from the training session. Please let us know if that would be useful to you.

Virtual FileMaker and JavaScript Training Session

Have fun. Let these videos help you pretend you attended the FileMaker and JavaScript training session. Explore FileMaker and JavaScript. Explore and see the power of JS in FileMaker (JavaScript is, of course, native to FileMaker). It is completely possible for you to learn and use JavaScript. So come along with us, will yah?

In about a week, I’ll be presenting at FileMaker DevCon on two topics related to the Workplace Innovation Platform. As part of those talks I am going to be talking about Custom Application Networks. In this post, I’m going to introduce Custom Application Networks and talk a little bit about what makes the FileMaker Workplace Innovation Platform so good at building them.

Bridging the Gap

In FileMaker’s recently released white paper on the Workplace Innovation Platform, the authors list five reasons you should invest in a Workplace Innovation Platform; number two is: “Bridge the gap between appliance apps and enterprise systems.” If you look around you’ll see it isn’t just enterprise applications that need bridging—it’s the dozen SaaS applications that most business now use as well.

Companies today have a mishmash of apps and services that they try to string together into some kind of cohesive whole, but duplicate data exists in many apps. Information needs to move from one application to another with custom transformations unique to business processes, and somehow they need to extract valuable business intelligence.

Who designed this mess? How did we get here? Wouldn’t it be better just to build a big monolithic application so we could avoid the chaos?

It’s the Economy, Silly

Well, it’s the API Economy to be specific. As more and more applications and services get added to the network through APIs, they all get more powerful. They get cheaper to build and maintain, they get easier to sell, and they generate more revenue. This is a classic example of the network effect.

It didn’t start out this way. When the first SaaS apps where released 10 years ago, they weren’t very good, but they were affordable. I used to joke that SaaS applications were the fast food of the software industry. They were cheap, satisfied a craving, and were available everywhere, but if you lived on them they would kill you. That said, over time these apps improved substantially.

Just getting better wouldn’t have been enough fo them for them to transcend the fast food category—the internet as a whole got better too. Internet Explorer was killed off. JavaScript become the dominant programming language, and developers settled on REST or REST-like APIs with JSON as the payload. Suddenly these applications could talk to each other. Platforms like Zapier were born which focused solely on connecting SaaS applications.

Now we have applications that are improving at an ever-quickening pace, they can interoperate efficiently, are drop-dead simple to try out, and relatively inexpensive if you consider all the costs of building the functionality on your own. Add this up and you have an economic incentive so compelling that companies start using more and more of these apps without even really knowing that they are doing so. At first slowly, and then quickly, companies begin to assemble custom application networks.

Custom Application Networks and Innovation

Now, many companies have many SaaS applications that they rely on. They are maybe partially integrated using Zapier or other custom code. Each company has a different set of applications that are connected in different ways. The “Custom” part of the solution has moved partially out of the custom application and into the network layer. It is the unique collection of apps, connected in a unique way that defines a “Business System.” This a Custom Application Network.

Look closely at what this Custom Application Network does—it runs a business. If it isn’t working well, the business isn’t working well. If it’s too rigid, the business can’t adapt. If you can’t change, you can’t try new ideas. If you can’t try new ideas, you can’t innovate. Suddenly, the health of this Custom Application seems pretty important.

Custom Application Networks
Custom Application Networks mimic the organization of human brains and neural networks

Build vs Buy

As a brief aside, I want to make it clear that custom software development isn’t going away. We still need to build things that are unique for our businesses. There will be apps to build, dashboards to build, custom integrations to build, and APIs to build. The incredible opportunity is that now we get to build more of what really matters to our businesses—or for our clients—and less that doesn’t. Anything that is essential but provides no competitive advantage can be purchased and integrated. So the answer to the old question of “should we build it or buy it?” is “both.” You’ll buy and you’ll build, but you’ll just get to build more of what matters. Almost everything you do will be connecting in some way to a Custom Application Network.

Back to the Future

If you’ve been paying attention, you will note that there are some problems with this arrangement. The Custom Application Network was probably designed over time, and without a game plan. Data is spread across many applications, and the flow between the applications is not great. You can’t see the data you need to see when you need to see it. This feels remarkably like the beginning of my career.

Back in the 90’s and early 2000’s, building business software often meant translating paper-based systems into databases. Collecting and organizing everything, creating reports, crafting finds, and writing scripts to get these data to flow from form to form or table to table. Now we have a similar situation, but instead of data existing in a bunch of filing cabinets on paper or maybe excel spreadsheets, we have it in separate applications. Fundamentally the goal is the same: organize these data, get it to flow where it needs to be, make reports and charts, and design data in/out forms. How we do it is different, but the end goal is the same. Back then, we were creating databases that were shared over the LAN. Now, we are creating Custom Application Networks that might reach around the world.

Workplace Innovation Platform

Let’s consider the basic set of capabilities you need to keep your Custom Application Network going. Whatever tool you use, it will require the use of REST APIs to create custom data flows between SaaS applications. It will need to be able to create web, mobile, and desktop apps. It will need to have a database component. It will need to be easy to get started with, and powerful enough to build pro-level applications. It would be great if it offered escape hatches through a plugin API and integration with JavaScript. Where can we find such a tool?

If you accept the premise that healthy innovation in a business is tied to the business’s Custom Application Network, it’s really no surprise that a Workplace Innovation Platform tool like FileMaker would provide these capabilities. Business Innovation is managing, building and maintaining the Custom Application Network. Even if you are only building a small custom application for your company, it is almost certainly going to need to plug into the network at some point, and so your custom app will be improving the health of that network.

FileMaker has all of the capabilities I outlined above. I am not aware of any other tools out there that have the full stack that FileMaker has, making it the perfect platform for building part, or all, of your Custom Application Network.

It’s Not That Hard, but it is Different and it’s Getting Easier. Oh, and it’s Worth it.

Many of you are probably thinking, “Ok sure, but integration is not easy. The Custom Application Networks that you advocate are a sort of distributed database system and that is more complicated than building everything in one system.” This is true to a degree. It was certainly true in years past, but I don’t think it as true today. The tools for integration are getting better, and best practices and patterns are emerging that will help us reason about these problems.

Also, it is undeniably worth it to make the effort. Once you begin to build systems in this way, you will begin to feel how much more robust, more flexible, and less risky your system is.

The Opportunity

It’s hard to overstate the opportunity presented by the Custom Application Network. Every business of any size is creating one, whether they know it or not. If you’re a business owner, understanding your network will help you decide what to build and what to buy. If you’re a custom app developer, every company has technical challenges, which you have skills to solve. If you’re a vertical market developer, understanding how to fit your app into your customers’ custom application networks will help you decide what features to build and what to leave to the network.

The Geist in your Business Innovation Machine

At Geist Interactive, we have a methodology we use to work through the Custom Application Network’s opportunity. We call custom application networks that are built with intent “Business Innovation Machines,” for what I hope by now are obvious reasons. If you’re curious about this, and wonder how it might help you, please reach out. We’d love to be the Geist in your Business Innovation Machine.

More at DevCon

Custom Application Networks aren’t the only thing I’ll be covering at my two talks at DevCon, although it will make up a substantial part of my first talk. The other presentation will be about where I think we’re headed in the next few years. I hope to see you there.

The topic of FileMaker tests is important, to me and to clients. I want to make sure my scripts work, and my clients don’t want bugs. For DevCon 2018, I put together a session about this very topic in the hopes of sparking the conversation. The recorded sessions from DevCon are now available online. Here is a link to my session on Building Testable Applications.

Introducing a new topic

In preparing for this talk, I did a fair bit of research on software testing. It became obvious early on that software testing has a lot of depth & breadth, so I wouldn’t have time to cover any other frameworks in the session in one hour. I was also grappling with the fact that the FileMaker community seems to have limited discussion on testing.

I decided to aim my session on talking about what FileMaker tests can do and prove testing’s worth with some live examples. My talk easily could have spanned two hours, so there are a few places where I had to gloss over key topics. I barely touched on modular scripting, the reason to use custom functions, and pre-conditions for testing. We will address these at some point–they play a vital role in building FileMaker tests. My goal was to pique interest in testing in the FileMaker community.

Why test?

The first few minutes were focused on why we should write tests for complex business applications. Any developer that has implemented changes on a complex system already knows the answer: we need to STOP BREAKING CODE!

Fair enough…on to the hard part. How?

Factors to Consider

As you design a testable custom app, you need to consider these factors and use these tools. At first, these ideas might seem foreign, but the more you work with them and engage with them, the easier it will be to work with these in the future.

Designing a system so it CAN be tested

Modular scripting is the vital first step to creating testable applications. If you have a piece of executable logic that should accomplish a specific function, you need to test that one function. However, if you have “spaghetti” code, functions are often times occurring in multiple locations, operating from a different context, or performing multiple discrete pieces of logic in one script. Instead, make your scripts modular and stay DRY. That’s the first step to enabling testing.


Every discreet piece of logic should not only accept a script parameter that is JSON, but it should return JSON as well. Error objects come back if there was a problem and a result object comes back if everything worked. This means you have a modular script that can be given a payload and return results. And JSON is the way to go. Trying to build a complex payload using anything other than JSON introduces you to a world of hurt. You’ll be working with a lot of data and will have to find some way to keep it organized.

Custom Functions

Geist Interactive has released custom functions on Github. We have repositories for handling JSON validation and errors, and analyzing test results. Even if you aren’t adopting testing yet, go get the other custom functions now. It’s amazingly helpful to handle parameters in a meaningful way.

My examples

The following examples contain simple-to-advanced examples of what we mean by testing. Take a look at each one and pick out the above factors in each example.

The simple one

My first example was as simple as anything could be. I had a script that multiplied a number by 2. Amazing, right? This file isn’t about what it does, it’s all about how it does it. If you follow along in the video, you’ll get a good sample of how to separate scripts based on Interface scripts & Controller scripts. The controller script is testable, the interface is just what calls on the logic.

Purchase order sample

I released a purchase order example that is probably the best thing to take from my session. The file is a good dive into a simple solution that’s pretty intuitive. You just need to turn on script debugger and follow the code. You’ll learn in no time how we manage to create records using a controller.

Once you’ve got a grasp on that, open up the test file, and start writing your own tests. I dare say it is the best learning tool so far! I’d recommend imagining customer requests, changing the code, and writing tests. Then change the business logic, write more FileMaker tests, and you’ll get a feel for how testing can (or can’t) solve problems for you. As your solution gets more complex, you’ll need more tests, but it doesn’t really get more difficult. If you can implement a change to your code, and write tests to support it, you’re good!

We practice what we preach

Along with the custom functions and our work on modular FileMaker, we put this testing concept into practice.

Karbon Tests

As most people have heard by now, Geist Interactive released Karbon at DevCon. This is the most complex solution that is publicly available with tests integrated. If you’ve mastered the Purchase Order Example, feel free to give it a shot here as well.

Testing Generator

Writing tests can be monotonous. You are declaring a case, subject, payload, script, and Assert functions for each test. Where code is predictable, we don’t write it, we generate it. I released a generator file as well, that can generate a template for your testable scripts. Feedback welcome!

Long live FileMaker Tests

Since DevCon, I’m a few inquiries about testing. There are a few folks out there that are interested. I hope more folks adopt a testing model for their custom apps.

It might take some time before everyone starts using this, but I’m convinced our community will become more interested in testing over time. One issue is that testing has pre-conditions in your solution, so if scripting isn’t modular, you aren’t ready to start testing. I’ll keep telling myself that’s why I’m not getting questions. Everyone is just re-factoring code to be modular…that’s it!

What’s next

There are some interesting opportunities for test generation. We released Karbon_Generator, which is a developer tool to generate Controller Scripts. Because there are things known about your code, we should be able to produce scripts to test any other scripts. There’s a lot to iron out, but maybe by DevCon next year!