Preventing Conflicts in DayBack for FileMaker 19

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.

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:

Add Conflict Detection to Your File

These instructions apply to DayBack for FileMaker 19. If you’re looking to add this to DayBack Classic, head over here for those instructions. Instructions for preventing conflicts in DayBack for Salesforce can be found here: conflict detection in Salesforce.

Begin by downloading the script here. That’s an example file containing just the changes you need to make to your FileMaker scripts, including the new “Detect Conflicts” script.

Next, import this new script into your calendar file: open DayBack–or the file you’ve added DayBack to–then open Script Workspace, and from the Scripts menu in FileMaker, select “Import.” Import the “Detect Conflict” script only.

Once that script has been imported, edit the script named “Create Edit Delete Event – DayBack” and add the following snippet just before the record is committed toward the bottom of the script. You can manually enter these lines or find this snippet in the file you downloaded in the “Create Edit Delete Event – Additions Snippet” script. Just copy and paste the contents of the snippet to your existing script.

That’s it. With that new script and those new lines added to the “Create Edit Delete Event – DayBack” 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. However, the layout used to show conflicts will be the layout you’ve specified for your source. Once you add this to your file, feel free to use literal field and layouts names if you want to change the script’s behavior. You can use the ‘$table’ variable to help determine which layout to open.
• The “Detect Conflicts” script contains some placeholder lines (they’re commented out, starting at line 48) 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 added to “Create Edit Delete Event – DayBack” 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: including it in the IF() statement above will prevent edits to “A” from showing the conflict.
• You could take this script further by implementing a “notified” flag so users aren’t warned about the conflict after they’ve accepted it once, 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. =)