If you have a distributed team, you’re painfully aware that there is no built-in support for switching time zones in FileMaker. There’s easy way to have your time fields translate themselves into a different time zone.

DayBack changes that.

By default, DayBack shows events on the calendar at whichever time is entered into your time field. But you can mod the calendar so users can select the time zone in which they want to view their schedule. Edits made in this mode are saved adjusting for the time zone they’ve selected. The mod takes advantage of a Moment.js enabled selector in a web viewer, along with some field and script changes. Detailed instructions and an example file follow below.

Here’s a video of the mod switching time zones in FileMaker:


How It Works

The most important thing to understand when implementing something like this is that the records will need to be saved in a specific “reference time zone”.

In an ummodified calendar, no matter where you are located, when you schedule an event in DayBack for 12:00 PM, that field will be saved as 12:00 PM in the record. A “reference time zone” is your team’s agreement as to what that “12pm” means. For SeedCode, we have users in multiple time zones, but our reference time zone for events is Pacific. The users living outside of the Pacific time zone have just had to manually adjust their events accordingly… until now! Most teams already have such a reference, even if it’s only in your head. In this mod, you’ll make it explicit.

After implementing this mod, if you are in Pacific time and your “reference time” is in Eastern, the field on your event record will actually be saved as 3:00 PM. =)

There’s a bit of work to implement this into your calendar, but you should be able to get there by following these instructions closely. If you run into any issues, please reach out to us.

Downloading the Example File

First, download the example file, try it out, and see if this time zone behavior is right for yout team: DayBackTimeZones

You’ll copy a few things out of this example and paste them into your file following the instructions below. You’ll add a new web viewer selector, a layout, scripts, and some DBk_WebViewerSource calculation additions to your file.

Read Full Article →

FileMaker makes getting an accurate latitude and longitude from an iPhone or iPad super easy. Say you want to update a properties’ exact location in ProMaps when you’re on site: why not get it automatically from your device?

Here’s a video of this in action:

Implementing Geolocation in FileMaker Go

This is easily implemented by adding a small script to your solution. Here’s a screenshot of the script we’d add to ProMaps (the only thing specific to ProMaps here is the location field which could be any text field in your solution):

FileMaker Script to Update Geolocation on iPad

The most complex part of this script is formatting the returned value into the comma separated “latitude,longitude” value required for the gm_GeoLocation field value, so I’ve pasted the value for the Set Variable step on line 20 here:

Now, you can call this script from a new button placed on your property detail layout. Alternately, you could call it automatically when uploading a new picture to your property. To do this,  add the highlighted lines in the screenshot below to the “Process Image…” script in ProMaps.

Geolocation in FileMaker Go for iPad

Hopefully, this example helps make your workflow with ProMaps even smoother.

Demo and Help

If you’d like to try out ProMaps, which allows you to display your properties on a Google powered map, including filtering and routing features, please download a demo at our ProMaps product page.

If you’d like help customizing this mod, or creating other mods like this, feel free to contact us and we’ll get you on the schedule.

You can add buttons and scripts to your calendar events with DayBack’s custom actions. These let you modify how the calendar works so folks can take action right from within the calendar. Now you can add these actions to shared calendars as well. This means you can do things like:

  • Link to a discussion about the event
  • Complete a form when someone clicks on a shared event

The short video below demonstrates both of these actions.

The first example adds a button to the PauseOnError calendar, so users can get more detail about the event. The second example hijacks the “click” behavior to bring up a confirmation form when a user clicks on the event.

Custom actions are either simple URLs or JavaScript. You can download the code for these two example actions here:

Documentation and more examples can be found here (docsexamples), or get in touch: we’re happy to write actions for you.

Check out this FileMaker calendar of the public events at the Hammer Museum in LA:

Julia Dzwonkoski of AngelCityData designed and built this, adding a custom sidebar to the left of DayBack calendar. This sidebar, which contains a list of current exhibitions, is made solely with FileMaker layout objects and calls FileMaker scripts in DayBack to manipulate the calendar’s filters. The result is a very elegant calendar that’s really easy to filter.

Very cool, Julia! And thanks for the screenshot.

See more examples of custom filters here: custom sidebars for DayBack Calendar.

Customizing the Go To buttons in DayBack for FileMaker

In the DayBack for FileMaker popover, the blue arrow buttons next to Contact and Project run a script that opens the related contact or project in its own layout. This script can be customized to perform other actions, rather than just opening the related contact or project.

In this example, we’ve customized DayBack for a customer to allow multiple contacts selection. Since each event could now have multiple contacts, rather than going to the first related contact, we customized the “Go To Related Record From WebViewer” script to change the action of the blue arrow button next to contacts. In this video, we show how this is done and what it looks like.

If you have an idea of how you’d like to customize the action of these buttons, feel free to reach out to us and we’ll be happy to help out!


Here’s an example file you can use to print web viewers in FileMaker 16. We use DayBack Calendar as an example, but you can use these scripts in your own file too. The scripts manage the window sizing which can make printing web viewers tricky. They also use the free ScriptMaster plugin to make PDFs for printing since FileMaker 16 no longer supports printing web viewer content on Mac.

In FileMaker 16, we lost the ability to print the web viewer, whether using Preview mode or Save/Send As PDF. This isn’t always an issue: in many cases, it may make more sense to create a dedicated print layout or sub-summary report to print calendar data. Often this is the only way to print all the text of an event. But sometimes it is best to print web viewer itself. For example, DayBack’s Month, Horizon, and other views would be too tough to replicate without the web viewer for printing.

Thanks to different plugins, we actually can print the web viewer in 16 — by taking screenshots. Once a screenshot is taken, you can insert it into a container field and Preview Mode and Save As PDF will have no trouble printing that image in a container. (Thanks to the FileMaker community at this thread for providing the idea to use screenshot functions as a workaround to printing the web viewer in FM16!)

Here’s a video of this in action:

If you’d like to grab that file and get to work, here it is: DayBack_PrintWebviewerExample

Printing FileMaker Web Viewers: Looking Closer

And here’s a closer look at the first script shown in that video: Read Full Article →

FileMaker partner aACE Software customized DayBack Calendar for their vertical market ERP solution: their customers love it!

“The results of implementing the calendar have been overwhelmingly positive. Everybody benefits from “real-time” scheduling allowing us to see down to the nth degree what resources are available for any project at any time. The calendar solved the lack of visibility issues we were having.” – Jimmie Wolfe, Director of Field Operations, Gable

Check out the details in the success story that aACE Software posted on their site: aACE + DayBack Calendar

Customize FileMaker Calendar Success Story

Customized to fit seamlessly within their app

We really like what aACE was able to do here and that they could customize DayBack to fit seamlessly within their own app. It looks great! And it’s clear they listened closely to their client: the customer loves what they’ve done.

Here are some links to help you start customizing the calendar:

The aACE+ DayBack calendar integration saved the day. Click To Tweet

Big thanks to Caitlin, Michael, and Brian at aACE for sharing their customization and publishing their client’s feedback! Congrats on such a great success story.

DayBack is designed for you to customize. Learn more

This is the fourth post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. These techniques have made a big impact at SeedCode and we hope you’re inspired to incorporate some of these into your own work.

We Record our Debt

Recording Technical DebtIn Documenting our Decisions, we talked about “creating a path from the customer’s cases (or feature specs) to the code that addresses them—a path that our future selves can follow.”

Similarly, when we take shortcuts, we record the path not taken as a new case. Technical debt taken on intentionally can help us get there faster, just like debt financing can help a company grow faster. Debt taken on invisibly is like a variable rate loan—not good—and in both cases it’s the unknown that makes all the difference.

What We Do

  • We know there is a better way to do something but we’ll defer hardening until our work is validated by the customer. Instead of premature optimization we create a case for the optimized approach and ship what we’ve got.
  • We can’t finish a feature, or can’t get to the edge cases, so we create a case for what’s undone. Sometimes the isn’t debt, but just “Friday”—I find myself making cases at the end of the week or end of the day for what I wanted to get done but couldn’t. Come Monday, it takes less time to get back to work because I know just where to pick up. This is a version of Hemingway’s dictum to always stop when you know exactly what you’re going to do next.
  • When we’re doing QA videos we create cases for any bugs we see that aren’t going to be fixed IN the video. By creating a case for anything weird we see, we can deflect the hard work of deciding when to fix it, or who’s going to fix it, or even to fix it at all. Without having to worry about that we can pay attention the nuances of the bug, and tag the case with any customers who’ve been affected.

Why This Works

Recording instead of coding lets us observe our work without the pressure to fix it. I’m just capturing the bug, not also trying to determine how big a change it’s going to be. This means we see more–and see more consequences–than if we were just looking for how to fix something.

Recording instead of coding lets us observe our work without the pressure to fix it. Click To Tweet

This also works hand-in-hand with delivering small chunks. Think of a feature as hub with several spokes. The hub might be creating a new contact. The spokes might be checking to see if the contact already exists and then merging the new contact with that existing record. Would an existing contact count if they were archived? What constitutes a “duplicate” contact, is it an exact name match or a close name match at the same domain? And who is allowed to create new contact anyway? Who is allowed to merge?

It’s much easier for me to create cases for these “spokes” (to treat them as debt) than to account for them in my code. If my code is the only place to capture these spokes then I’ll capure very few of them. Further, the deferring part of technical debt means I embargo the spoke cases until the hub has been validated by our customer: and that’s key. Because if we get something wrong about the hub, I’d rather just rework the hub than rework the hub and all it’s spokes.

Recent Ideas

Defering the spokes until the hub is validated is proving to be key. It mean we’re less resistant to chages suggested by the customer and, importantly, less resistant when the customer wants to pivot to a new problem: we’ve already got the landscape of this problem documented.

This was probably the part of my DevCon session that sparked the most… “discussion” =) This is the third post in a series that formed the basis of my 2017 DevCon session on Increasing Code Quality While Staying Lean. Check out the first post for an introduction to the series. This series describes techniques that have made a big impact at SeedCode and we hope you’re inspired to incorporate some of these into your own work.

We Break Things into Small Chunks

Of all the things we do, this probably has the widest application. I think of this when I’m replying to a customer’s email, when I’m designing a new feature, or writing up the cases for what’s to be done in a sprint. And the more I keep this in mind, the better things go.

Here’s what we do:

We deliver every 5 or 10 hours of code.

For large projects, we deliver every week.

Deliver means deploy: putting code into production with data migration and everything.

Break things into small chunks & deliver as they're done--so we don’t outrun our understanding of the problem. Click To Tweet

We do not listen to a client for 2 hours then head into the desert for 4 months to build their software, hoping they like it when we return. That is not how great software is made. Instead, we break things into really small chunks so we don’t outrun our understanding of the client’s issues. And, by delivering small pieces of work more often, that work gets validated quickly so clients can easily course correct. Read Full Article →

The latest in-app update to DayBack lets you style events in the calendar. You can use this to add icons, introduce a second color, or treat events differently when they contain certain keywords.

DayBack already let’s you use a FileMaker calculation to determine how each event is displayed above. Now you can include styling in that calc. New documentation contains screenshots and calculations for each of these examples:

  • Use colors to indicate which truck or team is assigned to a particular event (this lets you color code the calendar by status and by resource).
  • Change the background color or intoduce a gradient based on a calculated field.
  • Add CSS classes to indvidual fields to get more control or change their style on different calendar views.

Add this to Your Copy of DayBack

Styling is available in the latest in-app update. Just click “Account Settings” in the Settings tab of the left-hand sidebar, then click “Check for updates.”  If you’re new to those, you can see how they work here: In-app updates to DayBack Calendar.

If you’ve purchased DayBack Calendar on a monthly or yearly subscription, you can download in-app updates for the life of your subscription. But if you purchased DayBack outright, your free updates end after the first year. You can purchase additional years for 25% off during our year-end sale.

DayBack Calendar
DayBack's 30-day trial is unlocked so you can customize it and integrate it with your files.
Download DayBack and we'll send you a couple short emails with tips on how to modify it and use some of the coolest features.
Thank you! Please download: DayBack Calendar
Need More?
SeedCode tips & example files in your inbox
Need More?
SeedCode tips & example files in your inbox
Want More?
Be the first to see articles and tips like these
Download TimeZync and we'll send you a couple short emails with tips syncing your FileMaker Go files.
Thank you! Please download: TimeZync
Want More?
Be the first to see articles and tips like these