FileMaker and the Twilio API

Here at Databuzz we’re longtime fans of Twilio, the company with the strange name that offers a Cloud communications platform, providing the building blocks to add messaging, voice, and video in your web and mobile applications.

For many years we’ve been working with the Twilio API, primarily to send and receive SMS messages using our fmSMS FileMaker solution. Twilio provides great coverage and very competitive pricing and we’ve been recommending Twilio to our customers for many years – when they ask which SMS Gateway we use at Databuzz we don’t hesitate to recommend Twilio.

Earlier this year we had the chance to attend the first Twilio Engage Sydney and learn more about the company’s strategy and participate in some great product demos. Twilio are opening 2 new offices in Melbourne and Sydney and it was great to be able to meet some of their Australian based staff in person.

We’ve written about how we use the Twilio API in the past, including a demonstration for Voice Calling with FileMaker and Twilio as well as sending Emojis from fmSMS. We’ve also made some custom solutions for customers to allow them to send and receive MMS (picture messages) messages from the FileMaker platform.

Over the past few months we’ve had the opportunity to work on some additional Twilio APIs that enhance the functionality found in our fmSMS solution, including:

  • adding phone number lookup functionality via the Twilio Lookup API
  • adding the ability to poll Twilio for any incoming messages that may not have been delivered due to a local server/Internet outage when using the regular Webhooks

For some customers the ability to check a number before sending an SMS or MMS message is important as it allows you to verify that the number you are about to send a message to is indeed a mobile number. For example you might have a list of Customers and associated phone numbers, but you aren’t sure if the number is a landline number or a mobile number. Using the Twilio Lookup API you can make a request to verify a number and receive information about the carrier and optionally (where supported) the caller name, allowing you to confirm the veracity of the number.

fmSMS includes the necessary PHP files to receive incoming messages to your Twilio number and have these pushed automatically to your FileMaker Server, but there may be times when your server or Internet connection is offline but you would still like to download any missed messages into your FileMaker solution. We’ve helped customers add the ability to “poll” the Twilio Messages API for any incoming messages to their Twilio number that they might have missed during a planned or unscheduled outage.

We’ve put together a simple demonstration video showing these in action – you can watch the video inline below or directly on YouTube:

Andrew Duncan from Databuzz to speak at WordCamp Sydney 2018

 

WordCamp Sydney 2018 is on 28 & 29 July this year at the University of Technology Sydney. Databuzz is pleased to announce that Andrew Duncan will be speaking this year on WooCommerce integration using the WooCommerce API.

Databuzz are big fans of WooCommerce and WordPress – we’ve been using WordPress and WooCommerce for many years to run our websites and eCommerce platforms. Our fmEcommerce Link (WooCommerce Edition) solution is one of our most popular products and we can continue to update this with new features and improvements.

We look forward to meeting up and discussing all things WordPress – you can get tickets and more information from the WordCamp Sydney 2018 site here:

https://2018.sydney.wordcamp.org/

FileMaker, cURL and HTTP Response Codes

When FileMaker Inc. released the FileMaker 16 Platform last year they included a feature I had been requesting for over 15 years – native cURL support. cURL is a command line tool and library for transferring data with URLs – you’re probably familiar with the HTTP, HTTPS, FTP and SMTP protocols. cURL is important as it allows us to interact with external web services/APIs directly from FileMaker Pro, FileMaker Go, FileMaker WebDirect and FileMaker Server. For example we can use FileMaker to send an SMS, upload an Invoice to Xero or MYOB, or download Orders from eCommerce platforms like WooCommerce or Shopify.

Starting with the introduction of the Insert From URL script step in FileMaker Pro v12 we’ve been able to interact with URLs with some limitations:

  • FileMaker Pro v12 introduced the Insert From URL script step which supported http, https, ftp, ftps, and file protocols. A field was required to download the result/response into and it didn’t support performing an HTTP/S POST request – only GET requests were supported (most APIs require a POST request to create/update records via the API). There was also no ability to customise the HTTP request, e.g. to set HTTP Headers which are often required for many APIs
  • FileMaker Pro v13 extended the Insert From URL script step to both HTTP GET and HTTP POST requests using the httppost and httpspost custom schemes that you specified when constructing the URL (e.g. “httppost://www.filemaker.com/path?fname=Bob&lname=Smith”). You still couldn’t specify HTTP Headers and still required a field for the result

Given these limitations I rarely used the Insert from URL script step until FileMaker Pro 16 was released. Since the FileMaker Pro v6 days I have been using a number of different plug-ins to perform HTTP requests – initially I had a custom plug-in developed, then switched to the Troi URL plug-in and then to the BaseElements plug-in. Databuzz sponsored the development of some specific functions that we needed and the BaseElements plug-in provided us with cURL support and a number of other related functions, such as JSON encoding and parsing and XPath for parsing XML data. The BaseElements plug-in has provided us with the functionality we needed that was missing in the FileMaker platform, but as a plug-in was required it did have a number of disadvantages:

  • FileMaker Go does not support plug-ins (you can now use the iOS SDK). You could use FileMaker Server script schedules and Perform Script on Server as a workaround but this required the FileMaker solution to be hosted by FileMaker Server so wouldn’t work for solutions running locally on the iPad or iPhone
  • running scripts under FileMaker Server required the plug-in to be installed on the server, which can be done easily as long as the appropriate permissions have been granted in the FileMaker Server Admin Console. Some hosting providers also disabled the option to install plug-ins on shared servers.

With the release of the FileMaker 16 platform came the ability to specify one or more supported cURL options as a calculation when using the Insert From URL script step, as well as the ability to specify a variable as the target (no more fields required!). This was a game changer as far as working with APIs was concerned – now the entire FileMaker Platform could natively make HTTP requests, set HTTP Headers, and encode JSON data and parse JSON. All of our integration solutions were using the BaseElements plug-in, so we started to work on adding native support for FileMaker Pro v16 users by switching from the BaseElements plug-in functions to using the native Insert From URL script step, cURL options and JSON functions.

One function for which there was no native equivalent was the BE_HTTP_Response_Code function which returns the HTTP response code value from the last request. HTTP Response Codes are issued by the server in response to a request and can be used to determine whether the HTTP request was successfully completed or if there were issues associated with the request. For example 200 is the standard response for a successful request and 401 means there was an authentication issue and the request failed. It’s important when working with APIs to check the HTTP Response Code to confirm that the request was processed successfully – the documentation for each API will usually specify what response code indicates a successful request (typically 200 or 201).

The HTTP Response Code is contained with the HTTP Response Headers which are returned by the server processing the request. You need to specify the following cURL option to get the response headers returned into a FileMaker variable:

" --dump-header $responseHeaders"

The $responseHeaders variable will then contain something like this after the Insert From URL script step has been performed:

HTTP/1.1 200 OK
Date: Wed, 13 Jun 2018 04:45:17 GMT
Server: Apache/2.4.26 (Red Hat)
X-Powered-By: PHP/5.6.35
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8

In the above example you can see the first line of the response headers contains the response code: “HTTP/1.1 200 OK”. Other common response codes that you might encounter include:

HTTP/1.1 100 Continue
HTTP/1.1 403 Forbidden
HTTP/1.1 201 Created
HTTP/1.1 302 Found
HTTP/1.1 301 Moved Permanently

You can use standard FileMaker functions to get the actual numerical response code from the first line of the response headers, e.g.:

Let ( [
t1 = GetValue ( $responseHeaders ; 1 ) ;
t2 = Substitute ( t1 ; " " ; "¶" ) ;
n1 = GetValue ( t2 ; 2 )
] ;

n1

) // Let

This all works fine as long as the Response Headers only contain a single response code, but sometimes the server will return multiple response codes. For example the response might include a redirect or a continue and look like this:

HTTP/1.1 100 Continue

HTTP/1.1 403 Forbidden
Server: nginx/1.14.0
Date: Wed, 13 Jun 2018 07:41:16 GMT
Connection: keep-alive

The response code we are after is the “403” value and not the “100” value, so our above calculation would return the wrong response code in this situation. We started working on a custom function that would look for the last “HTTP/1.1” string and then get the code following this, but that failed pretty quickly when working with a server that included the string “HTTP/1.1” elsewhere in the response headers.

We’ve settled on using this custom function which so far is returning the correct result, at least with the APIs and servers that we have tested it on so far. We would much rather have a native function for this which does the equivalent of what the BaseElements BE_HTTP_Response_Code function does without having to try to locate and find the last response code from the response headers. From researching this it appears that there is already a cURL option for this:

-w "%{http_code}"

but unfortunately the -w option is not one of the FileMaker supported cURL options, so for now you’ll need to parse out the response code until FileMaker add support for the -w option. We’ve added this to the FileMaker Product Ideas discussion area – if you would also like to see this feature in a future version of FileMaker platform you can vote up the idea here.

FM Starting Point Custom Integrations

Over the past few years we’ve performed a number of customisations for customers using the popular FM Starting Point template from Richard Carlton Consulting. FM Starting Point is a free FileMaker CRM template designed for use with the latest version of FileMaker Pro, and is focused on small businesses, work groups, and non-profit organisations. FM Starting Point manages business contacts , accounts, products, projects, and more – since it’s first release 5 years ago it has been downloaded over 490,000 times.

Over the past 5 years we’ve performed the following customisations of FM Starting Point for our customers:

  • added the ability to send single/bulk SMS messages and receive incoming SMS messages (fmSMS integration)
  • integrated our fmAccounting Link (Xero Edition) solution so you can upload Contacts, Invoices, Bills, Payments and more from FM Starting Point to Xero
  • added the ability to send single and bulk HTML emails
  • integrated our fmEcommerce Link (WooCommerce Edition) solution so you can push Products from FM Starting Point to WooCommerce and download Orders from WooCommerce to FM Starting Point
  • integrated our fmEcommerce Link (Shopify Edition) solution so you can push Products from FM Starting Point to Shopify and download Orders from Shopify to FM Starting Point
  • integrated our fmAccounting Link (MYOB AccountRight Edition) solution so you can upload Contacts, Invoices, Bills, Payments and more from FM Starting Point to MYOB AccountRight

If you would like to discuss customising your version of FM Starting Point please get in touch for a free initial consultation to discuss your requirements.

 

Gravity Forms Integration with FileMaker

Gravity Forms is a popular Form plugin for the WordPress platform, allowing you to create simple or advanced forms to capture data on your WordPress website. Over the years we’ve helped many customers with retrieving data from their Gravity Forms using a variety of methods, including:

  • simple CSV file download from Gravity Forms then import that CSV file into FileMaker
  • using the FileMaker PHP API to have Gravity Forms data automatically ‘pushed’ to their FileMaker solution each time an entry is submitted
  • using the External SQL Data Source feature to view the Gravity Forms data live from within FileMaker and create FileMaker scripts to download data

Each of these methods have their pros and cons: for some users the FileMaker PHP API integration is not an option, and for others they aren’t able to connect remotely to the SQL database as this is blocked by their web host. Downloading CSV files each day/week is also time consuming and cumbersome. Fortunately there is another method to use that has many advantages over these methods: the Gravity Forms Web API.

Using the Gravity Forms Web API we can dynamically query Gravity Forms from within FileMaker to check for new form entries and download those directly into our FileMaker solution, all within a few seconds. If you’re using FileMaker Pro v16 you can also use the new native JSON and cURL features to do this without requiring any FileMaker plug-ins – for older versions of FileMaker a plug-in is required to handle the API requests and cryptographic requirements. You can also setup schedules using FileMaker Server to have new form entries downloaded automatically (hourly, daily etc).

Here’s a short video demonstrating how we can download Gravity Forms entries directly into a FileMaker solution (you can also view it directly on YouTube):

If you would like to discuss integrating Gravity Forms with your FileMaker solution please get in touch for a free initial consultation to discuss your requirements.

fmEcommerce Link (Shopify Edition) and Metafields

Metafields in Shopify are like custom fields – they allow you to attach additional metadata or information about a particular Shopify store resource, such as a Product or Product Variant. For example you might need to store information about washing instructions for clothing that you sell or you would like to store a manufacturer and supplier SKU for each Product Variant.

In our fmEcommerce Link (Shopify Edition) solution we support the downloading and uploading of Metafields for Products and Product Variants (the Shopify API allows you to attach Metafields to a number of resources – see here for the full list). Shopify unfortunately does not have an interface for store owners to view or edit the Metafields for your store – it is considered a developer/designer feature so you will need to use a Shopify App to create, edit or delete Metafields in the Shopify Admin page.

Here’s some screenshots showing the Metafields for a Product:

and a Product Variant:

Using fmEcommerce Link (Shopify Edition) you can add, edit and delete these Metafields and using a Shopify app you can also view them. Here’s a screenshot showing the Metafields using the Metafields Editor app:

Here’s some links for learning more about working with Shopify Metafields:

If you would like us to add support for Metafields elsewhere in the fmEcommerce Link (Shopify Edition) solution please let us know.

fmAccounting Link (MYOB AccountRight Edition) Updated for Bills

We’ve just released an update to fmAccounting Link (MYOB AccountRight Edition), our FileMaker solution for integrating with MYOB AccountRight in Australia and New Zealand, with examples for working with Bills in MYOB. With v1.25 of fmAccounting Link you can now use FileMaker to:

  • download Bills from AccountRight to FileMaker (either all Bills or filtered by Bill Date)
  • create Bills in FileMaker and upload them to MYOB
  • convert a Purchase Order to a Bill in FileMaker and upload the converted Bill to MYOB

This is a free update for all existing customers – you can view the full release notes on our version history page.

Connecting FileMaker Pro to FileMaker Server with the FileMaker Data API

FileMaker Server 16 (and FileMaker Cloud 1.16.0) included a new trial feature called the FileMaker Data API (application programming interface), which allows web services or applications to access data in hosted FileMaker solutions without needing any FileMaker client software to be installed. This is similar to the current XML and PHP APIs which have been around for over 10 years, however the Data API is a REST (Representational State Transfer) API which means you don’t need to use any particular programming language to work with the Data API.

In their Product Roadmaps over the past couple of years FileMaker Inc. have indicated that they will be investing in the Data API in future releases of FileMaker platform. Whilst they have not included the XML and PHP APIs in their list of deprecated features their focus will be on the Data API which opens up the FileMaker platform to an almost unlimited number of external apps and services.

We’ve been working with REST APIs for many years – sending SMS messages, integrating with Accounting platforms and eCommerce platforms – so we were pleased to see FileMaker Server (and now FileMaker Cloud) include a REST API as this now opens up many possibilities for integration by external web services and applications, as they don’t need to know “FileMaker” in order to make requests with the Data API. If you’re familiar with making HTTP requests (GET, POST, PUT, DELETE) and working with JSON data formats then you will have no issues working with the FileMaker Data API.

As the FileMaker Data API is a trial feature – the trial expires on September 27, 2018 and the Data API will cease to operate – we normally wouldn’t recommend our clients use this feature in any live systems as it is likely to change and you will have to upgrade to the latest version of the FileMaker platform before the trial expires in order to keep using it (after making any necessary changes to ensure compatibility with the final release of the Data API). There is also the issue of licensing – the Data API is currently free to use in the trial period, but FileMaker plan to have a licensing model in place before the end of the trial. Without knowing what the final licensing model will be makes it hard for clients to commit to using the Data API at this stage.

During a recent project we had encountered a challenging issue that turns out was perfect for the Data API. This project has a FileMaker Server v16 hosted solution with a Custom Web Publishing/PHP interface. All users access the solution using a web browser – for security reasons installing FileMaker Pro was not an option. One requirement of the project was to allow printing of labels with barcodes and picking lists – we solved this by generating PDF files via the new support for generating PDF files on FileMaker Server as well as Excel files (see our blog post from last year on how we did this). We still ended up using a local FileMaker file to import the Excel file containing the data for the shipping labels and to create the barcodes.

This process was working smoothly but was more suitable for doing large bulk shipments and involved a number of steps that you normally wouldn’t have to perform in a purely FileMaker Pro interface:

  • users would first have to find the records via the web interface that they wished to generate labels for
  • they would then click a button to call the server side script to create the PDF or Excel file
  • they would then have to download this Excel or PDF file to their local machine
  • for PDF files they would simply open them and print as needed, and for the Excel files they would open the local FileMaker file and click a button to import the Excel file which then generated the labels and barcodes

As you can see there’s a number of steps involved, whereas with a pure FileMaker Pro interface there would typically be only 2 steps:

  • find the records to print
  • click a button to print the shipping labels or picking lists

The process was also the same regardless of whether you wished to print a single shipping label or 100 labels. We had been discussing ways to streamline and improve this process, knowing that we couldn’t connect to the solution using a live FileMaker Pro connection. We were leaning towards building a integration using either the XML or PHP APIs, or using a product like RESTfm when we realised that the Data API might be another option worth considering, knowing that it was a trial feature and would stop working in September but would be a better long term investment. Now that FileMaker Pro v16 supports cURL and JSON natively it started to make even more sense, even though using FileMaker Pro to integrate with FileMaker Server via the Data API doesn’t make too much sense at first.

We built a basic prototype in a few hours to authenticate and make simple requests to get single and bulk shipping labels and picking lists and were impressed by the speed of the responses, so decided to press ahead and incorporate this functionality into the existing local FileMaker solution that users were already using to import the Excel files and print labels and barcodes. We were further able to link the web interface with this local FileMaker file through the use of FMP URLs by adding buttons on the web interface that called scripts in the local FileMaker file and passed in parameters, so the updated process to print labels and packing lists is now down to 2 steps:

  • find the records to print
  • click a button to print the shipping labels or picking lists

If you’re thinking about using FileMaker Pro as a client for the FileMaker Data API here’s some tips and tricks we learnt along the way:

  • the FileMaker Data API Reference can be found on your FileMaker Server at this URL – https://localhost/fmi/rest/apidoc/ – and contains examples for the requests and responses you can expect when authenticating, working with records and performing finds. The FileMaker 16 Data API Guide is the other main reference to working with the Data API. I recommend having both of these resources open in separate tabs when working with the Data API for the first time
  • we recommend using tools like Postman when working with the Data API to learn how to structure your requests. You can convert your working requests to cURL using the Generate Code Snippets feature which you can then copy and paste into your FileMaker Insert From URL script step and format for use with FileMaker Pro. See our previous article about about using Postman environments with the REST API.
  • the Data API is not currently a complete replacement for the XML or PHP APIs. For example you cannot insert container data or run FileMaker scripts with the Data API, or retrieve metadata about your FileMaker solution such as layout schema. The Data API does not currently return data such as the number of found records like the getFoundSetCount() method does in the PHP API, so you need to use workarounds for these.
  • date formats appear to work in a similar way to the PHP API in that you need to specify them in MM/DD/YYYY format regardless of your date formats on your server or FileMaker solution. Dates are also returned in the same MM/DD/YYYY format (e.g. 11/30/2017 for November 30th, 2017).
  • when performing a find query the fields you are searching for don’t need to be on the layout you specified in your URL, but only fields on the specified layout are returned in the response.
  • when performing a find query that results in no records found the use of the –show-error cURL option determines whether the Insert From URL script step returns an error (1631) or not. This is documented in the Supported cURL options page help page under the Handling errors heading.
  • one issue that caused us grief is an apparent bug with the use of the JSONSetElement function with spaces when used in a particular way the the cURL options. We have now standardised on specifying the JSON for each Data API request using the –data @$data syntax instead of the alternative methods
  • to help with debugging we recommend using the –trace and –dump-header options with every request

The final cURL options generally look like this for a typical request (assuming you have already authenticated and stored the access token somewhere):

"--request POST" & 
" --header " & Quote( "Content-type" & ": " & "application/json" ) & 
" --header " & Quote( "FM-data-token" & ": " & $$restAPIAccessToken ) & 
" --data @$json" & 
" --trace $$cURLTrace" & 
" --dump-header $responseHeaders"

Using FileMaker Pro as a client for the FileMaker Data API has us thinking about new ways we can leverage the Data API from an offline FileMaker Pro or FileMaker Go client, such as syncing records when using FileMaker Go on an iPhone or iPad and removing the overhead of having to have a live connection to your FileMaker Server. The Data API is perfect for uploading or downloading small changes from an offline file and once the shipping version of the Data API is available in the next version of the FileMaker platform (and the licensing model revealed) we expect to see more widespread use of the Data API, particularly for offline files running under FileMaker Go.

 

Databuzz Turns 10 🎂

January 2018 marks the 10 year anniversary for Databuzz – we first opened our doors for business back in January, 2008. As it turned out 2008 wasn’t a particularly great year to start a new business. According to the Australian Bureau of Statistics, more than 60 percent of small businesses cease operating within the first three years of starting, and with a global financial crisis that same year I probably couldn’t have picked a worse time to start a new business.

Here I am 10 years later and happy to have come out the other side of the GFC, with many customers from our first year still with us today (and some still with us after 20 years).

When I started planning to return to the world of FileMaker Consulting as an independent developer after spending many happy years with Complete Data (which is still going strong today) I knew that I wanted to have a different name to my previous company name – Splash IT Consulting Pty Ltd – as that was no longer an accurate reflection of the business and work that we would perform.

I had first registered the name Splash IT Consulting back on January 5, 1999 when I first went solo and needed a business name to operate under as a sole trader. Having worked at Apple for many years, both in Australia and the UK, I was more of a generalist back then and offered a number of IT services, including:

  • FileMaker Pro development (I had just joined the FileMaker Solutions Alliance as it was known back then)
  • Mac OS X Server installation/configuation (sadly Apple has just announced that it has deprecated most of the macOS Server services)
  • Sherlock Plugins for Mac OS 8.5 – who remembers those!
  • Palm Pilot solutions
  • CD Burning

Here I am almost 20 years later and FileMaker Pro development is now the only service Databuzz offers and most of the other services no longer exist. Back then FileMaker Pro v5 was the latest version – FileMaker, Inc. had only recently come into existence to replace Claris Corporation. I no longer have any of the original website files for Splash IT Consulting but thanks to the magic of the Internet Archive Wayback Machine I managed to find an archive from September, 2000 (missing the main graphic):

Back in 1999 the options for searching for business names and registering them online were very limited and you had to complete the registration in person at the local Consumer Affairs registry office. I wanted to have the word ‘data’ in my name somewhere and had compiled a list of my top 3 names which I believed were available and most importantly also had the matching domain name available. I had also learnt the lesson of never having a hyphen in a domain name if you can avoid it (too many typos from customers when reading your your email address on the phone etc), as well as unfortunate emphasis some customers placed on the “sh-it” part of the name when pronouncing it.

I headed off to the local registry off knowing that if my first option was rejected then I at least had 2 other names to fall back on that I was happy with. For reasons that I can no longer recall all my names were rejected and I was left standing at the counter with a big queue of customers behind me frantically trying other names – and that’s how Databuzz was born. It was the first name I could come up with on the spot that didn’t get rejected!

I decided to keep things simple and use Databuzz as a trading name and keep Splash IT Consulting Pty Ltd as the official company name. The first Databuzz website was also a very simple 5 page static site:

which had an associated blog that ran on a platform called WordPress, which itself was only a few years old at the time. I’ve since replaced the static website with WordPress which now runs the website, blog and online shops for the Databuzz and fmSMS shops. Back in 2008 FileMaker Pro v9 was the current shipping version and FileMaker Go was still three years away from being released – FileMaker Mobile, the previous FileMaker mobile solution for the Palm OS and Pocket PC, had recently been discontinued. The original iPhone had been released in June, 2007 but was not available in Australia – it wasn’t until the iPhone 3G was released in July, 2008 that you could buy an iPhone in Australia.

It’s amazing how much change there has been in the IT industry in the past 10 years, and no doubt there will be even more change in the next 10 years as the pace of change only gets faster. Looking back there have been a number of highlights and milestones that stand out, including:

We’re continuing to update these solutions with new features based on suggestions from our customers and our own product roadmap, as well as work on some exciting new products that we hope to release some time later in 2018. I’d like to thank our customers for their support over the past 10 years (and a special mention to PEDro who we have worked with since 1999) and I look forward to working with you all again in the future and cannot wait to see what the next 10 years brings.

Eliminating Double Data Entry with eCommerce, FileMaker and Accounting Integration

Are you a small business that uses FileMaker to run your business (Contacts, Invoices, Suppliers, Leads etc) but also have an online store and use another accounting software? Do you find yourself re-entering online orders multiple times in your FileMaker CRM then once again in your accounting software?

There is a better way – we know as we once were in that situation ourselves. Over the past five years we’ve introduced a number of new systems into our business operations, including:

  • 2 online stores for our main Databuzz site as well as for our fmSMS product both running WooCommerce
  • switched from a  desktop accounting software to the Xero Cloud accounting platform

We also use the FileMaker platform internally to run our business and like many of our customers we suddenly found ourselves in the position where we had to enter a new sales order multiple times in different systems. The workflow for a new order became:

  1. receive notification via email of a new online order
  2. create a new order in our FileMaker CRM and copy/paste the customer and order details from the email
  3. logon to Xero and create a new Customer and Invoice and enter the Payment manually via copy/paste from FileMaker

The online order was being manually typed twice in FileMaker and our accounting software, leading to data entry errors and wasted time handling the same order multiple times. At Databuzz we like to “eat out own dogfood”  and most of our Products have been the result of a need to solve a problem within our own business that we suspected other businesses would also have. With the help of our fmAccounting Link (Xero Edition) solution as well as fmEcommerce Link (WooCommerce Edition) and the power of webhooks we’ve been able to completely eliminate all data entry for our online orders.

The new streamlined process looks like this:

  1. a new order is created in one of our online stores which triggers a WooCommerce webhook to push that new Order to our internal version of fmEcommerce Link (WooCommerce Edition).
  2. this calls a FileMaker script which then pushes the online order to our internal version of fmAccounting Link (Xero Edition). It checks to see if the customer already exists, otherwise it creates a new one.
  3. a staff member does a quick sanity check to make sure everything looks correct and then clicks a button to upload the new Invoice and Payment to Xero.

We’ve managed to reduce this business process from 5-10 minutes to 5-10 seconds –  this has freed up time to be spent on more productive tasks instead of mindless double data entry. Whether you’re using WooCommerce or Shopify for your online store and Xero or MYOB AccountRight/Essentials for your accounting it is possible to integrate all of these with FileMaker in the middle so that new online orders flow directly into FileMaker and then into your accounting software without any more double data entry.

If you would like to discuss integrating your FileMaker solution with your eCommerce system please contact us for a free initial consultation to discuss your requirements. We also have a number of FileMaker integration solutions available if you would prefer to do the integration in-house: