Troubleshooting
If something doesn't look right, please get in touch. If you like getting your hands dirty and would like to dig into this yourself, we hope the following walkthroughs will help.
Note, there isn't much to set up for Google or Basecamp sources, so not much can go wrong. Salesforce and FileMaker data sources have a lot of options, though, so you'll see common issues for those sources below.
General Troubleshooting
I see two of each event
If you've created any App Actions, check that the action's "Prevent Default Action" is set correctly. If that's set to NO and your action is using action.callbacks.confirm(); you're essentially telling DayBack to render the calendar twice.
Times down the left-hand side are all random, like 10:08
Visit "Time Scales" in the left-hand sidebar of Admin Settings, and you've likely entered an odd time into one of the settings like "earliest time visible." These values should be in the form HH:MM:SS like 06:00:00 for 6am. If you enter 06:07:00, you'll see odd results.
I see "DayBack is Loading" on my Windows machine.
This is because you're using an older version of FileMaker for Windows. FileMaker users on Windows need to have FileMaker 19.3.1 or later to use DayBack. Update to the latest version of FileMaker and you should be all set.
The column headers in resource pivot views don't line up with the columns
This can happen if your browser is zoomed in or out (not at 100% zoom) in a Chromium-based browser (Chrome, the new Edge). Unfortunately, these browsers don't always zoom table headers the same as the table body, so this can cause the header to be zoomed disproportionately to the calendar rows. We'll try to address this in a future update to DayBack. For now, if you need DayBack to be more zoomed in, a workaround is to adjust your system-wide scaling or use a different browser (Safari, Firefox).
I see a red "Malformed Query Object" at the bottom of the screen
This error can show up if you've left DayBack's field mapping incomplete when you're setting up a new calendar. In that case, finish your field mapping and the error will go away. But it also comes up if you've accidentally created a new calendar. If that's the case, here's how to delete that unnecessary calendar:
Troubleshooting in Salesforce
I'm unable to authorize DayBack
If you're logged in a less than a system administrator, it may be that your user privileges don't include authorizing new apps: you'll want to ask a system administrator for help.
If you are a system admin, Salesforce might just be getting confused between your single-sign-on and sandbox logins. To fix this, you can change the Connected App settings to pre-authorize by profile, and that will bypass the authorization step. Information on how to do this can be found here under "Authorizing Users."
All I see is a frowny face on the DayBack tab in my org
This is likely because your network is blocking the dayback.com domain. To double-check, try and open http://app.dayback.com in your browser. If you don't see a login page, then your network is blocking the domain: ask your IT department to "whitelist" dayback.com, and you'll be all set.
The progress indicator keeps going, and my items don't show up in the calendar
The most likely reason for this is that something in your Field Mapping isn't pointing at a field in your Salesforce table. A common example is that you've mapped to a custom field but haven't used the Salesforce name for the field in field mapping: custom fields will have a suffix "__c" so your field "SomeText" will be named "SomeText__c" in Salesforce and that's the name you should use in field mapping.
I can't create or edit campaigns in DayBack
Modifying campaigns requires that the user is assigned the "Marketing User" permission. Visit your permissions in Setup and see if "Marketing Users" is checked. If not, ask your Salesforce admin to turn this privilege on for you.
Assigned To ID: Owner cannot be left blank
If you see this warning when dragging an item to the none column in resource scheduling, it's because the field you've mapped to Resource will not accept blank values. That's the case for the "Owner" field DayBack uses by default as the resource for Events, Tasks, and Campaigns. You can map this to another field of your own that will accept blank values.
Only System Administrators can see some events
There are some interesting restrictions that Salesforce imposes on the visibility of shared calendars. These are described here, but the relevant fact is that "The 'Related To' and/or 'Name' field must be completed, or the Activity will be deemed Private regardless of other sharing settings (such as Calendar Sharing). For example, even if a user shares their calendar with 'Full Access,' all events that are not associated with another record will be Private.”
Operation Failed: there was an error trying to connect to Salesforce
If you see this error on Salesforce mobile (especially after updating your device), the issue is in the Salesforce mobile app itself. You'll want to log out of the SF mobile app and then log back in to correct the problem.
Operation Failed: There was an error saving the event ... John Smith is not a valid Owner Name
This error occurs when you have manually added a Resource that is not a valid Salesforce User. The Event object's Resource field is mapped to Owner.Name, and this field can only contain Salesforce Users. You will either need to create this Resource as a Salesforce User, or map the field to a Custom text field that can store any text value as a resource name. For more information, please read mapping resource fields in Salesforce.
Salesforce Error: Total requests Limit Exceeded (REQUEST_LIMIT_EXCEEDED)
This error occurs when DayBack or another Salesforce application has exceeded the number of allowed requests for your organization. Exceeding the allowed API Request limit is typically a difficult limit to exceed unless you have a very large number of users, or use a lot of Salesforce Apps that make frequent API requests. If DayBack is the reason why this limit has been exceeded, it may likely be due to a misconfigured custom app action that is stuck in a loop or is using too many API requests. Your Salesforce Admin should start by viewing the API calls in the past 24 hours to assess if DayBack is causing the problem. This can be done by running the API Usage report with the detailed enabled. Here is a document explaining API Request limits.
To restore temporary operation while you assess the problem, we recommend contacting Salesforce support to get a temporary increase in the API Request Limit so that you can resume using DayBack. If a DayBack custom app action is causing the problem, you can grant us temporary access and we would be happy to take a look. To do so, please go to your personal settings and click Grant Account Login Access or Grant Login Access, whichever appears, to grant access to the author of DayBack: SeedCode. Once that is done, please get in touch with our team so that we can log in and take a look.
"You don't have permission to view application DayBack"
This is a permissions issue at the connected/canvas app or VisualForce level and is resolved in Salesforce permissions.
The error occurs, when the DayBack is set to "Admin approved users are pre-authorized" but the user's profile or custom permissions hasn't been added for the DayBack Connected App or VisualForce page.
This can happen at the Visualforce page level, which is less common and at the Connected app level, where you need to specify the Profiles that can see it. The error will say which one. In the screenshot above, it says the "Canvas application (DayBack)", which is the DayBack Connected App, otherwise it will say the "Visualforce page (DayBack)."
For the Connected app you go to Apps / DayBack / Manage and can specify the profiles there. For the Visualforce page, you go to Visualforce pages / DayBack / Security and can specify the Profiles there.
Troubleshooting Microsoft 365
I see a red message "REST API is not yet supported for this mailbox" at the bottom of the screen
This means that the Office 365 REST API is not supported in your Office 365 group. DayBack uses the REST API to be able to query your event data. Details on enabling the REST API in your Office 365 group can be found in the Office 365 support document here.
Troubleshooting Basecamp
I have multiple Basecamp accounts, and DayBack connects to the wrong one
DayBack automatically authenticates with the Basecamp account you're logged into in the browser. If you have a different login, you'll need to deauthorize Basecamp in DayBack, log out of Basecamp in your browser, authenticate with Basecamp in DayBack again, and choose the account'd like to connect to.
If you normally see multiple Basecamp launchpads (accounts) when first logging into Basecamp, then DayBack has trouble knowing which launchpad you want to use. Unfortunately, Basecamp3's API automatically returns the first active bc3 account in your launchpad list when authenticating, and there's currently no way to select a different one through the API. There isn't currently a way to select a different launchpad when using DayBack (or any app that connects through the Basecamp3 API).
At the moment, the only solution would be to remove access to the other launchpad for your Basecamp account so that only one is showing. But, unfortunately, we don't really have any info on Basecamp's plans on expanding their API, so we're constrained by that.
Troubleshooting FileMaker
DayBack Error Messages
Related Field cannot be evaluated from DBk_JSON
This error means that the referenced related field doesn't exist in your event table, the relationship to the related table doesn't exist, or the evaluation context (see step 7) of the DBk_JSON field is set to a different table than in the DayBack calendar settings.
DayBack cannot get the value of the field
This means that a field by that name doesn't exist from the context of the calendar's defined table occurrence. Validate your field mapping to make sure all fields are correct.
This event can't be opened because the id field is empty
This usually means that the field you've mapped for the ID is correct but doesn't contain a value. It may also mean that some disabled fields are still mapped:
- Make sure the field you've mapped to id is set to an auto-enter calc. DayBack doesn't automatically assign a value to the id field, so that must be done on the FileMaker end.
- Make sure any disabled fields are also unmapped (set to a blank value instead of a real field).
Can't find a mapped field or custom field
If your setup is passing field validation in DayBack, but you're still seeing this red error at the bottom of the calendar, please check these three things:
- Make sure any disabled fields are also unmapped (set to a blank value instead of a real field).
- Confirm that the context selected for your DBk_JSON calc field is the same table occurrence name as the table occurrence name you specified for this calendar in DayBack settings "Calendar Info".
- Make sure the table occurrence name in DayBack settings "Calendar Info" is the same in “both” files if DayBack is linked (vs embedded) or if the data is in another file. In other words, your local table occurrence and original table occurrence should have the same name.
Cannot set the field :DBk_Timestamp...
This error means DayBack wasn't able to set this field in find mode on the calendar source's specified layout. This could be caused by one of the following reasons:
- The layout specified doesn't have Quick Find enabled, doesn't allow entering a value into the field specified in the error, or has script triggers that are interfering with the DayBack scripts to query the data.
Your layout should not have any script triggers and doesn't need to have any fields on it. You can use the "Sample Events" layout in the stock DayBack file as a reference for how your layout should be set up. - The FileMaker scripting engine may have run into an issue and need to be restarted. This is usually the case if you're receiving the same error on multiple calendars. Restarting the scripting engine can be done by stopping and starting the database server, or by entering the following command line prompts to restart just the scripting engine on the server:
fmsadmin stop fmse fmsadmin start fmse
FileMaker Errors when Editing events
DayBack forwards any FileMaker errors encountered to be presented to the user in the calendar. Here are the most common errors encountered and how to address them:
Other common issues
DayBack Won't Load (Blue loading bar across top)
There are two FileMaker scripts that may help. Run one or both of these if you just see the blue loading bar but no calendar:
- Go to Admin Settings - DayBack | This will take you to admin settings and reset the web viewer.
- Sign Out - DayBack | Signs you out and takes you back to the sign-in page. More: how to sign out with a FileMaker Script.
If you believe the loading problem is because you've been writing custom app actions that may not function, here's how to get DayBack to bypass them: close the FileMaker file and re-open it while holding down the shift key and moving the mouse back and forth as you arrive at the calendar layout. This will take you straight to DayBack settings where you can turn off your app action by unchecking the box next to "app" below the action.
I'm seeing two of each event
If you've created any App Actions, check that the action's "Prevent Default Action" is set correctly. If that's set to NO and your action is using action.callbacks.confirm(); you're essentially telling DayBack to render the calendar twice.
No events showing (for one or more sources)
The most common cause of events not showing up is that you have some filters applied and no events match those filters. If you're filtering for a particular status (or calendar, or resource) and then create a new appointment with a different status, that event will disappear since it doesn't match the filters you have in place. Clicking "Clear filters" at the bottom of DayBack's filters tab in the left-hand sidebar will bring these events back if that's the case. If that doesn't help, try these ideas:
Go to admin settings and select the calendar you're interested in. On the Calendar Info tab, click "Validate Layout" and "Validate Table Occurrence". Click on the Field Mapping tab and scroll all the way down: click "Validate Field Mapping," correcting any issues you see.
Check for calculation fields that are commented out.When copying the required calculation fields to your file, if your table doesn't have one or more of the referenced fields, FileMaker will comment them out with a /* at the beginning and a */ at the end of the calculation. You'll need to remove these comment markers and then update all of the referenced fields to point to the appropriate fields in your file.
Mapped date field is emptyDayBack will only show an event on the calendar that has a valid start date. Make sure your events have a date set in the field you've mapped to the start date in DayBack.
Incorrect Contact or Project Table Occurrence NamesIf your events are linked to contacts/projects AND your events table is in a different file than the file DayBack is in, be sure the contact and project table occurrence names in DayBack are the same names those table occurrences have in your events file. If you change the table occurrence names in DayBack, be sure to change the names used in Field Mapping and Related records. More details here: Setting up Contacts & Projects.
The event popover is blank
There is a known issue in FileMaker web viewers on Mac: if you maximize or restore the window, you'll need to reload the web viewer or change layouts for the web viewer to resume working correctly.
My events don't show in WebDirect, but they do in FileMaker client
Make sure your scripts are updated to the latest build: DayBack Updates
If your table occurrence has spaces in it, you'll need to quote the table in the SQL query used for WebDirect. Near line 49 of the "Find Events - DayBack" script where the $select variable is set, wrap $table in the Quote function, so it looks like this:
"SELECT DBk_JSON FROM " & Quote ( $table ) & " WHERE " & $where & " ORDER BY " & $sort
Event doesn't update when saving and closing from my own event detail layout in WebDirect
It seems the behavior in WebDirect changed since we first created DayBack, so there's a small script update required to fix this issue:
On line 55 of the "Close And Update Event - DayBack" script, change the line from:
Else If [ Get ( SystemPlatform ) ≠ 4 ]
to just:
Else
Linked Contacts or Project details don't consistently show in the popover
This can sometimes be caused by having no records on the DayBack layout, or more than one record on the DayBack layout, especially if you have any references related to this layout. There should only be one record on the DayBack layout.
To prevent this, you can add a custom menu set with the "Records" menu removed, and apply it to the layouts based on the DayBack table occurrence. This should prevent the DayBack record from being unintentionally deleted or additional records added.
Some of my events don't show in public shares
Windows and High DPI Screens
On Windows systems with a smaller screen and a high DPI (resolution), the calendar text and objects may display very small and unreadable. There are a couple of options to address this, some of which are easier than others.
- Since web viewers are rendered as a web page, they have a separate zoom mechanism from FileMaker's zoom. This means you can zoom into the calendar using ctrl+scroll (or + and -) and it will not affect the other FileMaker objects. This is probably the easiest way to get the calendar objects to render at a higher scale without making your Event Detail window look too large.
- You could try increasing the system-wide Windows DPI scaling, keeping in mind that this will have an effect on all apps. Here's a link to instructions on adjusting the Windows DPI scaling: https://technet.microsoft.com/en-us/library/ff629368.aspx?f=255&MSPPError=-2147217396
- You could add the following to your CSS to adjust the zoom for Windows devices with high DPI screens:
@media only screen and (-webkit-min-device-pixel-ratio: 1.8),
only screen and (-o-min-device-pixel-ratio: 18/10),
only screen and (min-resolution: 180dpi)
{
@-ms-viewport{
width:960px;
}
}
This will only apply to Windows devices with screens showing 180dpi (dots per inch) or higher. You might want to modify the 3 dpi settings (1.8, 18/10, 180dpi) to get the right criteria for when to zoom or not.
For example, on a 40" 4k screen, DayBack looks great by default, so you don't want to resize on that screen. The dpi on this screen is 110.
An 11" 1080p screen has a dpi of 200, so you probably would want to zoom in, but it's going to take some trial and error to get the right number.
Server Timeout in WebDirect
In WebDirect, DayBack submits a request using Perform Script On Server (PSOS) to modify an event. Technically, this is asynchronous, but the client needs to know when the update has been completed in order to properly update the event on the calendar. This check is done in the "Process Web Direct Log - DayBack" script.
If your server is taking a bit longer to process these event updates, you may receive an error, or won't see the "Saved" confirmation after modifying an event. On line 17 of the script, there is an If statement that limits the check to 20 retries. If you're running into this issue, you could try increasing this value to retry a bit more.
If you're needing to increase this value a lot, it's likely that there are script triggers on your file that are unnecessarily running for every PSOS request. This causes these requests to be very slow because each one starts its own session, which is like opening the file. You can increase the performance of these PSOS requests by escaping any unnecessary script steps when run on server using:
Patterncount ( Get ( ApplicationVersion ) ; “Server” )
Troubleshooting FileMaker Server (FileMaker CWP Sources)
Background
The troubleshooting here is for administrators configuring DayBack. Most of this will be looking at the results of tests you can run to examine your config. You'll find this test towards the bottom of the Source Settings screen once you've selected your source:
General Improvements
FileMaker Web Publishing will pull data from every field on your layout, even though DayBack only needs some of the fields in your table. So to speed up your queries and to reduce the possibility that bad data is getting sent to DayBack, be sure that the layout specified in DayBack admin's Source Settings only contains the fields DayBack requires.
What's Wrong?
My server settings test aren't doing anything
If you click "Test Source Settings" and don't get any results, it is likely because DayBack can't see your FileMaker Server at all. Check that the server address is correct and that XML Web Publishing is enabled for your server.
My server settings test are failing
If you get an orange failed icon for the PHP Relay file, it likely means your PHP relay file isn't there or is in the wrong place. It could also be that PHP isn't running on your FileMaker Server.
If you get an orange failed icon that says the DayBack account doesn't exist in your PHP Relay file, it likely means that you have set the variable "$loginByName" to true in the PHP Relay file, and there is not a match for the DayBack account in the if statement to determine the correct FileMaker account.
If you get an orange failed icon on the FileMaker file, there are a few things to check...
Begin by testing to make sure XML web publishing is running. You can do this by manually typing the following into your browser, replacing "serverAddress" with the server address you entered in DayBack's configuration:
https://serverAddress/fmi/xml/FMPXMLRESULT.xml?-dbnames
If you get results in the test above and see your file listed there but got "0" or "1" byte downloaded in your test details, then your PHPrelay file is in the wrong place. Double-check that the location is one of the ones listed here in "Where does the file go?" You can test that you have the relay in the correct location by entering this URL:
https://serverAddress/fmxjRelay.php?test=true
That should return the phpinfo on your server if the relay is in the right spot and PHP is running. Remember, if you connect to dayback.com over HTTPS and your PHP relay / fmserver is only on HTTP, then you will get that error that it couldn't connect to the PHP relay file. So if your relay file is HTTP, you need to log into https://app.dayback.com instead of https://app...
Tip: If you're not getting the correct expected output, such as a file not found or a 500 error, try replacing your PHPRelay file with the downloaded, untouched version. If that works, then your PHP service is functioning correctly. Make sure you've used a plain text editor, as mentioned in our docs here. Also, verify that there aren't any commas or quotes accidentally deleted where the file was edited.
Once you're getting something more than 1 byte returned in test details or results at the URL above, you'll have the PHP relay file in the right place and can make sure the rest of your configuration is correct. If the URL tests above are passing but you still can't get the PHP file to work, AND you're using "localhost" in your PHP file, it could be that your server/hosting provider has settings preventing that: try replacing "localhost" with your server IP address.
Check the test details to see, for example, that the filename you entered is one of the file names on your server. Also, only files with XML web publishing enabled show up, so make sure it's enabled for your file.
Same thing with layouts: check the test details to see which layouts DayBack can see in your FileMaker file. It's likely that your spelling is wrong (remember that these entries are case-sensitive).
My server settings test passed, but I can't see any events
If you have green lights on your tests but no events, I'd check the fields mapped to the "TimestampNum calc start" and "...end" fields. Are these calcs defined to return numbers? Note that if you paste in our example field definition, you need to point parts of the "Let" statements at your own date and time fields: double-check that you picked the right fields from your table.
The TimeStampNum Calc End field is required to be mapped, even if you've disabled it in the settings. If you don't enter a valid field, you will receive the following error when loading the calendar: "There was an error retrieving FileMaker events: 4 - Command is unknown"
If you continually see the 3 loading dots in the calendar header, make sure that the FileMaker user assigned in the PHP Relay file has access to view all of the fields on the source's layout. This includes fields on the layout that are not used for DayBack Online and any hidden fields that may be off to the side of the layout. If those fields are necessary for a user interface, it's probably best to create a new layout, specifically for DayBack Online.
I can see some events, but they're all on the wrong date or for multiple days
This likely means that your "TimestampNum calc start" and "...end" fields described above are returning numbers but the calcs themselves aren't correct or only one of them is (only the start or end calc).
I can see bars for my events but no text
Double-check the field mapped to "Event display calc" and make sure it's returning a value on your FileMaker layout.
None of my events have any colors
You'll see event colors when the values in the field you've mapped to "Status" match the values in the calendar's Status Filters (these are on the Filters tab of the calendar sidebar).
If you do not see colors, it's because the field you've mapped doesn't contain one of the status values in the sidebar.
Some tips for errors you might see when dragging events around or editing them...
Errors when editing events
Error 102
102 means a "field is missing," so it sounds like DayBack Online is trying to write your event back to FileMaker but can't find one of the fields it needs. This is probably because one of the fields you've mapped got removed from the layout you specified, or the field got deleted from your table.
I'd return to Source Settings and re-run the tests towards the bottom of the page to see which field(s) this might be. You can also revisit the layout you specified (probably "Source No 1" if you're using DayBack for FileMaker also) and make sure the fields are mapped to fields in your table.
Error 201
"Field Can't Be Modified." Make sure that the fields you mapped are writable, that is, not calculation fields. Of the fields DayBack Online asks for, only the three that have "calc" in the name may be calculated fields.
If you are using a calc field for any of the other fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead. You might also check that the account you've set up in the PHP relay uses a privilege set with write privileges to all the fields you mapped.
Error 500 "There was an error saving the event, and your changes will be reverted: 500 - Date value does not meet validation entry options." When you see this, it likely means that the Date Format in your Source Settings doesn't match that in your file. To begin with, the format needs to be all capital letters like MM/DD/YYYY. To be sure the setting here matches your file, click on "Test Source Settings" then "Show Test Details" and scan down through the results until you find "Fields Available on Layout..." below that, you'll see the date format of your file. It likely looks like this:
"DATEFORMAT": "MM/dd/yyyy"
Then make sure that the settings you've entered into DayBack are the uppercase version of the format you find here.
Error 959
Error 959 lets you know that a dependant technology has been disabled on the FileMaker Server. DayBack Online depends on the XML and PHP web publishing technologies. Starting in FileMaker 17, XML and PHP web publishing must be enabled using the command-line interface. Details on how to enable XML and PHP web publishing on FileMaker 17+ can be found in FileMaker's docs here: https://fmhelp.filemaker.com/help/18/fms/en/index.html#page/FMS_Help/config-webpub-php.html
Error 8003
Error 8003 is returned when the event record you are trying to modify is locked for editing in FileMaker. If you receive this error, someone else is actively modifying that event record. Therefore, it's probably best to revert the changes and refresh the calendar to make sure you see the most recent data before editing that event.
None of that helped? Please get in touch.