If you want rich interactive charts in your FileMaker app, you are going to need to go beyond the built-in FileMaker charts. Luckily, the FileMaker Workplace Innovation Platform has escape hatches you can use to get just about any job done. In this post and video, I am going to show you how to make FileMaker Interactive Charts with the maybe the most powerful escape hatch in the professional Filemaker developer’s toolkit, JavaScript!

Why Not Just Use the Built-In Charts?

The built-in charts that come with FileMaker out of the box are fine.  They work well and look pretty good. But they are static. There is no animation and they don’t respond to clicks. There isn’t any way to drill down into data sets or otherwise explore the visualizations. Also, data visualization goes way beyond whats provided by the built-in charts.  If we need that extra innovative experience in our apps then we reach for the JS.

FileMaker Interactive Charts

We’ll need some JavaScript and a charting library. We’ll use C3 for this demo. The C3 Charting library is a built on top of D3 the most popular data visualization JavaScript library on the planet. It provides a lot of functionality and a lot of customization possibilities. Take a look at this video to see how to set up the library in your custom app

Oh, and download the files here to follow along.

FileMaker C3Charting

The video is about 45 minutes long. Here’s a breakdown of the sections:

  • 00:00–Setup
  • 17:40–Customization
  • 31:33–Handling Clicks
  • 40:41–Dashboard Possibilities
In which we walk through how to set up the C3 Charting library into a custom app. Sections: Setup: 0:00 Customizing: 17:40 Add Click functionality: 31:33 More than One: 40:41

Some notes

Completely customizable

FileMaker Interactive Charting gives us complete control of the chart. Here’s a partial list of elements we can control:

  • The type of chart
  • Displaying two types of charts in the same graph.
  • The labels and their format
  • The x-axis categories, their display format, and the number of ticks.
  • The y-axis placement (left, right, or both)
  • What happens when you click on or hover over a data point.
  • The colors of each line or bar or pie segment
  • Whether or not grid lines are drawn in the graph

It’s incredible what we can do, and it is fairly easy to set up.

Takes some time

FileMaker C3Charting does take some time to set up, but it gets easier the more times you do it. There’s the data structure and the library files code copying. You have to write in the customization you want and so on. There’s a lot to do, but that’s okay. It is worth the time to get the chart exactly how your client wishes it to be.

FileMaker Interactive Charts

Dashboard possibilities

With a Web Viewer and with this charting library, you can set up a dashboard. More than one chart can be visible, each chart having different properties. With this library, a dashboard is easy to generate.

We will revisit this

FileMaker Interactive Charts requires a lot more discussion, so don’t think we are done with this discussion. In a future video, we’ll explore how to use JSON as the data that drives the chart.


The C3Charting JavaScript library is great Pro tool to add to our tool box when we need to go out that escape hatch and get the job done.  In this case, we made some awesome FileMaker Interactive Charts. We’ll continue our study of JavaScript that we began at DevCon. Please join us in the SLACK channel, and we’ll talk about these. And stay tuned to our site for more integration videos.




In the DevCon 2018 training session on JavaScript, we took a look how to integrate various JavaScript libraries into FileMaker. We only got through one, and I’m sure I went pretty fast during the remaining minutes to make sure that I at least completed it. I might have lost a few folks. 🙂

But that’s okay. No DevCon Attendee left behind!

The week after DevCon I began to record videos of how to do the work. My plan was and is to work through each integration and walk through how I’d do the work.

So here’s the first one.

DataTables in FileMaker

Here’s the files for you to try out.

In which we talk about how to integrate the DataTables JS library by looking at the set up, styling, functionality, and some options. https://www.geistinteractive.com/2018/08/24/using-datatables-in-filemaker/


This video is long. It’s 53:00. So I broke it up into a few sections. Check out any of the sections in which you’re interested. (But, it’s good to watch the video in whole).

  • Basic Setup: 0:00
  • CSS Styling: 30:38
  • Functionality (adding the row click): 38:20
  • Table Options: 51:02.

Some Thoughts

It’s a fairly speedy process

I’ve done this enough that I can set up an integration in less than 20 minutes. I usually export all the code from a previous project or a practice file, so that makes things go even faster. And with more practice, you will get even faster. One DevCon attendee reported to me that he thinks it would take him 10-15 minutes to do another integration. The set up I’m advocating is simple. It’s fields and tables. That set up works for now.

Styling can take some time

The hardest part of this is styling it. You have to get down into the nitty-gritty of the CSS and adjust individual items. In the above video, I talk about it a bit, but this will require some more study.

The default library is a good start

DataTables comes complete with a full set of functionality. Once you install it into your custom app and load it with data, you can sort by columns, do filter-as-you-type, and adjust the number of records showing. There’s no additional scripting or buttons or tricks; just use what the (very well tested) library provides.

Alt ways

I’m suggesting one method here. But there are others, and we’ll discuss those in the future.

There’s one more method for using DataTables in FileMaker. For all my talking about using JavaScript in FileMaker, I’ve got a config file that will allow you to set up an integration without knowing any of the underlying JavaScript. Check that out here.


DataTables in FileMaker is one way we can innovate in FileMaker. We can provide a professional set of functionality to our clients. This functionality may not be needed for every list or portal. However, if the client asks that related records are sortable and searchable, we can turn to this library for complete help.

We’ll continue our study of JavaScript. Please join us in the SLACK channel, and we’ll talk about these. And stay tuned to our site for more integration videos.

Download the source, start file and finished file here.

Training Day at DevCon 2018 finally arrived, and I was ready. After fretting over my ‘lesson plan‘ for so long, I was ready to do some FileMaker DevCon JavaScript training, for FileMaker developers. So I left the breakfast room and entered my classroom. I was hoping to get some moments of calm before we started. To clear my head, to focus on the material at hand.

I walked in the room, and there were like 20 folks there. “Woo,” I thought.  I got them started on some ‘morning work’ to prepare for the time.

A few minutes later, there were over 60 people in the room., still barely 45 minutes before the 8:30 AM start time. I handed out more USBs.

By 8:30 am, the start time, folks were ready to learn JavaScript. A lot of them.

The JavaScript worm

Slowly but surely, JavaScript is becoming more present in FileMaker developers’ minds. The training session brought in over 150 people that think about JavaScript. These folks are interested in the power of JavaScript, in the fact that it is easy to learn and use. We are intrigued by the possibility that we can develop interactive charts or include a whole set of functionality in just a few minutes (maybe an hour at the most). We recognize part of making our custom apps innovative for the workplace is to use all the professional tools available, including JavaScript.

There’s a season for everything

I’m not the first to advocate for JavaScript in FileMaker. Many folks have come before me and have said the same thing. I rest on their shoulders. But now, it seems, is the good time to really explore what we can do with JavaScript (almost anything) in FileMaker. We get a glimpse at what we can do with the language. The time is right; let’s keep moving forward.

Many of the people & compaines who’ve contributed to my knowledge of JavaScript and the Web Viewer.

In the session

Focusing on pure JavaScript, we studied how to work with the Web Viewer.

For a very quick three hours, we took a look at JavaScript in the form of pure JavaScript and in the form of JavaScript libraries.

JavaScript, pure

First, we did a very brief study of some JavaScript concepts. I believe we all should know a little bit of the language so that when we want to do something in a library or in a blank web viewer, we have the knowledge to achieve it. So we spent time on pure JS, writing functions that added text to the web viewer or changed the color of a background. We built buttons in the web viewer and attached events to them. We learned a bit about variables and scope and functions.

JavaScript Integrations

After the break, we turned to JavaScript libraries, the fun part. Together we walked through how I have set up working with libraries to integrate into our custom apps using FileMaker data. We started with a chart and set it up, talking about that set up and how to customize the chart. The concepts we practiced in the first half helped us out here.

Along the way, I got to work with individuals and help them through very common mistakes (a missing comma or semi-colon). I also spoke about JavaScript concepts such as variables and scope and functions.

It was quite unfortunate that we didn’t have a full day to do this work. I wanted to spend more time on pure JavaScript and on how to integrate libraries. We completed 9 out of the 25 exercises, and only got to review one out of the eight integrations. But not all is lost. See below for more info on a plan.

I encouraged folks to sign up for the FM/JS SLACK group we started up a while ago. And many folks did. That’s one of the ways we’ll stay in constant contact throughout the next year.

Beyond the session

People left the session excited about using JavaScript. Many people approached me saying they see it as much more accessible now that we went through it. They were inspired to begin to use what we did in their own apps. That’s very cool. My goal has always been to excite FileMaker developers about JavaScript.

During the week of DevCon, at least two people continued the training session by working on an integration. Phillip Jaffe worked with the DataTables integration, and Logan Cornelius worked with the C3 Charting library. Through text messages or on SLACK or in person, I worked together with them to get their libraries integrated and to talk about the nuances of the library. We met at the Geist Interactive booth or in the hallway to get it worked out. Both attendees got their work done by the second day of the conference. Logan reported it took him about an hour to get the charting library working with data from his app.The rest of the week he tinkered with it, changing colors, adding options. 

I could tell he was excited about the work he did. And so was I.

Continuing the session

Lest anyone think they’ve heard the last of the session, we have a lot in store in the upcoming year. We want to keep this conversation going and inspiration hi, so we will do something with JavaScript every month leading up to DevCon 2019!. Here’s a list of what we’ll do and how you can participate.

  • On the FM/JS SLACK group, we’ll talk JavaScript and how we’re using it in our apps. It’ll be a great casual conversation. Please join and get in on the conversation.
  • The JavaScript training materials are found here. Download those and try them out.
  • I’ll do videos for each of the exercises in my JSPlayground file, and will set them up on a JavaScript-dedicated webpage.
  • I will do a ‘let’s integrate’ video for each of the integrations found in my session files. You can watch and listen as I work on one of these at a time.
  • As logistics allows, I’ll talk JavaScript at user groups throughout the community. Todd and I will be at the west coast user groups (Portland, Seattle, FMDIG, FMDisc, and San Diego) in October to talk JavaScript and other professional tools.
  • Occasionally we’ll do webinars on JavaScript and JS integrations. We’ll alert you in plenty of time so you can plan to attend.
  • And of course, I’ll suggest using JavaScript in the forums. I’ll be the first to admit not everything is a hammer (not everything needs JavaScript) but where it is a viable option, I’ll suggest and provide a sample file.

Join us for any of these events. We’ll take the next year to learn JavaScript and how it can be used in our custom apps.

Filemaker Devcon JavaScript Training

The future of FileMaker and JavaScript is bright. We will continue to promote its use and inspire folks, and I hope to work with others in the community to do the same. JavaScript is one of the many professional tools FileMaker developers can use to innovate.


In less than a week (as of Monday, July 30), I will work with FileMaker developers to learn, or get started learning JavaScript. I can’t wait. While I’m nervous about it, I’m also pumped that we get to talk the power of JavaScript and the power of the web viewer. It’s been my life’s goal (for the past 4 or so years) to get FileMaker folks excited about using JavaScript. We get to take another step in that direction. JavaScript is easy, it is powerful, and it is part of native FileMaker.

If you’ve not yet registered up for the training day (an additional cost), I encourage you to do so. I know it’s an investment. So to make sure your return will be adequate, I’ve described in pretty minute detail what we will do during the morning (there are other great sessions in the afternoon). You can check out the outline here. And you can review this video.

DevCon 2018 is coming up. In this video I walk through what we will be up to. https://www.geistinteractive.com/2018/07/30/devcon-2018-javascript-for-filemaker-developers/


The Highlights

On our minds

As we wrap our brains around JavaScript, we’ll keep in mind two questions:

    1. How does our current understanding of FileMaker help us learn JavaScript?
    2. What are the benefits to using JavaScript in our FileMaker development?

In education, these are called “Essential Questions”. These are vital mainly to our adoption of JavaScript as a viable tool in our FileMaker development, and they keep us grounded. As cool and powerful as JS is, we need to remained focused on our client’s data and custom app and needs.


We will spend most of the time in the session:

  • Working with pure JavaScript. We’ll write little functions that accomplish something for data presentation in FileMaker or data manipulation.
  • Exploring how to set up using JavaScript in any environment, for any custom app.
  • Implementing and customizing current JavaScript libraries out there for our use.

I’ve got quite a few files for us to work with. Here’s a few screenshots.

We will spend a lot of our time in here. writing functions that display our data in interesting ways.

We will spend a lot of our time in here. writing functions that display our data in interesting ways.

This file is a reference for what is known about the web viewer object

An example integration we’ll implement.

Join the JavaScript revolution

I encourage you to sign up for this training session. The more FileMaker developers that know and use JavaScript, the more the movement grows and the more awesome custom apps get delivered to clients.

Join me August 6, 2018 at 8:30 a.m. at DevCon 2018 to begin the JavaScript journey.


Lance Brandenberg, Solutions Architect here at Geist Interactive, will present a session title “Testable FileMaker Custom Apps”, focusing on FileMaker testing.

He is a first time speaker at DevCon, and we’re excited that he is another voice in the ‘testing-in-FileMaker’ conversation. He hopes to jumpstart the topic again and get folks talking about it because, as he will argue in his session, FileMaker developers have more of a need to rely on testing.

His session is Wednesday, August 8, from 1:00 p.m. to 2:00 p.m. Here are the details:

Session Description

With the release of FileMaker 16 and native JSON functions, it’s easier than ever to create testable FileMaker apps. We will walk through a simple example of what testing is, and how it can improve your solutions. Most developers have had situations where they need to alter some existing logic, and are concerned that they might alter something with unforeseen consequences. Wouldn’t it be nice if you could ensure that your changes didn’t break existing code? Welcome to FileMaker Testing.

Recommended Background

How to write modular scripts, trapping for errors, and some experience with using JSON objects.

Session Objectives
  • What is Testing?
  • How to write testable scripts
  • Benefits of testing
  • Custom functions needed for testing

To get a better understanding of this topic, I sat down with him over RingCentral and asked some questions. Catch the video here of our interview. You can also read it here.

In which Lance Brandenberg discusses his session titled "Testable Custom Apps" https://www.geistinteractive.com/2018/07/20/filemaker-testing-devcon-lance-brandenberg/

Here’s our conversation in written form:

Q: Who are you? What experience do you have in FileMaker?

A: Lance is a Solutions Architect at Geist Interactive. He’s been working in FileMaker since 2006. He stumbled into the platform while running a screen-printing business. Like many of us, he decided to get out of that game, selling the business in 2011 to become a full-time FileMaker developer. He’s in San Diego, and really enjoys working at Geist Interactive so that he gets access to the cool tools that Todd and the company have developed.

Q: Describe your session.

A: Lance’s session “Testable FileMaker Custom Apps”, on FileMaker testing. Building FileMaker solutions so their testable is interesting. There doesn’t seem to be a lot out there in the FileMaker space, so he’s excited to start that conversation. There’s a lot of ground to cover: modular scripting, custom function libraries. For attendees, you’ll see the benefits of testing and some live coding to see how to build these tests. (Lance will be brave and live-code!).

Q: Why is FileMaker testing important?

A: Remember the game “Wack-a-Mole”? It’s extremely close to how we develop in FileMaker in complex apps. We develop a new feature, and that has the potential to break something already working. Lots of feature requests means we need to test more, and we then need to develop a robust testing methodology. It’s possible we don’t test enough since we do have the rapid-application-development platform, but we really need to.

Testing allows you to build more durable solutions. If you write a test a year ago, and you add a feature today, you should be able to run the test causing nothing to break. We don’t have to worry when we deploy that something’s going to break. If we rely on tests and new tools that we have such as the Data Migration Tool.

It is not simple to test, but it is highly worthwhile. Testing is specifications in code. Scripts that run tests are run by anyone.

Q: What is a tip or trick that you’re going to demonstrate in your session?

A: Lance hopes to have a FileMaker Testing Generator file built. It is similar to our Generator file. A FileMaker developer can create a test using script comments written in a standardized JavaScript form. Test-writing seems boring and challenging, tedious. Lance’s Testing Generator file will help write tests a lot quicker with no mind-numbing work to do.

Lance welcomes anyone to continue the testing generation idea.

In all of software development, testing is complex. We have to be aware of what testing can achieve, and we also should test everything we can anticipate.

Q: Does the person who develops the code also test?

A: The best way to produce tests is the developer who makes changes or creates new features. She knows the system inside and out and knows how the app should work.

Q: Is Testing different than QA work?

A: Yes. A QA person is operating like a user, doing some user testing. What Lance will talk about is more analogous to functional testing. Lance will demonstrate with a purchase order system where a developer is adding new features and how to add tests to accommodate those new features.

Q: What materials will be available?

A: Lance has three libraries on GitHub libraries: JSON Validations, a custom-function library, and an error tracking library. These are all FileMaker custom functions. Lance will also include the starter file upon which he will do the demo. Finally, he’ll have references to documentation on such things as JavaScript standards and his Testing Generator library.

Q: What are modular scripts?

A: There are a few sessions at DevCon this year. Todd will speak of Modular FileMaker, and John Renfrew will speak about Modular Programming. These modular scripts should be a must-attend session. Modular scripts are, in essence, scripts that perform one function well. For example, you can build a script that returns the end date of an event if the script is given the start date and the event length as a parameter. Inside this script is the logic that will return the correct end date.

Q: How much JSON do you, Lance, use in your daily work?

A: Every project Lance work on uses JSON primarily to pass data around. JSON makes modular code easier. Each script has to receive data and return data. The chunks of code (in the form of JSON) make it very easy to work. Lance will always use JSON.

Q: What is something we could know about you that has nothing to do with FileMaker:

A: Lance will be a dad in December.

Lance’s session, “Testable FileMaker Custom Apps” is Wednesday, August 8, from 1:00 to 2:00. Check it out. It will be a good one.



To celebrate DevCon 2018, the newest release of the FileMaker platform, and all things JavaScript, Geist Interactive is pleased to begin a contest called GoCreate, where you get to go wild and show off your most unique use of GoDraw3.
Use all of the power of GoDraw3 to create a unique user experience to solve a particular use case. Read all about GoDraw3, but here are some things you might want to consider:
  • Any of the tools and functionality can be removed or customized.
  • The app is simply FileMaker. Use all of your knowledge and skills of FileMaker.
  • Tagged objects can be used in some awesome way.

Who can get involved:

This contest is open to anyone attending DevCon 2018 of any skill level. Since GoDraw3 is simply FileMaker, anyone can participate; no knowledge of JavaScript is needed.

Here are the details:

  • Use the fully-functional trial version and use that for your implementation.
    • Note: the trial version includes a watermark image. Ignore it.
  • Contest Date range: Now through August 9 at 8:00 a.m.
    • Feel free to work on it now!!! Get Started.
    • Or wait until DevCon.
  • Where: DevCon 2018. You must be a DevCon attendee to win.
  • Winner announcement at 3:30 p.m. on August 9.

Here’s what to do:

  • Download the trial version of GoDraw3 and create a unique implementation of it. Be creative. Create something that would work for any of your current work, or go wild and dream beyond your day job.
  • Email a link to your project to support@geistinteractive.com.


  • You must use GoDraw3 in your implementation.
  • You can use any part of the FileMaker platform including FileMaker 16 or 17 to create your design.
  • You can design it for FileMaker Go or FileMaker Pro Advanced. You’ll let us know which device it is meant to be on.
  • Your work must not contain any real customer data.
  • You are limited to one entry per person.
  • Your work will only be considered if you’ve emailed a link to your project to support@geistinteractive.com.


A team of independent FileMaker developers at DevCon will judge each entry, scoring your submission as they reflect on:

  • How clever of an implementation is presented.
  • How does the submission ‘feel’?

Granted, these are rather subjective, but we’ll do our best to make it fair.


You can get support and questions answered in the following ways:

We will be available to answer specific questions about GoDraw3, not about how you can implement it. We want to see what you can do! 🙂


GoCreate! Using FileMaker GoDraw for something awesome

We’re excited to see what you create with GoDraw3.

Terms and Conditions
  • You only officially enter the competition when you have emailed a link to your project to support@geistinteractive.com.
  • All submissions become property of Geist Interactive and will be used in promotional materials. We will credit the author.
  • Submissions have to follow the rules as set out above.
  • All entries must be submitted by August 9 at 8:00 a.m.
  • Geist Interactive have the right to remove any entry at their sole discretion.
  • Objectionable or offensive content will be disqualified.
  • The competition will be judged by an independent panel of FileMaker Developers from the community. The top three will be selected based on creativity, unique implementation of GoDraw3.
  • The winners will be announced at DevCon at 3:30 p.m. at the Geist Interactive booth and by email.
  • The winners have 7 days to respond and claim the prize; if no response has been received after 7 days, you forfeit your prize.
  • Geist Interactive reserves the right to exchange any prize for a prize of similar value.
  • The judges will be selected from folks outside Geist Interactive. 

You know me. I enjoy working with JavaScript. I learned it from my context of a FileMaker developer, and I think everyone can and should consider using it in some aspect of their work. We all can adopt a FileMaker integration. This year I’m lucky to teach a training session at DevCon, where I’ll guide people through the basics and how to apply it to their work. While not every answer I give on the forums is about some JavaScript integration, I do promote it where applicable.

The time barrier

But I do realize that there are barriers to the language for us FileMaker people. I asked a question about this a couple of weeks ago. Most people responded with ‘time’. They simply don’t have time to learn the language. I think that is more of a perception than reality, but I acknowledge that idea. My training session will work to break down that barrier, by the way.

Because of this perceived barrier, I want to give folks a way to use JavaScript integrations without actually knowing JavaScript. How you ask? Well, this goal is accomplished by a cleverly-created FileMaker file: The DataTables config file. Let’s take at this barrier-smashing setup.

Here we take a look at how to set up a configuration for the DataTables JavaScript library inside of FileMaker. A few clicks, a few choices, and you've got all the code you need to implement this library into your custom app. https://www.geistinteractive.com/2018/07/09/use-javascript-without-knowing-javascript/

Introducing DataTables Config

The goal of this file was to give anyone the ability to implement the DataTables integration into their custom app. And the DataTables JavaScript library provides a heck of a lot of functionality for list views or lists of related records with no additional coding. You can set up a web viewer that shows related records with column sorting, go-to-related-records, column or row colors, filtering, etc.

DataTablesConfig.fmp12 is a  FileMaker file that simply generates the JavaScript needed for the integration after the developer adds or removes functionality. Here’s what it looks like.

I’ll say it again. This config file lets you set up the DataTables integration without messing with the JavaScript. After only ten minutes of setting it up, the above configuration produces this:

Gettin’ you hooked

This config file is meant to be a gateway drug into using JavaScript. Once you try it out and see how much functionality it adds to your custom app and how easy it is to set up, you’ll be interested in diving into the JS code. I guarantee that. You’ll want to look at the JS code (it really is just text) that makes this all happen. You’ll find it is easy to read (JavaScript is easy to read) and you’ll be inspired to mess around with it, to change something to see what happens. And in this case, no one gets killed by the curiosity. Mess it up, you can use the config file to revert back.

You’ll be hooked on JavaScript, and then you can continue to learn more about the language. We at Geist Interactive will guide you along.

Features of the DataTables config file

There’s too much to explain in detail here in a blog post, so be sure and check out the video that walks you through the app. But here are some highlights of its features.

  1. DataTables comes with a lot of default features and options. If you don’t want to customize your implementation, you can generate the default code quickly.
  2. You can add or remove features and options using the FileMaker data fields and UX provided here.
  3. There are detailed examples of how to format the text you wish to put in. For example, if you choose to have your default table sorted by column 3, you can choose the ‘order’ option and then pass to that option the following text: [2, “asc”] (this is a 0-based index). That’s easy enough to type, don’t you think?
  4. You can add additional extensions to your implementation, functionality that makes the integration more complex. Such as something that looks like a sub-summary report (grouped records) in little time.
  5. There’s plenty of help and descriptions of the features.
  6. You can (and should) map your fields to this config, and you can describe how each column should behave.
  7. You can add a callback function (Run a FileMaker script when you click on a row) and even assign a column to use in the search.
  8. You can set this file up to be a module, a separate file next to your custom apps and link to it. This action allows you to use the code stored here to display the data.
  9. Give some basic custom styling to the table.

There’s so much more that can be done, and we’ll explore Extensions, custom CSS, and calling FileMaker scripts in later posts and videos.

FileMaker Integration: Give it a try

I strongly encourage you to give it a try. Play with it, mess it up, do all sorts of stuff to it and figure it out. I promise it will not take hours and hours (maybe one or two). It won’t be a huge drain on your life.

Download the free tool. Watch the video. There are some fine points in this, and it is best shown in the demonstration.

Feel free to reach out at jeremy@geistinteractive.com with questions if you wish. I can answer some questions, or we can set up an implementation package to do some custom development with this configuration in your custom app.

Let me know how it goes.





The FileMaker platform keeps getting better. The yearly release schedule gives us plenty to look forward to in new features, and the timeline gives us plenty of time to get to know what has been included. One of the new features is called “Default Fields”. We can now set up default fields to be created with each table in each file. There are plenty of articles out there already, and the knowledge-base article is out now. But I’ve seen some questions in the forums, sometimes the same ones. I did some research and put together the answers here. Let’s dive into FileMaker Default Fields.

Where are the Default Fields?

FileMaker 17 includes the default defaultFields.xml file in this location:

  • Mac: Applications/FileMaker Pro 17 Advanced/FileMaker ProAdvanced.app/Contents/Resources/en.lproj/DefaultFields.xml
  • Win: <drive>:\Program Files\FileMaker\FileMaker Pro 17 Advanced\Extensions\English

This is just the place to get the defaultFields.xml file. You shouldn’t move it. Just copy it and paste it to the proper location:

  • Mac: /Users/Shared/FileMaker/Shared/
  • Win: <drive>:\ProgramData\FileMaker\Shared\

Once there, you can open this file in a text editor (I use Visual Studio Code) and edit away.

How do we change the FileMaker default fields?

The defaultFields.xml file provided (and found in the location and placed in the location described above) allows us to make changes to the default fields. Here are some thoughts about it:

  • Start by making only a few changes to a field or two. Edit, save and see what happens when you create a new table. Get a feel for how the XML is written.
  • There’s a tag in the xml, near the bottom in the <tagList> tag, that identifies one of the fields as the primary key. Make sure that stays there if you plan on using addons in FileMaker 17 or any later version.

  • There’s a tag in the xml that identifies each of these fields as utility fields. It is found in the <TagList> tag: “#_FMI_0”. The 0 identifies it as utility. Remove it if you wish, but understand the (small) consequence of doing so (see below).
  • As you go to adjust a field’s xml, you can get immediate feedback by creating a new table in a .fmp12 file. If there’s any issue with the xml of a field, such as a missing ” or misspelled tag, that field will not be created. So give it a test.
  • If you’d rather not use FileMaker default fields, simply add a blank defaultfields.xml file to that shared location. This action prevents FileMaker default fields from being created.

How will default fields effect my development?

Using the FileMaker default fields can enhance our development in a small, but crucial way: You’ll create a table and immediately begin adding data fields to your system since these utility fields were automatically generated. Additionally, the following points illustrate more benefits:

  • We can add other utility fields by adjusting the defaultFields.xml file.
  • We can set this defaultFields.xml file up once and be done.
  • Every table will have common utility fields which record the basic necessities: primary keys, creation & modification user & timestamp.
  • We’ll never have to copy/paste the utility fields from one table to another. One less thing to worry about. I’m sure folks have forgotten to add these at one time or another.
  • Since these are utility fields, they do not get added to the layout automatically (as do fields that are created by you during the creation of the table) .
  • Utility field-creation is consistent across an entire team.
  • A field is identified as the primary key field which is useful for add-ons.

How do I add a certain type of field?

Many folks have asked in the forums how to create a certain kind of field. An amazing tool, by Salvatore Colangelo at Goya, allows you to create the fields you want for each table by constructing the defaultFields.xml file. The FileMaker file actually writes the xml of the fields after we make choices (name, type, primary key, calculation, etc).

Of course you can simply duplicate the xml for a field in the document and adjust it as necessary. By hand. That’s useful too.

But consider a very key point:

Every field in the defaultFields.xml file will be created in every table of every file you work with in FileMaker 17. So if we add a “FirstName” field to our defaultFields.xml file, that field will get created even in the Invoices or Dashboard or Inventory table we create.

Only a few

It seems to me there’s only a few fields that could always be a part of the XML file. We here at Geist Interactive want some fields in every table. Some other developers have more, some less. Here’s ours.

  • primaryKey // the primary key of the table. UUIDNumber
  • ModificationUser //autoEnter field
  • ModificationTimeStamp // autoEnter field
  • CreationUser //autoEnter field
  • CreationTimeStamp //autoEnter field
  • z_One_c  // a calculation field that returns a 1. Useful for relationships.
  • ModCount // a calculation field that counts the number of times each record has been modified

Remember, these are utility fields, so they server a utility and are not data fields as it pertains to the custom app.

New Feature, New Thinking

The FileMaker Default Fields feature is new to FileMaker 17 and it provides some possible glimpse into the future. We, as developers, can create FileMaker fields using XML, either by hand or using a tool. That’s an interesting thought.

You’re already using them if you’re developing in FileMaker Pro 17 Advanced, so embrace them and make them your own and be happy. They are here to stay.




FileMaker DevCon 2018, held in Dallas, TX, is fast approaching, and as always, I’m excited for the conference. It certainly is a highlight of my year, where I get to go and see old friends, make new connections and friendships, and revel in all things FileMaker. The conference is held in a fancy hotel, but they could host it in a Hotel 6 for all I care. Sure a huge pool is wonderful to sit at, but the more time you’re at a resort feature, the more you’re missing FileMaker stuff.

An amazing pool and view doesn’t make DevCon great, does it? (DevCon 2016, Las Vegas)

For those that are attending FileMaker DevCon 2018 for the first time, it will be a FileMaker-life-changing experience. You’ll meet folks, learn a lot, and simply be inspired by the excitement about the platform. Even if the community sometimes can be intimidating for few folks and a bit of a drag with complaints or laments of ‘missing features’, the experience of being surrounded by FileMaker stuff in person is exciting.

This guide is meant to help you if you’re new to DevCon. My first one was only seven years ago. Each year I remember what made it so great and try to continue those practices and attitudes. Let’s review how to make this first time an inspiring and fruitful one.

Don’t Mess With the Conference

Every year, FileMaker, Inc. puts on a fantastic conference, filled with people, cool FileMaker tips & techniques, products, free advice, great food, and a great location. Last year around 1600 people attended, so the conference is huge. I know people look forward to it.

DevCon 2016, Las Vegas

Tim Cimbura of LuminFire has a great write up about some of the facts about the conference.

Take advantage of every part of the conference. Get your money’s worth. Here’s some of how you can do this very thing.

Organization tips

  • Get there early to meet folks before the conference starts. I usually hang out in the registration area where I know FileMaker folks will be.
  • Check in soon after you get there. Each year we get some cool FileMaker swag. I’ve got four FileMaker bags and one FileMaker towel from my conference experience. We’ll also get a license key for the current FileMaker Pro Advanced version and some other items, including a vital accessory from Geist Interactive, a diamond sponsor of FileMaker DevCon 2018.
  • Make a plan of the sessions you wish to attend. More info on this below.
  • Scope out the session rooms. Practice the route to the rooms so you don’t get lost or have to consult your phone every time you want to go to a session.
  • Attend the Keynote. FileMaker DevCon kicks off at the keynote officially, and here we get to see FileMaker, Inc. and the folks there on stage talking about the platform they’ve chosen to spend their career improving for us. FileMaker, Inc. product managers and engineers emerge from their cubicles to show us what they’re currently working on back at the wedge.

Socialization Tips

  • Find a friend or two. If you’re coming by yourself, it’s quite intimidating to be in a sea of 1600 devs and not know anyone. So say hi. Make a friend early. My first time at FileMaker DevCon, I actually met someone through the community. We shared a room to save costs and I followed him around. He introduced me to folks and gave me advice. It was the start of a great friendship.
  • Visit the vendors. The main exhibit hall will be filled with booths of different FileMaker shops out there. We’ll have a booth, and we have cool things planned for that space. Also in that space is the Visionary bar and the FileMaker Tech Support Central. The visionary bar is filled with folks in the community holding office hours. You can come to them with any specific FileMaker problem (there is no couch) and get some advice from the experts. The Tech Support Center contains FileMaker, Inc. Engineers and designers that can talk to you about specific issues you might have with your app or with FileMaker.
  • Come join others at the New Attendee Meetup This is a session devoted to any first-timers. FileMaker, Inc. staff will be there to talk about the week and get you started. The Women of FileMaker is hosting a DevCon buddy program. Take advantage of this time to get to know other new folks and buddies that have been there many years.

Don’t miss any part of the conference.

Don’t Mess with the Sessions

There’s too many sessions for you to attend all of them, so be deliberate about which ones you want to attend. Take some time now to study the schedule and jot down topics you want to be a part of in person. Though each session is recorded and eventually posted to FileMaker’s YouTube channel, decide which sessions you’d like to be in the room during the time. TheDevCon2Go Scheduler custom app will be released soon, and you can use that on your devices to mark your favorite sessions and to review the schedule in advance.

Attentive listening in a session.

If you’re a FileMaker beginner, attend some beginner sessions, but also attend some more-advanced ones. You might not fully understand everything presented, but the stretch in content will further inspire you. Also attend sessions on stuff you’ve never used or heard of: cURL, JSON, integrations, IoT, all the things that you might not see yourself using. These innovation sessions are the future of the platform, so be sure and get in on the ground floor.

If you are able, attend a training-day session. They are held on the Monday of the conference and are an additional cost, but these sessions (3.5 hours in length) are more hands-on and more exploratory than the hour-long sessions of the regular conference. There are always beginner, intermediate, advanced sessions. The topics range from basic FileMaker to reporting and user experience design. I’m teaching a session on JavaScript for FileMaker developers.

Don’t Mess with your Health

The conference is a week, but a lot happens in that week. Protect yourself and keep yourself healthy. Here’s some ways you can do that:

  • Bring sunscreen. It’s Texas.
  • Bring a water bottle. It’s Texas.
  • Bring warm clothes. It’s Texas, and we’re indoors. The AC will be blasting and cold. Of course when you step outside into the sunshine, you’ll bake in all the layers, but at least you’ll not freeze in the sessions.
  • Exercise. You’re doing a lot of sitting in the sessions, and we know that sitting is the new cancer. Get outside and walk (at like 5 am) or late at night (2 am). Hit the hotel gym or pool. Listen to your Apple Watch (we all have one, right?).
  • Rest / Get away. Above I’ve encouraged you to attend all you can, but you have to rest. So if you’re exhausted on Wednesday, take a moment to yourself. The hotel is huge, so find a quiet spot to just zone out (preferably not in a session) and recharge.

Don’t Mess with the Opportunities

FileMaker DevCon is the best place for a FileMaker developer to go. For the first timer, it is inspiring and overwhelming and excellent. There’s so much to take in, so many folks to meet. I encourage you to take advantage of every opportunity given at DevCon and be a part of this great community. Meet folks that you’ve talked with in the community forums. Learn a lot. Meet at least four new people. Visit vendors and booths. Learn what’s exciting about the platform.

Say hi to us at Geist Interactive.

We’ll be there at our booth demoing Editor and GoDraw and Quickbooks and other products, or walking around with our company t-shirts. Be sure and strike up a conversation about JSON or Native FileMaker or the FileMaker platform. We have a few things to say about those I’m sure.

Meet FileMaker, Inc. folks. They are some of the most friendly and passionate people about their platform I know. Four years ago now, I met the PM of the FileMaker Pro Advanced product. We’ve become good friends. We chat about FileMaker, about video games, about yard work.

Don’t Mess with FileMaker DevCon

Do everything you can to get the most you can out of FileMaker DevCon. You’ll be grateful that you got your (or your company’s) money worth. You’ll be inspired and energized and ready to push yourself to become better in the platform.

FileMaker 17 introduces a new script step: Perform Script by Name.  FileMaker Devs have been asking for this feature for a long time. It sounds like a useful idea, but we should probably try to understand how it works before we just adopt it willy-nilly, for all our script calling needs.  Let’s explore this idea together.

Perform Script by Name: The basics

Perform Script By Name is a script step that functions as it is named. We now have two options when using the Perform Script step: By Name  & From list.

If “From list” is chosen, then we go about choosing a script in the normal way. However, if “By name” is selected, we get to set the name of the script using the calculation dialog.

At the script’s runtime, this step checks to see if the script is in the list of scripts and runs that one. If it isn’t in the list, then we get the good ol’ message:

We can suppress the message with the Set Error Capture [on] step and capture the error (104 Script is missing) with the Get (LastError) function.

In a multi-file solution, we can use this same step to call a script in another file using the same table/field format: ExternalFileRefName::ScriptName.

Notice this step is using the external file reference name, not the actual file name. We need to use the name we gave to the file reference.

Pretty simple. There doesn’t seem to be much else to this. Set the name of the script or external file reference name and script in some manner, and this step will run that script.

Oh, by the way, this works for Perform Script on Server as well. As we set up a script to run there, we are presented with the same dialog.

Wait, what? Why is this useful?

Here in FileMaker Pro 17 Advanced, we have the option to set a script name and run that script, a step that belongs in the ‘by name’ group of steps: Set Field By Name, Go to Layout by Name, and this one. When I first saw it, it struck me as odd: why would I ever use this step that adds another source of indirection to my file and is fragile. Let’s consider its possible uses and the idea that this step is fragile to see if we can find some workarounds.

It is useful after all

The option to perform script by name is actually useful. It seems to get rid of complex If / Else if / End if logic steps that determine the script to run. Maybe in a custom app, there’s a script called “Edit” and this script is run from a student record and a teacher record. The first part of this Edit script would have to use the If logic to determine which edit script to run, something like

Quite a few script steps.

With this new option, we can reduce the steps:

This does seem useful. It would certainly reduce the number of steps needed to determine the script. In a recent project, I saw one navigation script that ran for the entire system. IT was literally 150 lines long with a bunch of Else If logic steps. It was tough to debug. So there’s that. This option is useful.

Notice in the example above, I’m setting the name of the script into a variable and then passing that variable into the Perform Script step. That seems useful and handy.

Since the name of the script is a calculation dialog, I have a plethora of ways to get the script. I can construct it like shown above. I could get it from some preference table, or I could pass in the script name via a parameter, to name a few.

This new option in Perform Script allows us to write some pretty complex logic in a simpler way. If reducing the number of lines of code is your goal, Perform Script By Name is a must-use.

“Fra-gee-lay. It must be Italian”

Any developer’s first thought about this script step is that it can be easily broken. If my script name today is “ThatScript” and for some reason (legit or not) I decide to change it to “That Script”, then my perform script by name step is broken. That is certainly true.

Another factor to consider is that Perform Script By Name is another source of indirection, one that our Realtime Developer Intelligence tool FMPerception can find and point out, but this is an indirect source. Every time I use Perform Script by Name [“ThatScript”] I reduce the number of times FMPerception or database analysis tools can identify in the DDR where and when that script is used. That’s not bad. It is just something to consider.

But just because something is fragile or introduces indirection, there’s no reason to avoid this script step option. There are possible workarounds to the fragility issue. Let’s take a look at some of those.


Don’t change names

The first ‘workaround’ I can think of is: don’t change your script names. It seems obvious, but also almost unthinkable. FIleMaker is a rapid-application development tool. We can create a custom app quickly and easily, and that includes changing things on the fly. If our fieldName or script or layout’s original name is now unsatisfactory to us, it is easy to change. FileMaker after all actually looks at the ID of fields, layouts, scripts when calling or going to or setting. We’ve had it easy: change names as much as we want. I’d argue that this is a sign of not-fully-thought out planning, but I make no judgements. It happens. But I’d encourage us to change names of things as little as possible.


Second, if we do start using a script in the ‘by name’ option of Perform Script, we need to very clearly document that. In the above pictures, my script “ThatScript” is being used in the ‘by name’ option. So I should go over to “ThatScript” and document at the top “###### USED IN PERFORM SCRIPT BY NAME. DO NOT CHANGE THE NAME ######” or something along those lines to inform everyone, including your future self, to tread carefully with this script. Or put these called scripts in a “BY NAME” folder. Something to alert folks to its special case.

Generate script names

Third, we can generate the name of the scripts that will be used in the following parent script. 

At the top of my Edit_Record script, I have a code block that gathers the names of the scripts that could be used in this parent script. I first set a global variable to 1. Then I go into each of the scripts that could be used.

Inside each script, at the top, I immediately exit with the script name.

and then collect that name into a JSON object, in my case, in $scripts.

This works. It adds complexity to your parent script, but it does ensure that I get the correct script name each time.

Other possibilities

There’s more ways to ensure that you have the correct script names every time. There’s a good function I just discovered: ScriptNames(). It returns a list of the scripts in a file. That could be useful somehow. Maybe you could gather all the scripts into a global and then check against this list every time using Filter().

Don’t be afraid

This new option is useful and valuable in the right circumstances. I’d say we shouldn’t be afraid of it or avoid it. Use it where appropriate. But don’t go overboard. Don’t use it like we all started using ExecuteSQL() when it came out (that is, everywhere).

Be deliberate in its use. Document the heck out of scripts that are used in this “by name” manner, and be careful about refactoring script names for no good reason.

I look forward to using this to simplify complex logic. Give it a try, and let us know how you use the new Perform Script by Name step.