Showing Conflicts in DayBack Calendar for FileMaker

DayBack Calendar does a great job visualizing conflicts in your schedule. But sometimes you may want to alert users when they’re creating a conflict that they may not see.

We’ve created a simple script you can paste into your copy of DayBack Calendar to help notify users when they’re creating a conflict. Here’s the script in action:

[ba-youtubeflex videoid=”xZCajTfEPBA”]

Adding this to your file

Note. These instructions are for the older calendar, DayBack Classic. If you’re using the newest DayBack for FileMaker 19 and higher, you’ll want the updated instructions and example code here: Preventing Conflicts in DayBack for FileMaker 19.

Begin by downloading the script here. That’s an example file containing just the new “Detect Conflicts” script.

Next, import this new script into your calendar file: open DayBack–or the file you’ve pasted DayBack into–and from the Scripts menu in FileMaker, select “Import”. Once that script has been imported, edit the script named “Create Edit Delete Event ( SourceNo, Operation ) { Hide, DateStart , DateEnd , TimeStart … }”.

Scroll towards the bottom and create the lines shown in blue below. Here is the calculation to use for that first IF() line:

not IsEmpty ( GetField ( $$sc_SourceTableOccurrenceName[$sc_SourceNo] & "::" & $$sc_FieldForResource ) )

That’s it. With that new script, and those new lines added to the “Create Edit Delete Event…” script, users will be notified whenever an edit to an event–or a newly created event–overlaps with another event having the same resources.

Notes

• The script does not test for conflicts if the event being edited has no resource–though you can change that by altering that IF() statement above.
• The script currently only tests for overlaps within a single table: the same table as the event being edited.
• All-day events sharing the same resource are also considered to be conflicting.
• The script is completely abstracted as far as field and layout names go. Once you add this to your file, feel free use literal field and layouts names if you want to change the scripts behavior… provided you’re using a single source for your events. If you’re using multiple sources you may want to keep things abstracted so the script works with any source.
• The script contains some placeholder lines for records you may wish to omit from conflict consideration: in these placeholder lines we omit records where the status is “pending”, for example.
• You may want to add this test to the IF() statement shown above as well as including it in the “Detect Conflicts” script– the reason is that “Detect Conflicts” will return any conflicting events that overlap the event you’re editing: so you may be editing event “A” which, because of its status does not count towards conflicts, but in the same time frame events “B” and “C” conflict with each other. In this case, including your status test only in “Detect Conflicts” will return a conflict in this case, including it in the IF() statement above will prevent edits to “A” from showing the conflict.
• You can take this script further by implementing a “notified” flag so users aren’t warned about the conflict after they’ve accepted it one, even making that flag user-specific, if you wanted to. If you’d like our help extending this script, sign up for an implementation package, and we can make the changes for you, or coach you through making them yourself.
• For more on resource scheduling in DayBack, including more videos, check out resource scheduling in our docs.

We hope this helps make your resource scheduling a little easier and stops conflicts from sneaking up on you. =)