Custom App Actions

Custom app actions let you change core behavior about DayBack. This is useful if you want to change what is shown before the calendar is loaded or to add core features to the calendar itself. Unlike button actions and event actions, app action run when an app-level event is triggered.

Uses for app actions

App actions change core behavior, such as the loading of resources, statuses, calendars, or events. You can intercept navigation changes, such as switching calendars, bookmarks, or views. You can also intercept changes to status and resource filters and the rendering of events.

DayBack's behavior can be customized based on the role of the current user. For example, an app action can load a user-specific list of resources, statuses, and calendars that are relevant to that user. You can also make certain events read-only or hidden based on the user's role. If you have hundreds of resources, you can dynamically pre-load your resources and organize them in folders. In the screenshot below, the resource folders and all the equipment within each folder are pulled from the user's Equipment object in Salesforce. 

Extending DayBack with 3rd-party integrations

App actions give you total control over DayBack's behavior. You can extend DayBack using JavaScript and any 3rd-party APIs. Integrations allow you to pull in data or features that fully customize your scheduling workflow. If you have a 3rd-party system that you'd like help integrating, our integrations team is available to help. 

Here is an example of an action that adds route and distance calculation using the Google Maps API. Check out our DayBack Extensions Library for a full list of 3rd party integrations that DayBack supports today. 

Launch actions from a custom menu

When DayBack first opens you might want to add an action to insert some buttons into the sidebar or add buttons that open other apps, control your thermostat, or anything else you can dream up. You can add a custom button launcher like in the screenshot below. Custom buttons allow you to lunch your own actions, run FileMaker scripts, load commonly used bookmarks, or perform multi-update operations on the selected events.

Installing an app action

Creating a new action is pretty easy:

1

Head to the Administrator Settings. Click on "App Actions" in the left-hand sidebar towards the bottom.

2

Scroll down and click on "Add New App Action". Give your App Action a name, and pick the trigger for your action.

3

Paste the code you'd like to execute in the box labeled "JavaScript". This is obviously the tricky part--writing the action itself. If you're not sure how to configure or modify one of our custom app actions, or are not comfortable coding one yourself, feel free to get in touch and ask for help. We're happy to help. 

Examples

Set the currently-selected resource filter to the currently logged-in user

When you first open DayBack, the calendar will load with your previously-selected resource filters enabled. If you haven't logged in before, DayBack will load all events available for the given date range. If you want DayBack to load only your specific events when you log in each time, you can use this app action. Once installed,  it will de-select all previously-selected resource filters and set only the filter that matches your current username: SelectResourceAsUser.js

Set specific calendars to read-only based on the currently logged-in user

By default, all calendars are editable by all logged-in users. This action will make normally editable calendars read-only for specified users. You can configure the accounts and calendars in a configuration section of the following app action: readOnlyByUser.js

Retrieve a list of permitted calendars from FileMaker

DayBack can retrieve a list of permitted calendars directly from FileMaker based on your rules. The following action is a great example of how to retrieve information from FileMaker and pass it to DayBack for use within app actions. The action runs a script in your FileMaker file to retrieve a list of permitted calendars. It then filters DayBack's calendars against this list and only shows those calendars named in your FileMaker script. The app action requires a FileMaker script named "Get My Calendars". If you like, you can change the name of this script inside our sample code. Your script must return the desired calendar names as a JSON array as the script's result. See your bundled script "Sample Resources - DayBack" for an example of how to do this. Here's the On Sources Fetched action you'll add to DayBack: CalendarNamesFromFileMaker.js

Set filters based on the current view selection

By default, all of your resource filters stay the same when you switch between views. If you'd like to change filters when switching views, you may use this Salesforce-specific action. When on a resource view, the current user and all users in their folder will be selected. On all other views, just the current user will be selected. This sample code is easy to modify for any custom scenario: setFiltersByView.js

Sort the calendar list in a specific way

DayBack will display your list of calendars in the order you have mapped them or in the order in which they are sorted within Google. If you'd like to customize the display order, this action lets you define the order in which calendars should be listed on DayBack's sidebar and in Horizon Breakdown by Calendar view. This action can be combined with other actions to show a sorted list of calendars based on the calendars available for each user: SortCalendars.js.

Create or pull resources from Salesforce or FileMaker

By default, the list of resources in the DayBack sidebar has to be created by hand. However, the list of resources, resource folders, as well as skills, and attributes of a resource can be pulled dynamically from Salesforce or FileMaker. 

The Salesforce version of this action queries for one or more objects to create a list of resources and put them in folders based on the supplied criteria. You can also define custom sort criteria if you'd like to sort resources in a specific way: loadResourcesFromObjects.js

The FileMaker version of this action runs FileMaker scripts to build the lists of statuses, resources and folders. Check out our instructions and examples of how to get resources and statuses from FileMaker.

Open DayBack on today's date

By default, DayBack will open to the last date you were viewing. This action opens DayBack to the current date. The action can be set to work on just mobile or run in all contexts: openOnToday.js

Set the date to the current Monday when landing on specified views

When toggling between views and various dates, it can be helpful to always start the current view on a certain day of the week, such as a Monday. This action will detect the selected view and set the date in focus to the current week's Monday. This is useful for making sure resource views always show the full current week from the start. Default views are Resource Schedule, Resource List, and Resource Pivot List. However, any views can be specified: setToThisMondayOnViewChange.js

Add a timezone selector

By default, DayBack will show events in your computer's time zone. It can be helpful to switch time zones, however. This action adds a timezone selector to DayBack's left-hand sidebar under the Settings menu. You can set it up to automatically view events in a specific time zone or to automatically set the timezone to the user's current location. The current timezone will be displayed to the right of the date when the timezone configuration menu isn't open. Your user can quickly change the timezone they'd like to view by selecting it in the dropdown. Here is a list of available timezones which you can configure for your dropdown. Click here for an overview of advanced timezone support. Click displayTimezoneSelector.js to download the app action code. 

Open DayBack to a default bookmark

By default, DayBack will open to the last view that each user had open. If you'd like the user to start off with a specific set of settings, you can configure them as a bookmark. You can then set this bookmark as a system-wide or user-specific default. The following post explains how to load a different bookmark on startup depending on who's logged in: Default Bookmarks for Each User

Add a keyboard shortcut to select all events

This action adds a keystroke listener. It will select all events on the screen based on a key combination. The default key combination is Shift-A, but this can easily be configured to another combination. This type of action is useful for performing multi-select operations on the events. It is written to only fire when a user is not actively editing text in a select box. This means you can still type a capital A using Shift-A without triggering the key combination. In FileMaker environments, the command(meta) and control keys do not work as modifier keys, since these tend to be reserved for FileMaker functions: selectAllEvents.js

Automatically filter for resources that have events in the current date range

If you are in a resource-specific view, DayBack will show a breakdown of all of your events by resource. However, not all of your resources may have events. This can cause you to scroll through a lot of empty rows or columns on the calendar. This set of actions adds a new button in the bottom right of the calendar. When clicked, it will clean up your screen by toggling the resource filters for only the resources which have events scheduled within the specified date range. This action will work in all resource-specific views as well as horizon view with breakdown by resource enabled. Here's a short video of this in action. The download includes three parts - an After Calendar Rendered app action, After Events Rendered app action, and CSS additions. You can download the code here.

Embed a view of the calendar on your Salesforce homepage

This action will allow you to embed a mobile phone-style view of DayBack as a Visualforce Area Homepage component. This app action triggers DayBack to apply its mobile phone stylesheet when loaded DayBack in an embedded frame. The stylesheet hides certain screen functions to enable a simplified view. You can embed this as part of Visualforce Area Home Page Components: DayBackMobileDesktop.zip. The same method can be used with FileMaker if you'd like to embed the mobile view within a smaller view viewer. To load the mobile view, add the following string to the list of URL parameters that load DayBack in your web viewer: &extension=ChromeV1

Add a custom button to the Salesforce mobile DayBack view

By default, the mobile phone view in DayBack doesn't have a home button by default. But if you want to add a custom button to mobile views, you can do so with this action. You'll want to customize the text of the button and what you want it to do in the action, then paste the code and the Custom CSS into your settings to add it to your DayBack: addHeaderButtonToMobile.zip

Navigate forward and backward in time using horizontal mouse scroll wheel clicks

You can add mouse scroll wheel detection to navigate the calendar using your mouse instead of the previous/next arrows: horizontalMouseScroll.zip

Override FileMaker home button behavior to run any script

This example runs a FileMaker script when the home button is clicked, but you could modify the "clickAction" to run any JavaScript code you'd like: homeButtonOverride.js

Add a resource columns selector to the resource filters in the sidebar

By default, DayBack lets you change the number of resources shown in any given resource view from the resource method. It can, however, be helpful to have a toggle available in the sidebar. This example adds a new dropdown at the top of the resource filters which lets you modify the number of resource columns/rows to show: ResourceColumnsSelector.zip

Events that can trigger app actions

On Sources Fetched

• Actions run right after DayBack retrieves the list of calendar sources.
• This trigger fires when DayBack starts up, when you reload the page, or when you return to the calendar from the settings screen.
• "Prevent default action" would stop DayBack from continuing to start up. You can use this with action.callbacks.confirm() to make DayBack wait for your action to complete.

On Calendars Fetched

• Actions run right after DayBack retrieves the list of calendars.
• This trigger fires under two scenarios:
  • When DayBack starts up, when you reload the page, or when you return to the calendar from the settings screen.
  • When a user manually authenticates with sources like Google, Microsoft 365, or Basecamp.
• "Prevent default action" would stop DayBack from continuing to start up. You can use this with action.callbacks.confirm() to make DayBack wait for your action to complete.

On Resources Fetched

• Actions run right after DayBack retrieves the list of resources.
• This trigger is useful to intercept if you want to manipulate the resources before they are shown in the sidebar. Typically, this trigger is used to load resources from Salesforce or Filemaker.
• This trigger fires when DayBack starts up, when you reload the page, or when you return to the calendar from the settings screen.
• "Prevent default action" would stop DayBack from continuing to start up. You can use this with action.callbacks.confirm() to make DayBack wait for your action to complete.

On Statuses Fetched

• Actions here happen right after DayBack retrieves the list of statuses.
• This trigger is useful to intercept if you want to manipulate the statuses before they are shown in the sidebar. Typically, this trigger is used to load status from Salesforce or Filemaker.
• This trigger fires when DayBack starts up, when you reload the page, or when you return to the calendar from the settings screen.
• "Prevent default action" would stop DayBack from continuing to start up. You can use this with action.callbacks.confirm() to make DayBack wait for your action to complete.

Before Calendar Rendered

• Actions will fire before DayBack draws the calendar frame, which comes before it renders the actual events.
• They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from the settings screen.
• "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in app actions.

After Calendar Rendered

• Actions will fire after DayBack has drawn the calendar frame, but before proceeding to the events.
• They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from the settings screen.
• "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in this type of app action.

After Events Rendered

• Actions will fire after DayBack has drawn all the events. It will fire even if there are no events to draw (i.e. no events match the current date range or filters). 
• Actions will also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from the settings screen.
• Use the params.data object for details of what triggered this action.
• "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in this type of app action.

After View Changed

• Actions set to this trigger will fire whenever a user clicks on a new view like "Day" or "Horizon".
• They'll also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from the settings screen.
• "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in this type of app action.

After Source Selection

• Actions will fire whenever a user selects or deselects a calendar source on the "Calendars" tab of DayBack's left-hand sidebar.
• Actions will also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from the settings screen.
• Use the params.data object for details of the source(s) that were toggled.
• "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in this type of app action.
• When selecting a folder, this action can fire multiple times for each item in the folder. You can look at the params.data.isLast property to determine if this is the last item in a folder being selected. This is useful if you only want your code in the action to only run once.

After Filter Selection

• Actions will fire whenever a user selects or deselects a filter or clicks "clear all filters."
• If the user has a filter applied, then actions defined here will also fire when DayBack starts up, when you reload the page in your browser, or when returning to the calendar from the settings screen.
• Use the params.data object for details of the filter(s) that were toggled.
• "Prevent default action" would stop DayBack from continuing to start-up and should almost never be used in this type of app action.
• When selecting a folder or clearing filters, this action can fire multiple times for each item in the folder. You can look at the params.data.isLast property to determine if this is the last item in a folder being selected. This is useful if you only want your code in the action to only run once.

Special configuration options

Here are a few special considerations for modifying your actions:

Prevent Default Action

In most cases, "Prevent default action" would stop DayBack from continuing to start up and should almost never be used in app actions. Leave this set to "no" or ask us about what you're trying to accomplish.

Action Enabled For

Use this setting to restrict where an action can run. Select "App" to have it run in DayBack; select "Shares" to enable the action in public shares. Deselect both to turn the action off without deleting it.

Some triggers pass parameters into their actions

A few trigger types pass information into their actions in the form of parameters. You can use these parameters in your scripts to determine what caused the action to fire or learn more about the application state. To see which parameters are included, add a simple console.log to your action like this:

console.log(params.data);

The following actions include parameters: After Events Rendered, After Filter Selection, and After Source Selection.

Coding your own actions

We advise you to use our App Action Starter Template to create your own custom actions. Our starter template provides graceful error handling should you make a mistake when coding your actions.

Additionally, the template has built-in features for running app actions only for specific users. If you are using our starter template, we recommend you use confirmCallback() or cancelCallback() instead of action.callback.confirm() and action.callback.cancel() when telling DayBack how to process its usual default action. While both sets of functions work, these first two calls take advantage of the timeout handling features in the starter template should your app action take too long to run. Most of our examples use the starter template, so you can learn as you make changes to our sample code as well!

Troubleshooting your actions

If your app action prevents DayBack from loading, you will see a continual blue loading stripe at the top of the screen. To disable a broken action:

1. Click your browser's reload button 
2. Quickly hold down shift key and wiggle your mouse around
3. This will return you to the administrative settings so that you can disable and fix the broken app action

If you run into trouble with your actions you may wish to check your javascript console for any errors. If the cause of the problem isn't obvious to you, please take a screen shot of what appears in the console and send it to our support team. We'd be glad to help you resolve the problem.