Chief Product Officer, GW Apps
In this article we will look at how Collegiate School harnessed the workflow capabilities of GW Apps no-code application development platform to build a custom event management solution. Then, they added seamless Google Calendar integration to the application using Make.com’s automation platform.
Collegiate School is an independent K-12 school for boys in New York City, with a campus on Manhattan’s Upper West Side. The school holds many special events for school functions, admissions events, Parent Association groups, and external groups on its campus. These events require multiple levels of approvals to ensure that events do not interfere with normal school programs, or each other, and that school resources are not overburdened with the extra work required to support them. Additionally, once approved, coordination among multiple departments such as facilities, food service, and technology is required to prepare for and execute events.
The school has long understood the value of using custom solutions to help manage its events, as the required process is very specific and off-the-shelf systems found it hard to mirror that process successfully. Its prior system, built on WordPress and hosted internally by the school’s IT department, was difficult for end users to use and hard to maintain and modify, while also presenting a cybersecurity risk requiring substantial resources to mitigate. Collegiate School looked for a new platform on which to build a better event management system, as well as other workflow-oriented applications. The school focused on looking for flexibility, security, workflow capabilities and ease of development. They finally selected the GW Apps no-code platform, which had the added benefit of being particularly cost-effective.
The Event Management App
In building its new Event Management app in GW Apps, Ben Schworm, Director of Information Technology at Collegiate School, told us they wanted to add integration with Google Calendar in two main ways:
- Once an event is approved in the Event Management app, it must be added to the appropriate room resource calendar in Google Calendar. It must also be updated with any subsequent changes made to the event record.
- Events added directly to room resource calendars in Google must trigger the creation and approval of an event record within the Event Management app in GW Apps.
Collegiate School uses Make.com for the integration with Google Calendar. You could also use a number of other automation platforms, such as: Zapier, Tray.io, Workato, Integrately, etc. This integration saves time and reduces errors compared to having requesters or administrative staff manage events in two systems manually. It also helps Collegiate avoid potential room scheduling conflicts in heavily used, high profile spaces such as dining rooms, auditorium and gyms, by keeping all stakeholders in the loop though a formal approval process when one of these spaces is added to an event in Google Calendar.
For those of you interested in trying something similar, here a few pro-tips from Ben:
Tips for Creating and Updating the Google Calendar Events
- When writing new events to Google Calendar, grab the event ID returned by Make’s ‘Google Calendar – Create Event’ module, and write it to a field in the GW Apps event record. This allows you to easily find that specific Google calendar event again, for future updates (changes & deletes).
- Use Make’s ‘Tools’ module and the built-in date and time functions to parse and format the date, start time, and end time from the GWApps record and store them in variables for use in the start and end date fields within the ‘Google Calendar – Create Event’ module.
- Consider copying the record ID, updated time (last modified time), and any other identifying information from the GWApps event record into the Google Calendar event.
- Use a dedicated Google account, which has full access to the resource calendars, to add Google Calendar entries.
- If you are working with resource calendars, create a GWApps form to store resource calendar information, such as the resource calendar email address, that you’ll need to create an event.
Tips for Updating GW Apps Records from Google Calendar Activity
- If you are watching a Google Calendar and creating new GW Apps event record when a new calendar event is seen, ensure that you have a mechanism to filter out events created by GW Apps to avoid “reflection” entries in GWApps (where events created in GW Apps create an event in Google Calendar, which then triggers the creation of a new GW Apps record). There are a few ways to do this. I use a dedicated Google account when creating events in Google Calendar from GWApps form entries. The scenario (name for an automation bot in Make) that watches Google Calendar is then configured to filter out any event created by that account.
- If any Google Calendars for your rooms have existing, historic events that you don’t want to be added as new event records in GWApps, the Make ‘Google Calendar – Watch Events’ module must be configured to start at a specific date. Right-click on the module and select “Choose where to start” to set the date.
- I have users who “own” rooms and don’t need their event requests for those rooms to go through the full approval process. To allow for this I created Room records that store users who may bypass particular workflow/approval stages when creating an event in that room. I then created a Make scenario that checks this information to set the required workflow stage for the new event record. So, if the user adds events that include a room calendar directly in Google Calendar (ex. a user adding an event in a room they “own”) they’ll start in a later approval stage or just go directly to approved status. This process is on the more complex side and led me to use webhooks within Make to call a scenario from within another scenario. This keeps your Make “code” DRY (modular) so it’s easier to maintain moving forward.
- Consider the security of your GWApps environment when setting up your Make scenarios. GWApps gives you the ability to limit what your API endpoints can do in your app by user, form, and operation (view, create, update, delete, etc). Create different API keys for different levels of access. Also, be careful to limit the exposure of your GWApps API keys and associated credential information within the Make platform. I store it outside the Make.com platform and use a dedicated scenario to manage token retrieval from GWApps, with the “Data is confidential” setting enabled in the scenario, keeping API credentials from being logged at every scenario run. This is not bulletproof security, but it does limit your exposure to an extent. Needless to say, your Make.com environment should also have two-factor authentication turned on.