Custom Event Actions

Overview

Event actions allow you to modify DayBack's behavior based on user interactions with events. Unlike button actions, which trigger when a user clicks a button, or app actions, which control DayBack's loading behavior, event actions are initiated by activities such as clicking, saving, or deleting an event.

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.

By using event actions, you can tailor DayBack to better fit your workflow and enhance your overall user experience. You can also contact us any time, as we're happy to send sample code, or point you to examples that may meet your specific need.

You have the same access to create and modify custom actions as we do. You can even version and test your action using Draft Mode and Snapshots so that you can extend DayBack with confidence.

Uses for Event Actions

Event actions are used to change DayBack's standard behaviors. For example, if you want to verify that you have sufficient travel time between two events, you can interrupt the default save behavior before DayBack saves your event.

When a save action is intercepted, you can show a dialog to the user, make additional changes to the record, or connect to some other 3rd party service to notify a customer that a change has occurred.

Another example is that you might want to prevent the rescheduling of an event if it's too close to the event's start, or you might want to jump right to your own Salesforce page or FileMaker record instead of editing an item in the default popover. 

Example Salesforce action 

Here's a Salesforce-specific example of how you can open up the native Salesforce record when a user clicks the event instead of opening the record in DayBack's native popover:

Creating an Event Action

Creating a new action is pretty easy:

1

Log in to admin settings and select the source you're interested in.

2

Click the Actions & Buttons tab.

3

Click "Add New Event Action" and pick the trigger that should run your action.

4

Paste the code you'd like to execute where it says "URL or JavaScript". This is obviously the tricky part--writing the action itself. Don't hesitate to get in touch and ask for help (Note that you can also drag JS files into the code editor in DayBack if you'd rather compose your JavaScript functions in your own editor).

5

That's it.

Preventing DayBack's Default Behaviors

Each action you create in DayBack allows you to specify if the default behavior should run or not. Setting "Prevent default action" to true stops DayBack's default behavior until you decide what DayBack should do. For example, to check if a user is allowed to delete an event, set "Prevent default action" to true. Then, perform your authorization check within your action and use the following function calls based on the outcome:

• action.callbacks.confirm(); - Processes the request (e.g., deletes the event).
• action.callbacks.cancel(); - Ignores the request (e.g., event is not deleted).

Available Event Triggers

On Event Create

• Actions run when a user attempts to create a new event.
• Your code executes right before the popover renders, allowing you to interrupt the process for custom actions like opening a new browser window or navigating to a Salesforce record creation page instead. Typically, you use an On Event Create action to modify the editEvent object with default values (e.g., starting status, description, or resource). You can also prevent new event creation if the user isn't authorized to add events.
• Setting "Prevent default action" to true stops DayBack from creating a new event and rendering of the event popover until confirmed in your code. 
• See objects available in this context here.

On Event Click

• Actions will run whenever a user clicks on an event.
• They'll also run as soon as a new event is created, so you can also think of this trigger as an "On Popover Render" trigger.
• Setting "Prevent default action" to true prevents the popover from rendering unless this action is confirmed in your code.
• See objects available in this context here.

On Event Hover

• Actions will run whenever a user hovers over an event, most often used for creating tooltips.
• There is no default hover behavior, so "Prevent default action" does nothing.
• See objects available in this context here.

On Field Change

• Actions will run when a value is modified for a field in the popover.
• Supported fields are Calendar, Status, Resource, Contact, and Project, along with any custom fields that you define.
• Use the params.data object for details of what changed.
• Setting "Prevent default action" to true will prevent the field from being updated in the popover unless this action is confirmed in your code.
• Fields can can also be updated within the popover using this action. See the load contact address example below.
• See objects available in this context here.

Before Events Fetched

• Actions will run before DayBack attempts to retrieve events for a particular calendar source.
• Set "Prevent default action" to true to stop DayBack from fetching events for a given calendar unless this action is confirmed in your code.
• This trigger can be used to prevent DayBack from querying for the event data so that you can trigger your own custom query to add events to the calendar:

if (event.status === ['Completed'] && action.callbacks.cancel();

// Fetch events with your own custom query and add 
// events using dbk.addEvents(eventsArray);

• See objects available in this context here.

Before Event Rendered

• Actions will run after DayBack has retrieved the events but before each event is drawn on the calendar. The action runs once for every event that is about to be painted. You can use this action to transform how an event is displayed, or you can even prevent the event from displaying.
• Set "Prevent default action" to true to stop DayBack from rendering an event unless this action is confirmed in your code.
• See objects available in this context here.

Before Event Save

• Actions will run before changes made to an event are saved. This is the best trigger to use when you need to modify the event in some way before it is saved or if you wish to check whether the event should be saved in the first place.
• This trigger fires when users click "Save & Close" in the event's popover or when they complete a drag-and-drop operation in the calendar.
• Set "Prevent default action" to true to stop DayBack from continuing to save changes unless this action is confirmed in your code.
• See objects available in this context here.

On Event Save

• The action is triggered after DayBack processes the changes but just before the changes are written to the data store.
• This happens after the Before Event Save trigger and after the event changes have been processed.
• Setting "Prevent default action" to true stop DayBack from writing the changes back to the data store, but you could end your event action with code to execute the save yourself. 
• This is useful for writing changes to an alternate place, such as cloning data to another data store or modifying the data before it is sent to the data store. For example, you may want to prevent DayBack from trying to write back to a formula field or calculated field.
• DayBack lets users undo their changes, and your action can test for the undo property and behave differently when edits are reverted.
• See objects available in this context here.

On Event Delete

• The only way to trigger this action is via the "Delete" button inside DayBack's popover.
• Like On Event Save, setting "Prevent default action" to true will stop DayBack from writing the delete back to the data store (Google or Salesforce, for example).
• See objects available in this context here.

Available Fields, Functions and Objects

Your custom event actions have access to your Salesforce or FileMaker event data so long as you have mapped these fields in your data source settings. All fields can be accessed directly from the event and editEvent objects. Common functions and configuration options can also be accessed through the seedcodeCalendar , dbk , and utilities objects. Additionally, each individual trigger offers trigger-specific objects.

Learn more about accessing event attributes, additional custom fields, as well as DayBack objects and functions available for use within your event actions.

Here are some example actions to inspire your calendar customizations. Please copy and paste these into your DayBack, and don't hesitate to reach out if you get stuck. Check out our DayBack Extensions Library for a comprehensive database of all example actions.

// Standard way of referring to Custom Fields by 
// numerical ID:

let meetingAttendedFlag = editEvent['1234996543210-4152637485'];

// More human-readable way to refer to a Custom Field
// by using the field name

let fieldName = dbk.getCustomFieldIdByName('meetingAttendedFlag', editEvent.schedule);

let meetingAttendedFlag = editEvent[fieldName]

if (meetingAttendedFlag == true) {
    editEvent['status'] = ['Closed'];
}

noTimeChange();
function noTimeChange() {
   // drag and drop or popover edit?
   if(event.beforeDrop) {
      if(event.allDay!==event.beforeDrop.allDay || !event.start.isSame(event.beforeDrop.start) || !event.end.isSame(event.beforeDrop.end)) {
        event.allDay = event.beforeDrop.allDay;
        event.start = event.beforeDrop.start.clone();
        event.end = event.beforeDrop.end.clone();
      }
   }
}

// Default duration is 30 min by setting the end
// time to be 30 minutes after the start time

editEvent.end = moment(editEvent.start).add(30, 'm');

// Revert changes if the event was dragged and dropped
// otherwise, allow the Save to take place

if (event.beforeDrop) {
  action.callbacks.cancel();
} else{
  action.callbacks.confirm();
}

Retrieve custom parameter from URL

// Gets the sessionID parameter from the URL 
// and stores it in a custom field

getSessionID();

function getSessionID() {
  var sessionID = getUrlVars().sessionID;
  editEvent['1234996543210-4152637485'] = sessionID;
}

// This function retrieves all parameters from the URL
// and returns them as an object of key=value pairs

function getUrlVars() {
    var vars = {};
    var parts = location.href.substring(0, location.href.indexOf('#/')).replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,value) {
        vars[key] = value;
    });
    return vars;
}

Disable all-day events

// Add the creator as a resource to new events

editEvent.resource = [seedcodeCalendar.get('config').accountName];

// Set events to start off in New status

editEvent.status = ['New'];

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.