Five years ago, we outlined Google Calendar synchronization with TeamDesk. While we used our tools to push the data from TeamDesk to Google, on a way back we needed third-party integrator software (we used Zapier) to handle incoming changes. Now, with an addition of webhooks and iterators we can handle two-way synchronization using solely TeamDesk built-in tools. In this article we’ll show you how.
First, there is the link to sample database:
Example: Google Calendar Two-Way Synchronization
After creating your copy, please visit Setup | Database tab | Tools | 3rd-Party Accounts | Google Account and authorize an account to let access to your calendar. Save and here we go!
From TeamDesk to Google Calendar
Quick recap. Google Calendar has REST API to create and update events. Event in Google Calendar is identified by unique ID. From TeamDesk to Google Calendar the integration is fairly straightforward. When Event record in TeamDesk is added or changed, and has no stored Google Calendar Event ID, you should call Calendar’s REST API insert method and store Event ID returned back. If Event record in TeamDesk already has Google Calendar Event ID, you should rather call Calendar’s REST API update method. You can easily implement this with help of two triggers and a pair of Call URL actions – as described in old article.
Now to the interesting part…
From Google Calendar to TeamDesk
While you can scan for changes in Google Calendar periodically – poll, there is also more effective way: to get the notification on change. Notification is web request Google sends to some URL at third-party system. In case of TeamDesk, webhook can serve as the receiver.
To subscribe to notifications, you should register webhook’s URL with Google API. Would this be one time action, there would be numerous ways to do it, but, unfortunately the registration expires after 30 days. So, if you want to continue receiving notifications you have to renew the subscription. To do this we added Google Calendar Notification Subscription table with buttons to subscribe and unsubscribe and time-dependent trigger to handle automatic subscription renewal once current subscription expires. Once we subscribe our webhook will start receiving change notifications.
Google Calendar’s notifications are short on information. Notification merely denotes the fact some event was added or changed. So, once notification arrives, we call Calendar’s list method to get IDs of events changed or added since last notification. Once we have the list we can check whether ID exists in our Events table and we need to update, or ID does not exist and we have to create new Event.
TeamDesk implementation
TeamDesk implementation takes advantage cascading trigger execution. When notification arrives into webhook, new record is created in Google Calendar Notification table. Record change trigger runs Get Changed Events List action that retrieves the list of changed IDs and stores each one as a record in Google Calendar Changed Event table. The relationship between this table and Events table allows counting events with matched Google Event ID (in fact there could be either none or only one due to unique nature of ID). On …Changed Events there are two triggers. One works when count is zero; it creates new dummy record in Events table is created and flags it for update from Google Calendar’s Event. Another trigger works when count is non-zero; it simply flags TeamDesk Event record for update. In either case, yet another trigger, this time on Events table will call API to update the record with fresh data from Google Calendar.
I can confirm this new method works seamlessly after implementing it last week.
There are a range of actions which can be achieved; an example:
Marking an event (in gCal) to a different color, will trigger an update in TeamDesk.
Where we implanted this was to mark an event as ‘completed’ by changing to ‘red’ –> this pushed to TeamDesk and updated the record appropriately.
The speed at which the actions update is amazing, too.