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 actions run when an app-level event is triggered.

All actions are open-source, and written in JavaScript. We publish our most popular actions in a searchable extensions library. Some actions are plug-and-play, while others are more complex. Our library categorizes actions as follows:

• Easy Install: These actions can be installed without customization.
• Download and Customize: These actions require some editing or configuration before use.
• Custom Integration: These actions are complex and typically require deployment by DayBack's team.

Please contact us any time should you have questions about app actions. We're happy to send sample code, or point you to examples that may meet your specific need.

Uses for App Actions

App actions allow you to modify core behaviors in DayBack, such as loading resources, statuses, calendars, and events. They also let you intercept navigation changes, including switching calendars, bookmarks, or views, as well as changes to status and resource filters and event rendering.

For example, you can tailor DayBack's behavior based on the role of the current user. Here are some examples:

• User-Specific Content: Load a user-specific list of resources, statuses, and calendars relevant to that user.
• Read-Only or Hidden Events: Make certain events read-only or hidden based on the user's role.
• Dynamic Resource Management: If you have hundreds of resources, dynamically pre-load and organize resources into folders.

In the screenshot below, resource folders and the equipment within each folder are dynamically pulled from the user's Equipment object in Salesforce.

Extending DayBack with 3rd-party integrations

App actions provide complete control over DayBack's behavior, enabling you to extend its functionality using JavaScript and third-party APIs. These integrations allow you to pull in data or features that fully customize your scheduling workflow. If you need help integrating a third-party system, our integrations team is available to assist.

For example, you can add route and distance calculations using the Google Maps API. Explore our DayBack Extensions Library for a comprehensive list of third-party integrations that DayBack currently supports.

Launch actions from a custom menu

When DayBack first opens, you may want to insert some custom buttons into the sidebar. These buttons can open other apps, control your thermostat, or perform any action you can imagine.

For instance, you can add a custom button launcher, as shown in the screenshot below. Custom buttons enable you to launch your own actions, run FileMaker scripts, load commonly used bookmarks, or perform multi-update operations on 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 the resource filters you previously selected. If you haven't logged in before, DayBack will display all events available for the given date range. To ensure DayBack loads only your specific events each time you log in, you can use a custom app action. Once installed, this action will de-select all previously-selected resource filters and set the filter to match your current username. Use the file SelectResourceAsUser.js to implement this functionality.

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 Calendar Selection

DayBack allows you to display all of your calendar sources, as well as all your resources in one interface. However, not all resources may be applicable to every calendar. When a user switches between calendars in the sidebar, the following simple app action will automatically switch the currently-enabled resource filters to match the resource filters that are applicable for the selected calendar. Check out our example code and a video of this in action: select specific resource filters when switching between calendars. You may also consider loading different bookmarks for each user. Here's a blog post and code on how to open a default bookmark for each user.

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

Show or hide calendars based on the currently logged-in user

By default, DayBack will load all calendars that you have mapped. However, you may want to show only specific calendars for specific user groups. The following examples will show only the specific calendars you want based on the current user. This is great for large organizations with multiple lines of business. Each action uses a different way of restricting the calendar list:

• Show or Hide by DayBack Username (email address) 
• Show or Hide by Salesforce Username (email address) 
• Show or Hide by Salesforce Profile ID (Salesforce profiles can define a group of people)

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: Download the Resource Columns Selector.

Available App Action Triggers

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" doesn't have an effect in this action, as the calendars are already selected.
• 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" doesn't have an effect in this action, as the filters are already set.
• 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.

After Draft Mode Toggle

• Actions will fire after a user toggles draft settings mode.
• When disabling draft settings mode, this fires just after the draft is discarded, published, or saved.
• Use the params.data object for details of the current draft mode state and selected option (discard, publish, etc.).
• "Prevent default action" will postpone reloading the page when discarding or saving a draft. It has no effect when enabling draft settings mode or publishing a draft.

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. Available parameters are accessible from the params object. You can use these parameters in your scripts to determine what caused the action to fire or learn more about the application state.

For example, should you need to know that user navigated to a different view from the view they were on, this information will be available inside this object.

To see which parameters are included, add a simple console.log statement to your action like this:

console.log(params.data);

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

We recommend using our App Action Starter Template to create custom actions. The template offers graceful error handling and features for running actions for specific users. If using our template, use confirmCallback()  or cancelCallback()  instead of action.callback.confirm()  and action.callback.cancel()  to leverage the template's timeout handling features should your app action take too long to run. Most of our examples use this template, allowing you to learn by modifying sample code.

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 the 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 screenshot of what appears in the console and send it to our support team. We'd be glad to help you resolve the problem. 

Learning Resources

• Data Tokens, Event Attributes, and Functions: Gain a deeper understanding of the available data tokens, event attributes, and functions for your custom actions by visiting the APIs: Resources for Custom and Event Actions.
• JavaScript Objects and Methods: Explore the JavaScript objects and methods you can utilize in your custom actions at Objects and Methods for Custom Actions.

Sandbox for Testing

Custom actions provide an excellent environment for experimenting with new code and testing queries. For example, check out how DayBack's Jason Young uses custom actions to console log query results in Testing SOQL Queries in DayBack Calendar.

Draft Mode

For testing App Actions or Event Actions, we recommend using Draft Mode. This mode allows you to make custom changes what are only active for your user session. This mode is great for testing code changes without affecting other users. Drafts and be saved, disabled, reenabled, and then applied to production when your code changes are ready for production user.