First check out our Introduction and Configuration article, then if you'd like to dive deeper into how exactly this feature works and why it's designed the way it is, then read on!
Overview: Bringing Skedda and MS365/GW together!
More than ever, organizations are looking to allow people to manage all the time-sensitive items in their day-to-day.
Some time-sensitive items can involve the use of an organization's physical "spaces", like:
the hours booked at a working desk and car park at the office,
their meetings with other people (internal or external) in meeting or conference rooms. The concept of inviting attendees, tracking RSVPs and offering conferencing links (for those joining virtually) is critical for such events.
Other time-sensitive items don't involve any of the organization’s physical spaces, like:
meetings where everyone joins virtually,
external site visits (e.g. visiting a customer at some third-party location),
lunch meetings with colleagues (meeting at e.g. a public restaurant),
personal appointments (e.g. hairdresser/massage/doctor appointment).
To a large extent, the generic calendars provided by MS365 and GW are capable of managing a wide range of the time-sensitive items that are important to an organization's users, but they of course can't do everything!
Particularly for hybrid workspaces, modern organizations need more specialized features for optimizing the value of their physical spaces, particularly considering the increasingly ad-hoc, flexible, shared and dynamic way they're being utilized. Some of the top features in this category include:
This is where Skedda comes in. Skedda is a platform dedicated to the management of bookings for physical spaces and offers many such specialized features. Our vision is to be the go-to platform for those bookings that involve physical spaces.
This integration allows Skedda to seamlessly work side-by-side with MS365 and GW calendars. Users can exploit Skedda's specialized interfaces (like floorplans/maps) when making bookings that involve spaces, with Skedda then syncing/managing the corresponding events on their MS365/GW calendar. Other kinds of events (not related to spaces) continue to be created directly in MS365/GW. In this way, the user's MS365/GW calendar can remain a reliable focal point for all the important time-sensitive items in their day-to-day.
Design rationale: Integrity matters!
How does the design work?
Physical spaces like desks, meeting rooms and car parks are defined in Skedda alone. This means that you don't have to have an identical set of resources set up in MS365 or GW. Your MS365/GW tenant can be completely void of resources from Skedda's perspective. Skedda becomes the single source of truth for everything to do with the booking of your organization's spaces.
Bookings for such spaces are managed from Skedda's interface, which is specifically designed and optimized for such bookings. Our interface has all the features and policies configured by the organization baked in to it, and guides the user in a way that helps them achieve their booking goals while ensuring that they don't violate any of the organization's booking policies.
Based on your sync rules, Skedda creates and manages corresponding synced events on the MS365/GW side (including attendee and conferencing support), through your butler user, in a way that intentionally ensures that no changes can be made on the MS365/GW side. That is, any further required changes to the booking are made from Skedda, which is the optimal interface to make changes for such bookings. The synced events on the MS365/GW side include convenient links to guide the booking holder back to Skedda if they wish to make changes.
Where's two-way sync?
As mentioned above and in the Introduction and Configuration article we just offer a one-way sync, but why not two?! That is, if I create a booking in Skedda, can I go and make changes from the MS365/GW side? Or, can I create an event in MS365/GW and have it propagate to Skedda? There are various reasons why two-way sync is problematic! Our one-way design results in a cleaner, simpler solution that upholds the integrity of bookings.
To start, remember that Skedda offers specialized features that MS365 and GW don't (i.e. check-in, quotas and lots more). Many of these features can be bundled under the umbrella term booking policies. These allow the organization to have more control over the way their users book spaces, thereby helping to automate control and optimize the usage of those spaces.
MS365 and GW calendars don't respect such booking policy features, and also don't give third-party apps like Skedda any technical way to intervene if a user were to attempt something in MS365/GW that violated such policies.
Below are a few examples of the kinds of issues that would arise from two-way sync:
Check-in: John doesn't complete the Skedda-managed check-in process for his booking of Meeting Room 2, because he doesn't want to agree to the required check-in confirmation items. Skedda subsequently releases the space (deletes the booking) because he didn't check in, which deletes it from his MS365/GW calendar as well. John then realizes that he can bring back his booking and bypass the check-in items by going to his MS365/GW trash bin and restoring the deleted booking, thereby violating the organization's check-in requirements.
Quotas: A quota rule limits each user to a maximum of 5hrs in the Meeting Room each week. John creates a 5hr booking in Skedda. He extends it to 8hrs via his MS365/GW calendar (which he can't do via Skedda), thereby violating the policies.
Booking window: A window rule that prevents users from booking the Meeting Room more than 10 days out. John creates a booking for 9 days out in Skedda, then moves it to 20 days out via his MS365/GW calendar.
Essentially, many of Skedda's valuable features would become significantly less valuable if two-way sync were used, because we wouldn't be able to guarantee that their function would always be fulfilled.
There are a few additional items worth mentioning:
A design based on two-way sync would require that a set of "resources" be set up in MS365/GW that mirror the "spaces" in Skedda. In addition to this being a pain to set up and maintain, spaces like desks that are much more numerous in quantity would be problematic. MS365/GW calendars aren't designed intuitively for "resource" bookings with that kind of use case and scale.
Whenever two distinct systems need to be in constant sync given changes on either side, the latency involved is non-trivial and the chance of race-conditions increases. For example, Skedda would no longer be able to guarantee "no booking conflicts" with a two-way sync design, because it would now and then happen that John uses MS365/GW to create his desired 9am booking for the Meeting Room at more or less the same instant that Sally uses Skedda to create her desired 9am booking for the Meeting Room, resulting in a conflict.
Many of Skedda's direct competitors that do attempt to offer a two-way sync plainly concede in their documentation that integrity issues can arise as a result, so it's clear that the issues involved are general and not just specific to Skedda.
By not having to support two-way sync, Skedda can remain very agile. That is, we'd have one significant hindrance fewer when it comes to creating additional innovative features to further help you optimize the use of your spaces.
We're confident that our design, which isn't based on two-way sync, results in a clean, viable solution that upholds integrity and allows your users to get the best out of both sides.
Example flow: Conference Room booking with attendees and virtual conferencing
Let's say that Sally needs to meet with Dave and Tim to do a retrospective on a recent project. Sally uses Skedda to create a new booking for Conference Room 2, and opts to sync the booking with Google Workspace ("Microsoft 365" would appear in the MS365 case). She adds Dave and Tim as attendees (by searching for them or entering their email addresses). Sally knows that Tim might be working from home that day, so she opts to include a video conferencing link in case he needs to join remotely.
When Sally confirms the booking, Skedda creates a corresponding synced booking on the butler's calendar with Sally, Dave and Tim all as attendees. They all receive the familiar Google event invitation. Here's the one that Dave receives, for example:
The text in the screenshot is a bit small, but the take-aways are:
Basic information about the event is included in its summary (booking holder name, booking title and space names).
Attendees can do RSVPs in the normal way, either via their inboxes or on their personal calendars. Note that Skedda automatically RSVPs "Yes" on Sally's behalf, (because she's the booking holder and just created the booking in Skedda).
Conferencing information is included.
The organization's butler user is noted as the organizer, and Sally is noted as the booking holder and the contact point for inquiries.
There's also a link for Sally to get back to Skedda to manage the booking, should she wish to make changes.
Here's the same invite for the MS365 case:
When Tim and Dave RSVP, Sally will get those notifications within a minute or so. Tim and Dave can also use the normal functions to propose a new time, and Sally will receive an email with the request (which she can action in Skedda if she agrees).
Any changes that Sally makes to the booking in Skedda will also send out the equivalent familiar MS365/GW notifications to attendees and immediately update the events on their calendars. For example, Sally might use Skedda to extend the duration or cancel the booking, and the changes are propagated to MS365/GW.
Once you're ready, you can start the configuration with the following instructions:
How do RSVPs work?
Skedda automatically RSVPs with "Yes" for the booking holder (i.e. the user that creates the booking in Skedda) in Google Workspace only. With MS365, booking holders are required to RSVP manually. Other attendees can use the familiar functions of their MS365/GW inbox or calendar to RSVP to the invite (see the earlier example for screenshots).
Now, one interesting twist is that MS365 and GW only notify the event "organizer" when somebody RSVPs. The "organizer" is of course the butler user, and its inbox isn't monitored by a real person. For this reason, Skedda's integration supports monitoring the butler's inbox and forwarding RSVPs to the "real" booking holder (i.e. the user to which the booking is assigned in Skedda). Note that there may be a delay of up to 10 minutes before RSVPs are forwarded, however the holder can of course always see the real-time RSVP status directly on their event in their MS365/GW calendar.
How does attendee search work?
When a user creates a booking in Skedda and the addition of attendees is available (controlled by sync rules), the user can type a query to search for the attendees they wish to add (screenshot below). Skedda uses your provider's standard APIs to perform the search. These are:
When Skedda uses your provider search APIs, it "impersonates" the user that's currently logged into Skedda. This is done for obvious security reasons. The user will only see results that they'd normally be able to see if they were searching in similar ways from inside MS365/GW. This behavior implies that if the confirmed email address of the person logged in to Skedda doesn't exist on your MS365/GW tenant, then no useful search results will be returned (but they can still manually add attendees by typing out their email addresses).
Attendee search does not look through the list of users on the Skedda venue account itself. That is, it only searches the MS365/GW lists via the standard APIs mentioned above. This behavior is usually not of significance, because users on Skedda almost always exist on the provider side too (particularly if SSO is being used).
If a user wants to add an attendee that's not in the organization's directory and also isn't in their personal list of contacts (i.e. they're a new external contact), then the user will have to type the full email address manually each time (i.e. even for subsequent bookings with the same attendee). If the user wishes to be able to search for the person by name instead, they should add the person to their list of contacts in their personal MS365/GW account so that the person is found when Skedda makes the API calls listed above.
If I delete an entire space and all its bookings in Skedda, are all its synced events deleted from MS365/GW?
No, Skedda doesn't go and delete all the events from the MS365/GW side if you delete a space with all its bookings in Skedda, because this would involve us needing to do a very large number of API calls in the general case. Normally, we recommend deleting a space in Skedda only when you're sure that there are no outstanding bookings for it.
Are recurring bookings supported?
Yes, recurring bookings are fully supported.
Are "internal"- and "unavailable"-type bookings synced?
No. Only user-type bookings can be synced. Note that "internal" and "unavailable" bookings can only be created by System users (ex. booking admins) in Skedda, so this question isn't relevant to normal Skedda users.
If you wish to sync a booking without specifying a "holder", a System user can create a user-type booking for the "casual user" (the default holder selection in the booking modal for system user-created user bookings), which can be synced.
How many attendees can be added to a booking in Skedda?
Skedda allows users to add up to 100 attendees to their booking. Google and Microsoft have limits not much higher than this, and Skedda is of course constrained by those limits. If you need to add large numbers of users as attendees, consider creating corresponding "Groups" on your provider (e.g. "All hands") and entering the group email address as an attendee in the booking.
To what extent is booking-attendee information exposed to users in the Skedda interface?
The attendees of a booking are only visible in the Skedda interface to the Skedda booking holder and Skedda administrators. To see the attendee information in Skedda, the "view/edit" form for the booking needs to be opened, and this can only be done by the booking holder or a System user. Note that it doesn't matter what is chosen for the "Which booking details are visible?" question in the Access and Visibility settings (the most liberal choice for that question just exposes the booking holder and title information, not attendee information).
Of course, things are a bit different in the MS365/GW interface. There, each attendee will see a copy of the corresponding event in their personal MS365/GW calendar, which includes attendee information (this is standard MS365/GW behavior).
Are custom field values from Skedda propagated to the event in MS365/GW?
No, not at this time. Custom field values are only visible to Skedda System users and the Skedda booking holder (assuming they're not admin-only fields). If we were to send the field values as part of MS365/GW event information, attendees of the event would also be able to see them, which may well not be appropriate.
MS365/GW don't have any clear place to "put" the custom field values, other than in the general event description in text format.
If you wish to vote for a Skedda enhancement that allows custom field values to be synced with MS365/GW events (e.g. by adding a new configuration option to sync rules), then please reach out to our support team and ask for your vote to be counted!