Custom Event Actions

By default, DayBack allows conflicting events. What constitutes a conflict in one calendar might differ from another. Since users can make changes in DayBack or Salesforce, conflicts can arise from either. Therefore, conflict-checking must be implemented in both platforms.

DayBack Action:

This example action fires when events are edited in DayBack. It prevents double-booking if an existing event with the same resource and overlapping times exists in Salesforce. This example can be modified for additional conflict criteria.

Salesforce Trigger / FileMaker Trigger:

This DayBack example works together with the following Salesforce triggers to prevent conflicts when events are edited in DayBack or Salesforce screens. There is also a FileMaker version available.

DayBack allows assigning events to any of your resources, but sometimes you may want to restrict an event to a specific list of resources. This action lets you specify a narrower list of assignable resources by setting tags for your resources. Tags can describe a resource's relationship to a specific calendar.

The action checks resource tags and folder names to determine applicable resources for an event. You can configure options to include or exclude entire folders of resources for a specific calendar. Here's a video explaining how this works and the tags you'll use to configure it.

Open in new window: No  Prevent default action: Yes

Clicking an event in DayBack opens the native event editing popover. If you prefer to edit event details directly in Salesforce, you can use a one-liner to jump to the item's Salesforce page. Alternatively, you can keep basic editing in DayBack and add a button to go to the Salesforce record.

For FileMaker, you can configure DayBack to open events in your own FileMaker layout or card window.

If you've mapped a custom checkbox field called meetingAttended , you can use this app action to set the event's status to "Closed" when the checkbox is checked. This is useful if users forget to manually mark events as "Closed." The Before Event Save action checks if the checkbox is marked and updates the event 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'];
}

DayBack has a setting for an app-wide default event duration. To change the default duration for specific calendars, use the following action. Since event actions can be unique for each calendar, you can copy and paste the code into each calendar's On Event Create action and set your default duration.

For different default durations for each resource or other resource-specific defaults, refer to our blog post on setting up default values for each resource.

By default, DayBack allows rescheduling events using drag and drop. To prevent dragging and dropping in a specific calendar, use the following action. This action cancels the save event if it finds a beforeDrop property in the event object but confirms the save if triggered another way.

This ensures that events can only be rescheduled through other means, not by dragging and dropping.

DayBack can be loaded with special URL parameters to control its initial behavior. To pass custom URL parameters for use in event actions, use this app action to scan the URL for parameters. This is useful when loading DayBack in a FileMaker WebViewer, allowing parameter usage when creating or editing events.

For example, the following action retrieves the sessionID parameter from the URL string and assigns it to an additional field in the event object. This action runs when an event is clicked or created, as creating an event also runs the On Event Click trigger to open the new event's popover.

Open in new window: No  Prevent default action: No

By default, DayBack allows changes to historical events. To prevent this, you can make past events read-only using two app actions:

1. On Event Click: This action dynamically makes the event popover read-only, allowing the event to be opened but not edited.
2. Before Event Save: This action prevents past events from being dragged and dropped to a new place.

These actions ensure that historical information remains unchanged while still providing visibility into past events.

DayBack can send notification emails directly from Salesforce or your FileMaker server. For Google Calendar users, notifications are managed by Google settings. While DayBack doesn't communicate with email servers directly, you can use a simple action to compose an email using your computer's default email client.

For example, if you want to notify someone when an event's status is set to "On Hold," this action will automatically compose an email with the event's details, including the title, description, time, and a link to the event in DayBack.

By default, newly created events are unassigned. This action automatically assigns new events to the currently logged-in user.

Since events can be assigned multiple statuses and resources, these values must be defined as arrays. For example: ['resource1', 'resource2'] . In this action, the account name from the seedcodeCalendar object is placed inside the resources array.

Read more about the information available through the seedcodeCalendar object.

This method can help set default information for events. 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:

For projects with multiple related events, you may want to create a linking relationship so that changes to any activity automatically cascade through the timeline, reflecting in all downstream activities. This type of relationship is called a cascading event.

This action has several configuration options, detailed in our blog post on cascading events.

DayBack allows importing any third-party JavaScript library, enabling extensive customization. This example uses the Wufoo form library to create a public booking request form in a publicly-shared calendar. Public shares can display specific views to the general public via a direct link.

This example overrides the On Event Click trigger for events in a public share. For instance, when a potential customer clicks an event in your public calendar, DayBack can display a custom form, collect the customer's information, and email both you and the customer. The Wufoo form library offers features like form validation and emailing.

Here's a short video of this in action.

DayBack doesn't perform specific data validation when users create or edit events, but you can easily add basic or advanced validation. This custom action specifies fields that must be filled before saving an event. If a required field is empty, a notice pops up, giving the user the option to continue editing to fill in all required fields or save with some fields empty.

Here's a video demonstrating this action in use.

To prevent over-scheduling certain resources, you can set up scheduling limits. This action stops an event from being saved if it causes a resource to exceed its daily event limit. Using a SOQL query to check Salesforce records directly ensures access to the full schedule, not just the user's current view.

If the change would overbook a resource, it prompts the user with an error message showing the over-capacity days and cancels the edit. This action demonstrates how to scan calendar events and make decisions based on the upcoming schedule.

By default, DayBack displays all events in your mapped Salesforce objects. To filter events, set up a calculation to determine which events to include. 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

Create a formula field in your Activity object that returns an empty date for excluded events and the real start date for included ones.

Example:

This example 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('')

Here's an article that describes how to pre-filter events in Salesforce using this method.

Part 2 - Specify the Real Start Date Field

Since pre-filtering uses a calculation, DayBack can't update this field directly when scheduling changes are made within DayBack. Instead, you must add a Salesforce-specific event action to specify the actual StartDateTime field for saving changes, intercepting the On Event Save tigger, and copying the date to the real StartDateTime field.

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

DayBack can push events from other calendars to Google Calendar, useful for integrating with third-party applications that interact with Google Calendar but not directly with Salesforce or DayBack.

For example, if you're using Calendly to allow customs to schedule appointments with you directly, you can block your appointment availability by cloning your schedule into a Google Calendar that Calendly checks to prevent double booking.

While this action doesn't sync with Google (changes in Google aren't brought back to other calendars), it's effective for building a Google Calendar from specific Salesforce, FileMaker, or other Google Calendar events.

When you drag-duplicate an event with attendees (for Google and O365), you may want to avoid copying attendees to the new event or reset their "accepted" status. This action removes the attendee object entirely. You could also unset just the event acceptance by examining the properties of the event.attendees object.

Remember, app actions can be defined for all calendars or an individual calendar. Apply this action to the origin calendar, as the On Event Create fires immediately after duplication while the event is still in the original calendar.

By default, all your resources share the same default values, such as event duration. This app action lets you set specific default durations—or any value—for each resource. While backend triggers or formula fields can set defaults, they don't apply until the event is committed to the backend. This action adds defaults immediately as users start creating the event.

Resource Tags are a powerful way to define skills or attributes for your resources, useful when creating events requiring specific skills. This action checks an event's custom fields for a list of required skills. If a user tries to assign a resource lacking the necessary skills, they receive a warning message. Required tags/skills must be specified as a comma-separated list in a custom field. Configure this action to check this field against your resource's tags.