Proof is excited to announce that Ernest Koe, Co-Founder and CEO, has joined the Claris Partner Council!

The Claris Partner Council is a collaborative effort between the Claris Executive Team and selected Claris Partners from the Claris FileMaker community. Meeting twice each quarter, the Council aims to advance the long-term growth and success of the Claris FileMaker platform and community.

Proof encourages fellow Claris Partners and members of the Claris FileMaker community to reach out to us directly to share experiences, ideas, and suggestions for discussion at Council meetings (the Council meets twice each quarter).

For more information and to connect with the Claris Partner Council, please visit the online Claris Partner Community.

The Claris Engage 2020 Community Virtual Conference is nearly here! Proof is excited to be participating in this first-ever virtual event, free to all Claris community members. You can find us presenting at the following live session or by visiting our virtual booth (details below!).

Ernest Koe, Co-Founder and CEO of Proof, will be a panelist in the session Add-Ons & Open Platform: This Changes Everything on Tuesday, August 4, 2020, from 3-3:45 p.m. EDT. The session will explore how new JavaScript and Add-on capabilities in Claris FileMaker 19 have opened the platform, enabling faster, simpler creation of apps that are more powerful than ever. Discussion topics will include:

  • Modular development with the FileMaker platform using Add-ons
  • Add-ons, integrations, or from scratch – how to choose the best approach for adding new functions to your app
  • JavaScript for pro-developers and low-code creators
  • Vision for Add-ons marketplace of the future

Don’t miss it! Register online to attend this panel here:

Proof will also have a booth at the Claris Engage Watch Party and Virtual Tradeshow – a Slack workspace for conference attendees – on August 4-5, 2020. We hope you can join us there to learn more about what we’re doing with add-ons, education and business systems, workflow and integration, and more. Find our booth here:

We’re looking forward to being a part of this exciting virtual conference this year and can’t wait to reconnect with this amazing community. See you there!

For more information on the Claris Engage 2020 Community Virtual Conference, visit:

By Brian Ouimette:

In this article, we will be looking at a demo of a check-in/check-out system based on geolocation that is specifically for FileMaker WebDirect clients.

HTML5’s GeoLocation API gives us a web-native way of doing this within the webviewer. However, in FileMaker 18 or earlier, there is no built-in way for us to get geolocation data out of the webviewer and back to FileMaker. (Stay tuned for a FileMaker 19 version of this solution.) For now, the constraints that gave rise to this solution are that (1) we have a FileMaker Server 18 hosted WebDirect solution and (2) we want to avoid plugins or other technologies that are not directly supported by

FileMaker Server.

To start, we have a FileMaker file that references a basic HTML page containing a single button that is conditionally formatted

based on the record state (never checked in, currently checked in, or checked out). We add a little JavaScript code to get coordinates using the HTML GeoLocation API and send them along with the FileMaker recordID to a PHP page, which then makes a REST API call to FileMaker Server via the Data API.

If being entirely standalone isn’t a requirement, you could use something other than PHP to serve up the HTML/JavaScript file. At Proof, we generally prefer AWS Lambdas APIs or Claris Connect to glue our workflows together. For an all-in-one standalone solutions, enabling PHP on FileMaker Server gives us an easy win.

If you want a serverless solution, you could skip the PHP/server-side matter altogether and just have your JavaScript function to make a call to some REST API that would do the heavy lifting of writing back to FileMaker Server.

The webviewer in the FileMaker file references the HTML page and has parameters that are passed in like the FileMaker recordID, as well as values that may have already been recorded in the geolocation fields.

The Files: A Quick Breakdown

  • geolocation.fmp12 FileMaker database to host on FileMaker Server. It contains two layouts: one is for WebDirect and the other is for the Data API. The WebDirect layout has a webviewer at the top with a the single button that is conditionally formatted based on the record state (never checked in, currently checked in, or checked out). The remainder of the layout consists of FileMaker fields. The Data API user is `dapiuser`. This user only has access to the Data API layout and to modify the four geolocation fields.
  • geo.html –This is an HTML file you will host on FileMaker Server. It is the web page used in the webviewer and allows the WebDirect client to get the geolocation data.
  • sendLatLng.php – This file receives several parameters: Latitude and Longitude as well as a FileMaker recordID used to update the record via the Data API. Depending on the button state in the HTML file, the parameter names will either be checkinLat and checkinLng or checkoutLat and checkoutLng. The PHP takes these parameters and makes a post back to FileMaker via the Data API and updates the record. The way this file is currently set up is to hold the base64encoded username and password for the Data API. This could be improved, but for the purpose of this demo, this is how we went about storing the credentials.

Access these files by downloading the demo here.


Open the PHP and HTML files. Replace anywhere where <<host>> is with the FQDN where the files are being hosted. In FileMaker in the webviewer replace <<host>> with the FQDN. In the PHP file, you will also need to update the base64 encoded credentials. If you use the dapiuser, the base64 would be `ZGFwaXVzZXI6ZGFwaXVzZXI=`. You will need to enable the Data API, which means you will also need to install an SSL certificate. Web Publishing and PHP will both also need to be enabled as well.

And there you have it! Feel free to give this solution a try and drop us a comment below to let us know what you think.

As your school or organization works to adjust to the new COVID-19 landscape, no doubt there are lots of questions and uncertainty. We just want you to know that one thing you don’t have to worry about is support for your Proof systems. We have always been a virtual office company. We have experience being a productive remote team. We know the tools, the tricks, and the challenges. We’re here for you like we’ve always been.

Get in touch with us at if you need help with the transition from on-site to remote, have questions about Proof systems, or just need to bounce general tech or data ideas off someone. We are here for you.  And in that spirit, we have set up a hub for the greater education technology community called edTechCRT.

This is a community-driven virtual hub for anyone involved in education at any level or capacity to share information and get support from each other in the face of the current COVID-19 emergency. Join us there and add your voice, experience, and expertise.  edTechCRT is free, non-commercial and open to everyone. Learn more here:

I took some time this week to gather together and clean up the assorted powershell scripts I’ve written to make CLI admin of FileMaker Server (≥ 16) a little less tedious. There’s more to come–these are the core scripts to get the ball rolling. You can find the public release (MIT License) on github at

As usual, all standard caveats apply.


Checkout the latest podcast episode from the good folks at Geist Interactive,

Listening time: 72min Jeremy Brown and Todd Geist were wonderful and gracious hosts. This was originally going to be about FileMaker Finds and Searches but…well, we went pretty meta and totally blew past the original theme.

It was a really fun session that touched on a number of topics close to my heart: remote teams, the present state and the future of FileMaker (Claris), the search engine problem in FileMaker, the concept of “FileMaker AND” vs. “FileMaker OR” and the future of workplace innovation, digital transformation and the power of systems, and the idea that we are living in an incredible time of business technology transformation. There’s a lot going on here, and I don’t do enough to share my thoughts publicly, so it may seem out-of-character, but I swear it’s me – I hope this will give folks a glimpse of some of the key ideas that continue to motivate me and help form the foundation of Proof’s mission and purpose.

By Andrew Koller

FileMaker offers a plethora of premade tools to organize and display data, so it may come as a surprise to many new developers that there are no native functions built in for phone number formatting.

Lucky for us, this is a quick and easy DIY project, and a great chance to expand your knowledge of functions and script triggers. Read on for a step-by-step walkthrough on how to create and implement this yourself!

Or, if you don’t feel like learning, just scroll down and swipe the code. Nobody’s watching. 👀

Time: 20 minutes

Level: Beginner What you’ll need: a basic understanding of layouts and custom functions


  • Create a custom function to format the phone number field after some text has been entered by a user:
  • In Field Options, set the field as a Calculated value of the custom function and pass in the field itself as a parameter. Make sure that the “Do not replace existing values” is unchecked.
  • Create a script for a script-trigger to format the phone number as you type:
  • Set script trigger to OnObjectKeystroke, and pass in the field itself as a parameter.


As with any good solution, the first step is identifying the problem and the desired outcome. In this case, I want the phone number field in my FileMaker app to format a user-entered string (some combination of characters) with a desired format of xxx-xxx-xxxx.

Broken down into bite-sized chunks, the task list reads as follows:

  1. Accept input from a specified field
  2. Remove all non-numeric values
  3. Remove any digits beyond the first ten
  4. Place dashes in front of the fourth and the seventh values
  5. Store our calculated value in a specified field

In the Manage Database window, I can automatically modify a field’s contents by setting it to a calculated value. I can take my input in the same step by adding the field that’s being pulled from as a parameter. That would take care of steps 1 and 5, so I can set those aside for now and plan to build around that (don’t worry if this is a little confusing – I’ll do a more detailed walkthrough when it’s time to implement this portion). With this plan in mind, I’ll start by creating a custom function to do the necessary calculations. I’ll call the function “FormatPhoneUS,” and add a parameter to represent the input. I’ll call that parameter “string.”

From there, the first thing to do is remove everything from the string that isn’t a number. The function GetAsNumber may seem like an obvious choice, but this function retains periods (to represent decimal points) as well as numbers, so in this case Filter is a better choice. I’ll set the parameter “string” as my textToFilter, and all digits as the filterText (literally “0123456789”). I’ll need to access the filtered string throughout the function, so I’ll set it to a variable called “format” using the Let function.

Next comes formatting the number. I need ten digits to get the proper format, but what if a user tries to put in a longer string?

As with many scripting exercises, I’ll have to make some assumptions in order to handle potential user error. In this case, I’ll assume that any digits after the first ten were typed in error, and leave them out of the final equation.

Using the Left and the Middle functions, I can set three more variables to capture the three left, three middle, and four right digits. I’ll call those “l”, “m”, and “r”. By using the Middle function rather than Right on the last four digits, I can get the numbers I need without having to trim the string first.

I now have the numbers I need grouped in easy-to-call variables. I’ll use List to concatenate those variables. Since List separates each variable with a carriage return, I can use Substitute to get the dashes I want by substituting the carriage return (”¶”) with a dash (“-”). I’ll set my original “format” variable to the value returned by substitute, and have that be the value returned by Let.

All together, this looks like:

Now back to steps 1 and 5 so I can add this function to my field as a calculated value.

In the Fields tab in the Manage Database window, I’ll select the field that I want to edit (in this example, I’ll use a field named “phoneNumber”). Pressing the Options button brings up more options for the field. Under the Auto-Enter tab, I’ll select the Calculated value checkbox and set that to “FormatPhoneUS ( phoneNumber )” – (I could have also passed “Self” as the parameter to the same effect in this case). I’ll also make sure the “Do not replace existing value” is unchecked, and there we have it! I now have a field that will format phone numbers.

Predicting and handling edge cases: +1

While the phone number formatter technically meets all of the original requirements, there’s a glaring omission: what if someone prefixes a number with a “1”? As it currently stands, if a user enters 1-877-776-6301 for example, the field would populate as 187-777-6630.

That’s not what I want at all! Because the +1 prefix is used to represent the US country code, no US area code can start with “1.” With this in mind, I can make some assumptions. Any time the first number is “1”, I can assume that the user was accounting for the +1, and remove it prior to formatting.

This is easy to achieve with an If statement. If the first number of our filtered variable f is “1”, then I want to return everything in “format” minus the first number; otherwise, I’ll just return “format” as it is.

I’ll use Left to identify whether or not the first number is 1. If it is, I’ll use Right and trim the leading “1” off by simply return the Length of format – 1; otherwise I’ll just return format in its current form and continue the process.

Formatting on the fly

Let’s take this one step further and auto-populate the dashes while information is being entered. This can be achieved through the utilization of scripts and script triggers. The script trigger “OnObjectKeystroke” is what I’ll use in this case. I’ll set it to trigger on the field that I’m formatting and pass in the field’s contents as a parameter.

In the script, I can capture the keystroke that was entered by utilizing Get(TriggerKeystroke). I’ll set a local variable using the Set Variable script step, and set it to the value of Get(TriggerKeystroke). I’ll call that variable $keystroke. From there, I’ll take a page from the function I wrote earlier and filter $keystroke for digits.

I’d like to use an If statement in combination with Filter to determine whether or not a digit was entered; the problem with that is that If interprets “0” as a false statement, rather than as a digit. I can get around this by wrapping the Filter function with IsEmpty. If the filtered result of “0123456789” does not return empty, we know that a digit was entered and the script will move to the next step. The next part seems relatively straightforward: get our script parameter, add $keystroke to the end of it using “&”, run those through FormatPhoneUS, and insert those back into the field using Insert Calculated Result.

But what if our user tries to make edits to the middle of the string? According to this setup, the edit would be tacked to the end of the current field contents, no matter where the user is in the field.

No bueno. One way to get around this is by using Get(ActiveSelectionStart). I can effectively chop our current string at the selection position and use that to capture the left and right portions of the string in two separate variables.

I’ll start by going back to the top and setting a new variable called $parameter to Get(ScriptParameter), and another called $position to Get(ActiveSelectionStart) – 1. I’m subtracting one because Get(ActiveSelectionStart) returns the ordinal position, but the string is indexed at zero.

From there I’ll go back inside of the If statement and set a new variable called $leftString. Using the Left function, I’ll use $parameter for the text, and get $position numberOfCharacters. Setting the variable $rightString to capture the right side looks similar. I’ll use the function Right to get $parameter for Length ( $parameter ) – $position numberOfCharacters.

I can stitch together the three string components as a formatted string by setting a variable (I’ll call it $result) to the value of “FormatPhoneUS ($leftString & $keystroke & $rightString)”. Now I can insert $result using Insert Calculated Result, and boom! I have a field that automatically formats as the digits are being typed.

Accounting for Edits

Since I filtered the keystroke to include only digits, I’ll need to add an exception to allow users to move around the field and make edits. In this case I’d like them to be able to use the backspace, delete, left arrow, and right arrow keys, as well as to use tab to move to the next field. I’ll set this up as an Else If statement and use FilterValues. I can filter according to the unicode values of the keys I want by using Code to interpret $keystroke as the textToFilter, and using List to hold the unicode values I want to accept. If the statement evaluates as true, I’ll set another variable called $validChar to 1 (aka “true”).

Now all I have to do is add a quick If check for validChar, and exit the script if $validChar evaluates as false. And there we have it! A phone number field that automatically formats with each keystroke.

Proof and Northeast Database Solutions are excited to announce the launch of the first official community edition version of fmEZcharts!

fmEZcharts is a chart and dashboard tool for Claris FileMaker that allows for the quick and easy creation of JavaScript or HTML chart components (even if you don’t know anything about JavaScript or HTML). Over a year in the making, the newest version offers a tighter, cleaner look and feel, with improved functionality and usability. It includes new features like the ability to pick themes, colors, and data sets, as well as a larger selection of ready-to-go charts.

fmEZcharts is available to download for free at Give it a try and let us know what you think!


Hey folks,

We are big fans of Paw here at Proof. Paw is an API tool that lets you create and test web API calls. The folks at Paw have done a pretty remarkable job of making the business of making API calls a thing of joy. If you are familiar with Postman, you’ll like Paw. While Postman is pretty cool, Paw has a few additional killer features that make it hard to beat for those of us who are primarily working in OS X.

Paw has several code generators already built in for different languages, but unlike Postman, Paw provides the ability to create or modify a code generator to work for specific needs. As a FileMaker-heavy shop, we were frequently tweaking Paw generated cURL snippets into a format that’s compatible with FileMaker’s  “Insert from URL” script step. In our experience, this can be a repetitive, error prone exercise in chasing down quotes, carefully adding escape characters and substituting strings for variables.

We thought it’d be cool if we could copy the code directly out of Paw and into FileMaker without too much jiggery-pokery. And so, the FileMaker Code Generator for Paw was born.


To use the FileMaker code generator for Paw, go to your Paw application>Extensions>Install Extension and paste this in:

You can also search for FileMaker Code Generator via Paw’s extension web page like so, and install it that way.

The Source Code

The Paw FileMaker extension is available via the online Paw Extension directory and can be downloaded from GitHub. We’ve released this as an open source project (MIT license), so please hack it, add to it, fork it, and most of all give us any feedback so we can make this better. You can read more about it here,

The Details

Paw’s standard cURL code generator is already pretty close to the format required for FileMaker’s cURL Options. For example, copying a stock cURL snippet gets us something like this:

It’s close, but not quite.

First, it’s gnarly stuff to read and to parse. Second, it seems like our spiffy little Paw extension should (1) fix the quotes, properly escape them, and (2) substitute the parameter values in our snippet with placeholders FileMaker variables, which is exactly what we’ve done in this initial release.

Version 1

Once you have installed the extension, you should see a ‘FileMaker’ option in your code generation selector. There are two parts to the generated snippet:

  1. the cURL Options code snippet itself
  2. the url of the endpoint.

We’ve also included trace and response headers to help with debugging when things go wrong. You don’t actually need the –trace-ascii and –dump-header flags but if you use them, just use your data viewer to show the $trace and $headers values while stepping through your script.


We’ve named user-defined header keys according to their header names in Paw; auth header keys get generated as “username”, “password” and “access_token”. In the url, query parameters are included in the snippet and the query values have been substituted with FileMaker variables with the same names. While v1 of the code generator it does not handle path parameters, we are looking at adding that in a future release.

The Paw FileMaker extension is available via the online Paw Extension directory and can be downloaded from GitHub.

Drop us a comment below and let us know what you think.