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.

Actions are written in JavaScript, and we publish our most popular actions in a searchable directory. Some of those can be installed with no customization (tagged as "easy install"), some you'll need to edit ("Download and Customize"), and some are so involved that you'll want us to deploy them for you (those are tagged "Custom Integration").


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

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


Use By default, DayBack allows you to create conflicting events. What constitutes a conflict in one of your calendars might be different than the rules for another calendar. Since a user can make changes to events in DayBack or in Salesforce, conflicts can originate from changes made in either place. For this reason, conflict-checking must be implemented in both DayBack and Salesforce.

DayBack Action:

This example action fires when events are edited in DayBack. It will prevent an event from being double-booked if there's an existing event with the same resource and overlapping times in the same Salesforce object. This DayBack-specific example can be easily modified if you have other things you need to consider when checking for conflicts.

Salesforce Trigger / FileMaker Trigger:

This above example goes together with the Salesforce trigger examples published here: Date Range Conflicts in Salesforce. Both sets of examples work together to prevent conflicts when events are edited in DayBack or in Salesforce screens. There is a FileMaker version of this action you can paste into your file.

Trigger   Before Event Save
Script The code, a demonstration video, and details are available here: Prevent Resource Conflicts in Salesforce.
Options Open in new window: No  Prevent default action: Yes


Force single selection for statuses and/or resources

Use By default, events can belong to multiple resources and can have multiple statuses at the same time. This action will ensure that an event can only be assigned to a single resource or status at one time. This is particularly useful in mobile environments where multi-select is the normal behavior but the field should only be set to a single value.
Trigger   On Field Change
Script forceSingleSelect.js
Options Open in new window: No  Prevent default action: Yes


Specify resources shown for each calendar with tags

Use DayBack allows you to assign an event to any of the resources that you have set up. However, there may be times where you want to restrict an event to only a specific list of resources. This action allows you to specify a more narrow and specific list of resources that an event can be assigned to. You will first need to set tags for your resources. Tags can describe a resource's relationship to a specific calendar. 

The following action will check a resource's tags as well as the names of resource folders to see which resources apply to a given event. You can include or exclude an entire folder of resources to show for a specific calendar by configuring the options in this action. Here's a video of how this works and the tags you'll use to configure it.
Trigger   On Event Click
Script resourceListToggle.js
Options Open in new window: No  Prevent default action: No

Prevent popovers from displaying

Use By default, all users can drag events around to reschedule them and click the event to view and edit event details. If you'd like your users to drag events around but you don't want them to view or edit any event details, you can simply disable the edit event popover. This one-line action effectively turns off DayBack's On Event Click behavior. 
Trigger   On Event Click
Script var dummy;
Options Open in new window: No  Prevent default action: Yes

Note that you can use this var dummy; to turn off any of the trigger actions, including turning off deletes. 


Go right to the item on click

Use Clicking an event opens DayBack's native event editing popover. If you'd prefer to edit your event details inside your native Salesforce screen you can use this simple one-liner to jump right to the item's page in Salesforce.

If you prefer, you can continue to edit basic details in DayBack but create a button that goes to the native Salesforce record instead.

If you're connected to FileMaker, you can configure DayBack to open events in your own FileMaker layout or card window.
Trigger   On Event Click
Script
fbk.publish ( "dbk.navigate" , { "url" : "/[[Id]]" , "new" : false } );
		
Options Open in new window: No  Prevent default action: Yes


Change the event's status if a checkbox is checked

Use Say you've mapped a custom field called "meetingAttended" as a checkbox. This app action will automatically set the event's status to "Closed" if the user has checked that checkbox.  Something like this may be useful if the user forgets to mark the event "Closed" when they are making changes to an event. The Before Event Save save action will check whether the checkbox has been checked and will set the event's status accordingly. 

Quick Example of how to access custom fields:
// 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'];
}
		
Trigger   Before Event Save
Script setStatusOnCheckboxChecked.js
Options Open in new window: No  Prevent default action: No


Prevent dragging from changing an event's time

Use All events can be dragged and dropped to a new resource, calendar, status, or time. Say you have users who are rescheduling events by dragging and dropping them to different resources. You want them to reassign resources using drag and drop, but you don't want them accidentally changing an event's time when dragging between resources.

The Before Event Save trigger gives you access to an event's state before it was dragged and after it was dropped. This allows you to detect what was changed, and to react appropriately. The following action will snap an event back to its original time if it detects that the drag-and-drop resulted in a time change.
Trigger   Before Event Save
Script
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();
      }
   }
}
		
Options Open in new window: No  Prevent default action: No


Add a default duration to an event

Use DayBack has a setting for an app-wide default event duration. If you'd like to change the default event duration for specific calendars, this action is a great way to do so. Since event actions can be unique for each calendar, you can copy the code below and paste it into each individual calendar's On Event Create action and then set your default duration.

If you'd like to have a different default duration for each individual resource or set up other resource-specific defaults, you can check out our blog post on setting up default values for each resource.
Trigger   On Event Create
Script
// 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');
		
Options Open in new window: No  Prevent default action: No


Prevent dragging from changing an event

Use By default, DayBack allows you to reschedule events using drag and drop. We previously showed you how to prevent dragging and dropping from changing an event's time. Say you have a specific calendar where you don't want people dragging and dropping at all. The following action effectively cancels the save event if it finds a beforeDrop property inside the event object. However, it will confirm the save event if the save was triggered another way.
Trigger   On Event Save
Script
// 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();
}
		
Options Open in new window: No  Prevent default action: Yes


Retrieve custom parameter from URL

Use You can load DayBack using special URL parameters. These allow you to control what happens when DayBack first opens. If you'd like to pass your own custom URL parameters for use in your event actions, this app action allows you to scan the URL for these parameters. 

This type of action can be useful when loading DayBack in a FileMaker WebViewer, as this allows you to pass parameters for use when creating or editing events.

In this scenario, we're retrieving the parameter "sessionID" from the URL string and assigning it to an additional field in the event object. This takes effect when an existing event is clicked on or a new event is created.
Trigger   On Event Click
Script
// 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;
}
		
Options Open in new window: No  Prevent default action: No

Note: A few example DayBack URLs that could be used in with this custom action:


Make past events read-only

Use By default, DayBack allows you to change historical events. If you want to prevent users from changing historical information, you can make past events read-only using a combination of two app actions:

  • The On Event Click action dynamically makes the event popover read-only so that you can still open the event, but you can't change anything about it. 
  • The Before Event Save actions prevents past events from being dragged and dropped to a new place.
Trigger   On Event Click
Script readOnlyPastOnClick.js
Options Open in new window: No  Prevent default action: No

Trigger   Before Event Save
Script readOnlyPastBeforeSave.js
Options Open in new window: No  Prevent default action: Yes


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

Use DayBack can be set up to send notification emails directly from within Salesforce or from your FileMaker server. If you're using DayBack with a Google Calendar instead, your Google Calendar with send notifications automatically based on your Google settings. 

While DayBack is not configured to communicate with your email server directly, this simple action can be used to compose a new email using your computer's default email client. 

Say you'd like to notify someone when an event's status (or another field) is set to a specified status ('On Hold' in this example). This action will automatically compose an email with a notification that the event is in the specified status. It can also build the body of the email to include the event's title, description, time, and a link to the event within DayBack. 
Trigger   On Event Save
Script emailSupportOnHold.js
Options Open in new window: No  Prevent default action: No


Add a default event contact for all events

Use Salesforce has specific sharing rules which prevent everyone in the organization from seeing events and tasks that they don't own. One way to overcome this limitation is to set up a parent customer record and then give users permission to view records associated with this parent account. This custom event action will automatically assign a Parent Customer Record Id to all newly-created events. This Salesforce customization is just one possible way to allow individuals to see each other’s Events and Tasks.
Trigger   On Event Create
Script setEventParentContactID.js
Options Open in new window: No  Prevent default action: Yes


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

Use Salesforce contains address information in an event's related contact record. This app action detects if a user is changing the contact associated with an event and uses a SOQL query to load the contact's address into the event location field. This is a great example of how to react to changes a user is making and interact with Salesforce records from within the event popover. 
Trigger   On Field Change
Script loadContactAddress.js
Options Open in new window: No  Prevent default action: Yes


Disable all-day events

Use If you'd like to prevent all-day events from being created, this action converts all-day events into scheduled events. It sets your event to the current time-slot with the default event duration set from your DayBack settings.
Trigger   On Event Create
Script disableAllDayEvents.js
Options Open in new window: No  Prevent default action: No


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

Use All newly created events start off as unassigned. This simple action automatically assigns newly created events to the currently-logged-in user who is creating the event. 

Since an event can be assigned to multiple statuses and resources at the same time, your actions must define these values as arrays. For example: ['resource1', 'resource'2, 'resource2']. In other words, your values must be in brackets even if you have just one value. In this example, we fetch the account name from the seedcodeCalendar object and place it inside the resources array. Check out all the cool stuff you have access to inside the seedcodeCalendar object

This action is a great way to start thinking about your event's default information. Since you have access to the current user and the calendar, you can make decisions about other defaults you may want to set. Consider starting all your events in the 'New' status, as in the example below:
Trigger   On Event Create
Script
// 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'];
		
Options Open in new window: No  Prevent default action: No


Define event dependencies and update all related events 

Use If you are managing a project that has multiple related events, you may want to set up a linking relationship between related events. If a change is made to any of the activities in your project, the change will automatically cascade through the timeline and reflect in all downstream activities. We call this type of relationship a cascading event

This action has a number of configuration options described in our blog post on cascading events
Trigger   On Event Save
Script cascadingEvents.js
Options Open in new window: No  Prevent default action: Yes


Confirm appointments or collect information in a form

Use DayBack allows you to import any 3rd party JavaScript library. This means you can extend DayBack any way you want. This example shows you how to use the wufoo form library to create a public booking request form within a publically-shared calendar. Public shares can show specific views to the general public which can be accessed in any browser directly from a link. 

This example overrides the On Event Click trigger for events within a public share. Say you are advertising available appointment slots, or special events in your public calendar. If a potential customer clicks on the event in your public share, DayBack can bring up a custom form, gather your customer's information and then email you and the customer. The wufoo form library has many great features, including form validation and emailing capability right within wufoo form itself. 

Here's a short video of this one in action.
Trigger   On Click
Script confirmAppointmentWuFooForm.js
Options Open in new window: No  Prevent default action: Yes


Validate data entry and ensure all fields are filled in

Use DayBack doesn't perform specific data validation when users are creating or making changes to an event. However, you can easily add basic or advanced validation. This custom action allows you to specify a list of fields which must be filled in before a user is allowed to save an event. If a specified field is left empty, a notice will pop-up notifying the user with a choice. It will allowing them to continue editing the event to fill in all required fields, or allow them to save the event with some empty fields. Click here for a video of it in action.
Trigger   Before Event Save
Script validateFieldEntry.js
Options Open in new window: No  Prevent default action: Yes


Check resource capacity and prevent overbooking

Use If certain resources should not be over-scheduled, you can set up some scheduling limits. This action prevents an event from being saved if it will result in the specified resource going over its daily limit of events. We use a SOQL query to check Salesforce records directly. This ensure that we have access to the full schedule, not just the filtered view that the user is currently seeing.

If the requested change would result in a resource becoming overbooked, you can prompt the user with an error message to show which days would be over capacity and you can cancel the edit.

This app action is a great example of how you can scan the events on the calendar and make decisions based on the upcoming schedule.
Trigger   Before Event Save
Script checkResourceCapacity.js
Options Open in new window: No  Prevent default action: Yes


Warning when creating events in the past

Use We all make mistakes, and sometimes we accidentally schedule events in the past. This simple action prompts the user with a warning that they are creating an event in the past. The user can then choose to cancel or continue with the event creation. 
Trigger   On Event Create
Script inThePastWarning.js
Options Open in new window: No  Prevent default action: Yes


Looking up a Resource ID by name (Salesforce)

Use Salesforce stores an event's resources as a list of numerical IDs. This means that when you change a resource on an event, DayBack has to look up the numerical ID for your resource before this change is saved back to Salesforce. This lookup used to require an app action - but you can now map related resources within the Admin settings directly.


Override Start Field when editing (Salesforce)

Use By default, DayBack will display all events in your mapped Salesforce objects. However, you can set up a calculation to determine which events should be included and which should be excluded in your calendar definition. The way this is done is to map your calendar's start date to a formula field instead of the event's real start date.

Part 1 - Set up your formula field

Your new formula field is set up inside your Activity object and defines the rules that govern whether a date is returned. If you don't want an event record displayed by DayBack, have the formula field return an empty date. If you do, have the formula field return the event record's real start date.

Here's an article that describes how to pre-filter events in Salesforce using this method. Below is an example formula field definition that you can add to your Activity object. It returns the event's start date and time but only for events belonging to the current user.

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

Part 2 - Tell DayBack the name of your real start date field

Since pre-filtering tells DayBack to use a calculation for an event start date, this field isn't really a field that DayBack can update when your user makes a scheduling change. If your user tries to update an event with a formula field, DayBack will experience an error.

The following Salesforce-specific event action allows you to specify the actual StartDateTime field DayBack should use when saving event changes to your Salesforce record. It does this by intercepting the On Event Save event, and copying the date to the actual Salesforce StartDateTime field.

Trigger   On Event Save
Script overrideStartEdit.js
Options Open in new window: No  Prevent default action: No


Merge information to/from Google Calendar (Salesforce)

Use Here are two ways you can integrate Salesforce with Google Calendar:

  • Use Salesforce data to create and pre-populate a Google Calendar event
  • Create new Salesforce records from existing Google Calendar events
Trigger   Multiple
Script Two examples here: Google Calendar Actions in Salesforce
Options Open in new window: Multiple  Prevent default action: Multiple


Push events to Google Calendar

Use DayBack can push events from other calendars to Google Calendar. This can be helpful for many different reasons, including integrating with 3rd party applications that already interact with Google Calendar but don't interact with Salesforce or DayBack directly.

If you use Calendly to allow your customers to schedule appointments with you, this action can allow you to block out your availability in Calendly. It does this by automatically cloning your schedule into a Google Calendar that Calendly can use. Calendly then checks this special calendar to ensure customers can't double book your time. 

While this action isn't "syncing" with Google, since changes made in Google aren't brought back into your other calendars, this action is still a great way to build a Google Calendar out of specific events from Salesforce or FileMaker calendars, or even from select events in other Google Calendars.
Trigger   Multiple
Script Find a description and download code for the two required actions here: DayBack and Calendly
Options Open in new window: No  Prevent default action: Yes


Change behaviors when special keys are pressed

Use Keyboard shortcuts make everything easier. This pair of actions teaches DayBack to listen for the keys you're holding down and lets you test for these in your custom actions. A common use case for this would be to change what happens when you click on an event if the "z" key is held down. (Note that DayBack is already listening for the shift and option keys, and the command key is reserved by the browser, so using "regular" keys is recommended)
Trigger   Multiple
Script The two actions are available here: KeyDown Listener
Options Open in new window: No  Prevent default action: Probably


Remove attendees from events when duplicating (Google Calendar)

Use When you drag-duplicate an event containing attendees (applicable to Google and O365), you likely don't want the attendees copied to the new event. Or at least you'll want to reset their "accepted" status. This action removes the attendee object entirely; you could go further and unset just the event acceptance by examining the properties of the event.attendees object.

Remember that app actions can be defined for all calendars or for an individual calendar. If you're changing the event's calendar assignment during your duplication, apply this action to the origin calendar, not the destination calendar -- when duplicating, the On Event Create is fired as soon as the event is rendered on-screen (which happens right after it's duped and is still in the original calendar).
Trigger   On Event Create
Script
event.attendees = [];
		
Options Open in new window: No  Prevent default action: No


Default values for each resource

Use By default, all your resources have the same default values, such as an event duration. This app action allows you to set a default duration--or any value--for each of your resources. While you can usually set defaults in the backend, using a trigger or a formula field, those don’t evaluate until the appointment is committed to the back end. Using an action like this adds the defaults to the event as soon as users begin creating it.  

Trigger   On Event Create
Script See a video of this in action and copy the code you'll want for your own version here: Default Durations for each Resource
Options Open in new window: No  Prevent default action: Yes


Require tags/skills for an event

Use Resource Tags are a powerful way to define skills or attributes for each of your resources. You can leverage this list of skills when creating an event. You may want to require that resources assigned to the event have the required skills for the given event type. 

This action checks an event's custom fields for a list of required skills. If your user attempts to assign a resource that does not have all of the required skills, they will receive a warning message. Required tags/skills must be specified as a comma-separated list in a user-defined custom field. You can then configure this action to check against this field and your resource's list of tags. 

Trigger   Before Event Save
Script You can see this action at work towards the end of the video introducing resource tags. You'll find the code for his action here: eventRequiresTags.js
Options Open in new window: No  Prevent default action: Yes


Specify a default popover drawer at the root calendar level

Use The list of available Google and Microsoft 365 calendars are unique to the authenticated user. Currently, DayBack only supports setting a default popover drawer at the individual calendar level.

With this action, you can specify the default popover drawer to open at the root calendar level, so it takes effect for all Google or M365 calendars for everyone.
Trigger   On Event Click
Script DefaultPopoverDrawerRootLevel.js
Options Open in new window: No  Prevent default action: No


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!

Coding tip: We recommend you edit your actions in a code editor like Visual Studio Code. This allows you to keep a backup copy of any code that you write. Additionally, we recommend you keep two tabs open when working with DayBack actions. One tab opens to your Administrative settings where you're working with the JavaScript code. Your second tab opens to the calendar, where you can refresh your screen and test your changes. If you make a mistake, you can always switch back to your first tab and press Ctrl-Z to undo the last code change.

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.