Is this your DayBack story? You have users who are primarily using one calendar view for a long time, and another user updates an event. In a busy scheduling environment–like a call center–how does everyone know that something has changed? Normally other users won’t see these changes until they change a filter, change their view, or click the calendar’s refresh button. This can slow folks down or poorly schedule a particular resource or timeslot thanks to out of date information.
Listening for Other Users’ Changes in DayBack for FileMaker
We recently had an opportunity to modify a customer’s DayBack for FileMaker 19 to automatically refresh any modified or deleted events for other users viewing the same data. Imagine – the front desk receives a call from a customer who needs to change an appointment to later in the day. For staff in the back office, this is reflected in DayBack just seconds later with no user interaction required. This is a game-changer for our customer, and perhaps it will be for you as well!
We’ve uploaded a simplified version of what we created that you can paste into your own deployment of DayBack (example file and instructions follow below). Here’s a short video of this customization in action:
How It Works: Execute FileMaker Data API
When a user makes a change to an event, a field on that record captures the host’s current timestamp of when the modification was made. By using the host timestamp, we can ensure that the modification timestamps are consistent, regardless of the time zone any individual user may be in. An on timer script will run for each user, and if it finds that there are events that have been modified, it will update the display of these events.
We are using the cool “Execute FileMaker Data API” script step to query the event records and determine which records have been recently modified. This allows us to query the data without pulling focus away from the user. Additionally, there is no need to open hidden windows or to create additional schema within the table and relationship structure. To learn more about this script step, and it’s potential, check out this post by Geist Interactive.
This works seamlessly because DayBack has an API to refresh individual events without redrawing the whole display and causing the screen to flash. The FileMaker scripts in this example call this routine in DayBack when they find updated events.
Note. If you want to refresh an unattended calendar, like a sign or a dashboard, consider putting DayBack into kiosk mode.
The example file below does not handle deleted events since there are several ways to approach this depending on your archiving and deletion rules. (Instead of deleting events, we recommend marking events as “archived” and then filtering them from DayBack under the hood.) Please feel free to contact us if you would like to discuss the options that may be best for your unique situation.
Add This to Your DayBack
To implement this refresh behavior into your own file, please download the example file linked here: Refresh Events Sample.zip. Below are the steps to implement the changes, as well as some further notes. If you would like us to help with any step along the way, please don’t hesitate to reach out.
Add one field:
In the Sample Events table, copy the “LastModifiedHostTS” field and copy it into your events table. Notice that this is an Auto-Enter field, which Replaces Existing Values.
Copy four scripts in the Refresh Folder from the example file:
Copy these three scripts into your file: “Install Refresh Timer”, “OnTimer Refresh Events DataAPI”, “Stop OnTimer”, and “Update Events on Calendar – DayBack”. The “Stop OnTimer script” is optional, and simply allows you to stop the time script if needed (particularly useful if you are in “developer mode” making edits to scripts).
Set an “On First Window Open” script trigger for the file:
Go into File/File Options and then select the Script Triggers tab. If it is unchecked, check the box for “OnFirstWindowOpen” and apply the “Install Refresh Timer” script. If your file already has this box checked, you can add a Perform Script step into your existing script.
Add a field to the Sample Events layout:
On the Sample Events layout, enter into Layout Mode, and place the DBk_JSON field onto the layout. You do not need any other fields and ideally you will keep this layout as empty as possible. If you prefer to create a new layout, or if you have changed this layout name in your file, you will need to reference the new layout/name in the “OnTimer Refresh Events DataAPI” script on line 12, changing “Sample Events” to your layout name.
That is it! The next time your users open the file, they will be able to stay up to date as events are updated by other users! Here are a few other notes:
- The timer is set to run every 5 seconds in the sample file. If you would like to change the frequency of this, you can do this in the “Install Refresh Timer” script. Please note that if you do change the time, you will also want to change the search criteria on line 9 in the “OnTimer Refresh Events DataAPI” script.
- Although we are using the Data API script step, these calls do not actually go against your Data API data limits for your account, and no modifications are needed in your security settings.
- If you have events in multiple data tables, the steps above can be expanded so that all of your modified events are updated at once. The “Update Events on Calendar – DayBack” script handles this seamlessly.
- If your DayBack calendar is embedded into your main file, you may want to start and stop the timer based on the DayBack layout loading.
- This refresh behavior is currently only available for DayBack for FileMaker 19, and unfortunately, is not available for DayBack “Classic”. Interested in learning more about updating? Please contact us for a demo, and for any questions that you may have.
4 Comments
Hi,
This is an old post, but I just updated to FM19, but I’m keeping for now the Dayback classic, did too many custom changes to redo it all again, at least for now ! I’m very satisfy with that version, it does what I need.
So on FM19 with Classic DayBack, all I have to do is to set a script timer for the fresh ? Or I can refresh only the event that was changed in real time ? Not sure I get this part.
I haven’t found a specific post for that on Classic running FM19.
Thanks,
I apologize for the late reply, Jean-Francois. Unfortunately, this refresh behavior isn’t available in DayBack Classic.
This looks fantastic. Can it be integrated to work in the ‘Classic’ versions easily?
Sorry for the late reply, Terri! You could customize this to work in DayBack Classic using a slightly different approach. If you’re not yet in FileMaker 19, there is no Data API script step for you, so you’d use Execute SQL instead (another way to retrieve data without needing to open a new window). And the method to refresh the calendar when you’re done is different in Classic.
The big difference is that in Classic you’d likely want to see if any events are changed and, if so, trigger a complete refresh, rather than what Ann is doing in DayBack for FM19. In the new DayBack, Ann is quietly injecting the changed events into the current display. Ann’s method is *very* fast whereas doing this in Classic would be asking for more data from your FileMaker Server every time there is a change.