Notifications for Incoming SMS Messages

Databuzz pioneered the sending of SMS messages directly from the FileMaker Platform 20 years ago and fmSMS, our FileMaker solution for sending/receiving SMS messages, has been used since then to send and receive millions of SMS messages by organisations all around the world.

When Claris released the FileMaker API for PHP with FileMaker Server v9 we knew we finally had a reliable way to receive incoming SMS messages as soon as they were sent using webhooks. Essentially the SMS Gateway (e.g. Twilio) would be configured to sent via an HTTP POST a notification to a PHP file containing the details of the incoming message when it was received (sender number, message body, timestamp etc). The php file would then convert that data into a record in a FileMaker table using the FileMaker API for PHP. To users this looked like magic – incoming messages would automatically appear within seconds of being sent and be linked to a Contact record so you could see the history of all sent and received messages.

The only downside of having incoming messages automatically pushed to a FileMaker solution is that it happened in the background, and unless someone was monitoring the Messages/Replies table to see if new messages had been received they might not be aware of these.

Over time customers have been asking for ways to be notified when a new incoming message has been received. We’ve come up with a number of options over the years, each of which have their pros and cons. Some of the options we’ve deployed over the years include:

  • simple email notifications for new messages. These emails could include an fmp url link which users could click to open the FileMaker file and navigate to the new incoming message record. The downside of this is that a lot of emails could be generated if you received a high volume of replies or incoming messages.
  • a calculation field on a layout that is frequently accessed showing a total of messages in the replies table that were not flagged as ‘dealt with’. This also relied on users to frequent the layout and notice this new field (many customers would make this field bold/red etc to stand out)
  • using a dedicated window to show Replies sorted in descending order. This window could get lost amongst the various application and FileMaker windows that users could have open
  • we developed a Chat View that shows messages in style similar to Apple’s iOS Messages app. This was limited to showing the conversation between a single Contact, though it could be modified to just showing incoming messages. It also required a refresh to update the Web Viewer to see if new messages had been received, which was typically done using the Install OnTimer Script which was set to run periodically. The downside of using the Install OnTimer Script is that it can interrupt the user’s workflow (e.g. if they are in the middle of typing in another FileMaker window) and is inefficient as it has to run regardless of whether any new incoming messages have been received
  • for some customers we’ve deployed the technique that can trigger a script on multiple FileMaker Pro clients using the OnRecordLoad Script Trigger when a record is deleted that results in a found set of zero records. This can call a script that shows a new popup style window alerting the user to a new incoming message. Unfortunately this can also interrupt users when they are in the middle of something in another FileMaker window when suddenly a new window appears. It’s also not suitable to sites that receive large numbers of incoming messages.

Recently we’ve been exploring a variation of the last approach for the macOS platform that uses the Notifications feature and AppleScript to display a Notification when a new incoming messages has been received. The notification generated looks like this:

This uses the same OnRecordLoad Script Trigger that is attached to a hidden window that is generated when the FileMaker solution is first opened that only ever contains either 1 or 0 records. Each time a new incoming message is received by FileMaker Server it calls a FileMaker script that updates the table to either add a new record or delete the single record. This then triggers the OnRecordLoad script on any clients that have this hidden window configured. Users then receive a standard macOS notification that displays for a few seconds. The advantage of this approach is that a new FileMaker window isn’t required and if the user is away from their computer they can still see these in their Notification Centre along with all their other macOS Notifications. You can also control through a User Preferences table which users need to receive these notifications so you’re not sending notifications to all users unnecessarily. The FileMaker script to generate the AppleScript only requires a few script steps so can perform quickly – for details on how to create macOS Notifications from FileMaker using AppleScript check out this article from HomeBase Software.

Like all the other methods there are some downsides to this approach, including:

  • it uses AppleScript so it’s limited to macOS users
  • it does require the fmextscriptaccess extended privilege to be enabled for the required Privilege Sets
  • there’s no way to customise the action that is performed when the users clicks the Notification in the Notification Centre. I couldn’t find a way to include an fmp URL that would take the user to the particular record directly – currently it just opens the FileMaker Pro application

Here’s a short video we recorded showing this in action as a new incoming message is received (you can also watch this on YouTube here):

If you have come up with any alternative options for displaying alerts to users please let us know in the comments below. In our next article we’ll look at integrating FileMaker with Slack to generate notifications in a Slack channel when incoming messages are received.

2 replies

Trackbacks & Pingbacks

  1. […] written previously about generating local notifications from FileMaker Pro (for example when a new incoming SMS has […]

  2. […] Part 1 of our series on generating notifications to users for incoming SMS messages we discussed how […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *