DayBack and Calendly
DayBack can push events from other calendars to Google, so these events block out your availability in Calendly.
DayBack and Calendly both use Google calendars as data sources, which allows DayBack users to maintain their Calendly availability directly in DayBack. Using some Custom Event Actions, DayBack users can set up automation to keep a Google calendar updated based on other calendar activities within DayBack. For example, I may have a Salesforce calendar and two Google calendars set-up, and I want selected events from all three to block out time on the third Google calendar that’s driving Calendly.
We love Calendly. The only problem is that Calendly uses whole calendars to represent your availability. Suppose you have a calendar where only some events should make you unavailable. In that case, you’re likely copying those events over to your “Calendly” calendar.
This custom action automates that. It also lets you send events from other calendar sources into the Google Calendar that Calendly is using for your availability.
If I’m scheduling on behalf of other users, I can also set up some logic in my custom actions to map changes to specific Google calendars for each of my people. And I could add rules that are based on field values. For example, maybe only Salesforce Events marked “Confirmed” update the associated Google Calendar.
Note that this push only works for edits made inside DayBack’s interface. Events created and edits made in your other applications will not be pushed until those events are edited in DayBack Calendar.
Add this to your DayBack: Custom Event Actions
Action #1: On Event Save
To set up a DayBack calendar to update a specific Google calendar a new custom field is required. This field will store the id of the associated Google event and can be given a name like “Google Id Field”, but the name doesn’t matter. Once the field is in place, an On Event Save action can be added. This action will check if there is an existing Google id and if so will update the Google calendar event based on the changes made to the source event in DayBack. If there’s no Google id, the action will create the Google event and write the event back to the custom field. Keep in mind that Google’s permissions are in play here, so the DayBack user will need to be authorized into Google with an account that has write access to the target calendar: basically, they’ll need to be able to see the destination calendar in DayBack’s calendar list, but they don’t need the calendar to be selected (colored blue).
The example action below works any source that supports custom fields (like Salesforce, FileMaker, or Google). This action contains a JSON example of mapping DayBack resources to a specific Google calendar name and should be modified for your organization’s calendars. The variable name is resourceMap. You’ll also want to update the value assigned to the googleIdField variable to match the custom field id from your set-up.
(For an overview on how to add event actions to your DayBack, try this: creating an event action.)
Action #2: On Event Delete
This second action is very similar to the On Event Save action above and will delete the corresponding Google event when an item is deleted in DayBack. Like the On Event Save action, you’ll need to configure the resourceMap and googleIdField in this action.
Going Further: Defend Your Time
And while your focussing on your availability, be sure to defend your time for what’s most important.