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.


  • 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. =)

Featured Posts

Follow Along

Stay up to date with the latest news & examples from SeedCode


  • Is there a way to trigger the detect conflicts script every time the calendar refreshes? I edit events from another layout, so when I create an event, commit it, and return to the calendar the conflicts are not being detected. I love the feature, but would like to make sure conflicts are always being detected.


    • seedcode

      *This* script won’t work that way: it runs in the context of a particular event, so my advice would be to run a variant of this when you’re editing your events: whichever layout you’re editing them on. Of course, our script is designed to run from within the calendar and uses the $$variables set within DayBack: you’d probably want to use this as a template for your own script if you wanted to check for conflicts from your own layouts. If you want help making your own version of this script, just email us and we can do this as part of an implementation package. (

  • Great stuff – although I just developed a custom overlap-checker-script which seems obslete now 😀

Leave a Reply

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

Check out some of our other posts ...

Improved Resource Selection

We’ve made some big changes to how you filter and assign resources when editing events in DayBack. These changes will make it much easier to

Suggesting Appointment Slots

Show Available Slots that Match Multiple Criteria Schedulers often look for gaps in their schedules to find the open resources for each opportunity. But sometimes,

Introducing Draft Settings Mode

Following up on this idea that people stretch themselves when they feel a little safer, we’ve been very focused on the customization experience for DayBack

New Longer Timescales for DayBack

Resource Scheduling Swimlanes You can now extend the pivoted scheduling view in DayBack to show items by week instead of solely by day. This lets



Stay up to date with the latest news & examples from SeedCode

© 2024 SeedCode, Inc.