Custom Event Actions

Event actions let you modify everyday behaviors in DayBack. Unlike button actions that fire when a user clicks a button or app actions that control DayBack's loading behavior, event actions are initiated when users perform an activity with a particular event. Activities include things like clicking an event, saving an event, or deleting an event.

Uses for event actions

Event actions are used to change DayBack's standard behaviors. For example, if you want to verify that a user should be allowed to make a specific change, you can interrupt the default save behavior before DayBack performs the save. When a save action is intercepted, you can prevent saving if the user is not authorized, make additional programmatic changes to the record, or connect to some other 3rd party service to notify a customer that a change has occurred.

Alternatively, you might want to prevent the deletion of an event in certain cases, 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

Every action you create allows you to specify if DayBack should run the default DayBack behavior or not. If you set "Prevent default action" to true, DayBack will not run its default behavior until you tell it to do so. This allows you to prevent a default behavior until you have determined if the behavior should run or not. For example, if you want to check that a user is allowed to delete an event you can set "Prevent default action" to true. Inside your action, you can perform your authorization check and then run one of two function calls depending on the outcome of your authorization check:

action.callbacks.confirm();

Tells DayBack to go ahead and process the request. In this example, the event will be deleted.

action.callbacks.cancel();

Tells DayBack to ignore the request. In this example, the event will not be deleted.

Available Event Triggers

On Event Create

• Actions run when a user attempts to create a new event.
• Your code runs right before the popover is rendered. This allows you to interrupt the loading of the popover so you can do something else, like opening a new browser window or going to a Salesforce record creation page instead. Most commonly, you may use an On Event Create action to modify the editEvent object and fill it in with default values, such as a default starting status, description, or resource. You can even prevent the creation of new events entirely if your user is not authorized to add events.
• "Prevent default action" stops DayBack from creating a new event and rendering of the event popover unless DayBack's default action is confirmed in your code. 
• See objects available in this context here.

On Event Click

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

On Event Hover

• Actions will fire whenever a user hovers over an event: most often used for 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 fire 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.
• "Prevent default action" will prevent the field from being updated in the popover unless DayBack's default action is confirmed in your code.
• Fields can be updated within the popover using this action. See the load contact address example below.
• See objects available in this context here.

Before Event Rendered

• Actions will fire after DayBack has retrieved the events but 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.
• "Prevent default action" would stop DayBack from rendering an event unless DayBack's default action is confirmed in your code.
• See objects available in this context here.

Before Event Save

• Actions will fire before changes 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.
• "Prevent default action" will stop DayBack from continuing to save changes unless DayBack's default 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.
• "Prevent default action" would 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; 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 this action gets triggered is from the "Delete" button inside DayBack's popover.
• Like On Event Save, "Prevent default action" here will stop DayBack from writing the delete back to the data store (Google or Salesforce, for example).
• See objects available in this context here.

Note that On Event Save and On Event Delete actions can affect the "Saved" and "Deleted" notifications that pop up from the bottom of the screen to confirm an event. If you select "Prevent default action" to be "yes", DayBack will not show the success notification after your action because DayBack wouldn't know if your action saved or deleted the event after all. You can, however, call the notification in your own code by using the utilities.showMessage() function.

Accessing your own data fields

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. Learn more about accessing event attributes, additional custom fields, as well as available DayBack functions in your event actions.

Examples

Here are some example actions to get you thinking about how you can customize your calendar. 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.

Prevent resource conflicts in Salesforce

Force single selection for statuses and/or resources

Specify resources shown for each calendar with tags

Prevent popovers from displaying

Go right to the item on click

fbk.publish ( "dbk.navigate" , { "url" : "/[[Id]]" , "new" : false } );
		

Change the event's status if a checkbox is checked

// 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'];
}
		

Prevent dragging from changing an event's time

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();
      }
   }
}
		

Add a default duration to an event

// 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');
		

Prevent dragging from changing an event

// 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;
}
		

Make past events read-only

Send an email when an event is set to a specified status

Add a default event contact for all events

Set an event's location to the contact's address

Disable all-day events

Set the default resource for new events to the logged-in user

// 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'];
		

Define event dependencies and update all related events 

Confirm appointments or collect information in a form

Validate data entry and ensure all fields are filled in

Check resource capacity and prevent overbooking

Warning when creating events in the past

Looking up a Resource ID by name (Salesforce)

Override Start Field when editing (Salesforce)

if ( $User.Id = OwnerId , If( IsAllDayEvent , DATETIMEVALUE(ActivityDate) , ActivityDateTime ) , DATETIMEVALUE('') )
		

Merge information to/from Google Calendar (Salesforce)

Push events to Google Calendar

Change behaviors when special keys are pressed

Remove attendees from events when duplicating (Google Calendar)

event.attendees = [];
		

Default values for each resource

Require tags/skills for an event

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.