Part 1 of 3 on creating attendees, invitations, and accepting invitations in DayBack.
Why Use Google to Send Notifications?
Email notifications were built into Salesforce Classic, but they’re getting harder to do in Lightning. Having Google Calendar send notifications for your Salesforce events is a great alternative.
Even FileMaker developers, who have always been able to use server-side scripts to send email notifications, can benefit from having Google send notifications instead. If you want to send an actual calendar invitation, instead of just an email, that can mean calculating .ics files by hand: having Google manage the notification for you is much simpler.
Need help? The instructions and example code that follows is designed to show you how this customization works and to let developers add this to their own deployments. If you’d rather we deploy this for you, we can customize this feature and add it to your DayBack as part of an implementation package. Just get in touch.
“Sync” Your Events to Google Calendar
In a previous post we looked at creating and updating a specific Google calendar from a different calendar. The target Google calendar could then be used as a Calendly source that could be kept updated based on a one-way sync from any of your other calendars.
Since DayBack can update a Google calendar from another DayBack calendar, you can also leverage Google’s notifications API. When specified in the API request, Google will send notifications to the attendees/guests associated with the event. This is very slick: the Google API handles what kind of notification to send based on the activity and all DayBack needs to do is to supply the list of attendee emails and to specify whether the notifications should be sent. For example, if an attendee is removed from the event and a new attendee is added to replace them, the removed attendee will get a cancellation notice and the new attendee will get an initial invitation. Other changes to the event, like rescheduling, will be sent as update notifications to the list of attendees with the specific changes pointed out.
In addition to the notification itself, attendees will have a read-only version of the event placed on their Google calendar when they accept. Changes you make in DayBack will then send Update and Cancelation notices to update their event. Since the event is read-only, there’s no danger of their Google calendar getting out of sync with the calendar that sent the notification.
Limitations
This is a “one-way” sync: changes made in DayBack are synced to Google, triggering new notifications as needed, but since users are invited to a Google event they don’t own, they can’t edit the Google event. And even if they could, changes made in Google would not update DayBack, Salesforce, or FileMaker.
The other limitation is that the sync only fires on changes made in DayBack’s interface. Changes made on other Salesforce pages (or on other FileMaker layouts) won’t be sent to Google until the event is edited in DayBack. This is generally a good thing–you want to be making your scheduling changes in your calendar, where you can see the consequences of your changes–not on isolated pages out of context.
Add this to Your DayBack – Calendar Notifications from Salesforce
Designing the Custom Actions
For this example, we’re going to use Salesforce’s standard Event object as the primary (origin) source, but this action could be adapted to any DayBack source that supports additional fields and custom event actions. Your origin could be in a Salesforce custom object, in FileMaker, or in a Google Sheet.
When the origin event is created, a corresponding Google event will be created on the specified Google Calendar. The user will be presented with a dialog asking if notifications should be sent out, mirroring the behavior of when you’re on google.calendar.com. Any further edits (or deleting the event) will update the Google event and the same dialog will be presented in DayBack.
An additional field to store the corresponding Google event id will need to be added to the standard event object and mapped in DayBack.
Defining Your Attendees
In this example, the attendees will be the standard Event owner (Assigned To) the specified Contact. Another additional field will be required where a comma-separated list of additional emails can be specified.
The OnEventSave Action
In the custom event actions, the additional field Ids will need to be specified as the field for storing the Google Event Id and the field for specifying the additional attendees. The names of these fields can be anything. The name of the target Google calendar must also be specified. This is done at the top of each action in the config variables block. The DayBack user must have Google Calendar enabled and be logged in with a Google account that has write access to the specified target calendar. In our example, our target Google calendar is named “Google Invitations From Salesforce”. The calendar does need to be selected in the sidebar but does not need to be enabled.
When the Event Action is triggered, the user will be presented with a dialog about whether to send the notifications or not. The action will then do two SOQL queries to get the standard Event’s owner and contact email. These will be added to the list of email addresses that are sent as part of the request to Google. Here is the sample code for this action:
The OnEventDelete Action
The On Delete action is similar and also needs the Google event id and Google Calendar name specified, but not the attendees as all of the existing attendees will receive the cancelation notice. Here is the sample code for this action:
What Your Notifications Will Look Like
When the “Send Notifications” button in DayBack’s dialog is clicked, the action will compete and the notifications are sent right away. Here we can see them in Gmail with all of the test emails specified for the event.
Conclusions: One-Way Sync to Google Calendar
Keeping everyone updated, whether they’re in your team, outside, or somewhere in between, is an issue all schedulers face. Using Google’s API for handling the notifications is a great choice for its universality and intelligence in managing the notifications themselves. It also provides a way to keep read-only versions of your events up to date for folks who may not have access to your Salesforce or FileMaker environments.
Leave a Reply