Our powerful two-way sync feature allows your organization to pair Skedda spaces to Microsoft 365 (MS365) room resources and have events/bookings on one side be synced with full integrity to the other.
This allows your users to review availability (of rooms/attendees) on the Microsoft side and create/manage bookings that will be synced to the Skedda platform. Bookings (with or without attendees) can also be created/managed on the Skedda side and these will be synced to Microsoft.
Check out our FAQs for more information!
How it works - Microsoft
This section outlines how two-way sync works for your organization if you're using Microsoft. All you have to do to get started is follow these outlined 8 steps:
1. Open your calendar
In Microsoft Outlook, open your calendar:
2. Open your "event composer"
Once in your Outlook calendar, click "New event":
3. Select the preferred date for your event
Once your "new event" composer has opened, select the preferred date for your event:
4. Add attendees to your event
Next, add the attendees you'd like to your event:
5. Open the "Scheduling Assistant"
Next, navigate to the "Scheduling Assistant" for the event:
6. Set a preliminary time for your event and select an available room
Your "Scheduling Assistant" will allow you to review availability for your attendees and your chosen meeting room.
If you want to find a specific room, simply search for it in the "Rooms" / "Location" field!
7. Confirm the time for your event
Once you've confirmed your attendees, room, and time, you're ready to finalize everything:
8. Send the invitation... booking synced to Skedda
This is where the magic happens... Once you save the event in Microsoft, your booking will be synced to Skedda for the appropriate meeting room!
Skedda-to-Microsoft bookings
As the name suggests, "two-way sync" allows you to make bookings for rooms in Skedda, and these will be synced to MS365 for the appropriate room!
Settings and setup - Microsoft
This section outlines the process you can follow to set up a two-way sync for your venue in Skedda.
1. Set your time granularity to 15 minutes
Two-way sync requires that you set your time granularity in Skedda to 15 minutes. This is to ensure that synced bookings from Microsoft have the highest chance of aligning correctly with the strict intervals that always exist in Skedda.
You can set your time granularity to 15 minutes on your 'Basics' settings page:
2. Remove all pricing rules
It's worth noting that both pricing rules and online payments aren't things we expect many prospective users of two-way sync to have in place, if any. In the likely case that this is true for your organization, feel free to skip these steps (steps 2 and 3)!
Two-way sync requires that you remove all pricing rules from your Skedda system. This is because Microsoft does not support the notion of chargeable bookings.
You can delete your pricing rules from your 'Pricing' settings page:
3. Disable online payments
Two-way sync requires that you disable online payments in Skedda. This, as mentioned above, is because Microsoft does not support the notion of chargeable bookings.
You can disable online payments from your 'Online Payments' settings page:
4. Unlock the feature for your domain
If you don't already see your domain listed on the 'Microsoft 365/Google Workspace' settings page, then the next step is to reach out to Skedda support. Ask for the feature to be enabled using the support chat widget in the bottom right.
As part of this process, we may need to verify the domain you want to use (i.e. the domain corresponding to your Microsoft tenant) for security reasons.
5. Create your butler user
Please note: If you are switching from our one-way sync feature, you should already have a butler user in place. Please feel free to reuse this butler for two-way sync! We will ensure that the bookings for your butler from one-way sync are replaced as part of the move to two-way sync so that your provider (Microsoft) will reflect the bookings in Skedda at the point you initiate the sync.
The next step is to create the user account in your Microsoft tenant that will serve as your butler. This needs to be done by a tenant administrator (i.e. someone in your organization with the ability to create user accounts).
Your tenant admin can refer to the MS365 docs if they need assistance creating a user account.
General recommendations for your butler user:
Choose an account name that will make the nature of the account clear to everyone. We often recommend "Two-Way Sync Butler" (i.e. first name "Two-Way Sync", second name "Butler"), but you can also choose something like "Skedda Butler" or "Service Account".
We encourage you to appropriately secure the login to the butler user account considering your organization's usual policies. There should be no reason for anybody to need to log in to the butler account, so one approach could be to use a secure password generator to set a very complex login password for the user and not share it with anyone (i.e. "throw it away"). In the rare case that you do ever need to log in to the butler account (e.g. perhaps to diagnose a full mailbox), then a tenant admin can reset the login in order to gain access.
The butler user needs nothing more than a standard calendar and mailbox, so follow the "least privilege" principle and avoid granting it access to other organizational resources.
The butler account should not be a "shared mailbox" account in Microsoft. It should be a "normal" user account. If you use a "shared mailbox" account as a butler user, certain aspects of the integration may not work correctly (e.g. Teams conference links).
6. Connect Skedda to Microsoft
Head to Settings > Microsoft 365 / Google Workspace in Skedda and click the button 'Enable calendar sync'.
The configuration items to complete are explained below:
In the configuration modal select your provider: "Microsoft 365".
In the "Sync type" dropdown, select Two-Way Sync.
Enter the email of the butler you created in Step 5 in the "Butler" field.
When creating a booking in Skedda and adding attendees, the user can always enter a query to search their own contacts (which then display for selection in the dropdown list). If you check the "Allow users to search the full organizational directory" checkbox, the list will additionally include matches from the organization's full directory of users. This option also increases the number of "scopes" that you need to grant when you give Skedda permissions to your tenant.
Additionally, if this box is unchecked, we won’t be able to detect your users' personal details (first name, last name) and will have to use “Unknown” for these values if we have to create their Skedda account when placing their events in Skedda.
If you want Skedda to sync user photos from your provider and display them in useful areas of the Skedda interface, check the "Sync and display user photos" checkbox. See the dedicated support article on user photos for more information.
Once you've configured these items (but before you save them), grant Skedda the appropriate permissions in your tenant. A tenant admin only needs to grant this access once on behalf of the entire tenant. The big blue message in the setup modal gives you some information about this, but here's more info:
Please note: if you have already granted Skedda a number of permissions in order to use one-way sync, please still click the "consent" link seen in the blue info box shown above. Skedda requires additional permission, beyond those which you have already granted, in order for two-way sync to work (`Place.Read.All`). This will allow Skedda to read the list of rooms in your Microsoft account.
The person taking these steps needs to have the ability to add (and grant permissions to) Enterprise Apps to the Microsoft/Azure tenant.
If your Microsoft tenant is identified by the domain of the butler's email address, click on the link shown in the blue message box. Otherwise, copy the link manually, edit it to include your Microsoft tenant ID in place of the "<tenant-id>" placeholder, and then navigate to the link.
Microsoft will show you a page and ask you to consent to grant the verified Skedda app the required permissions for the integration (screenshot below). Review the information and click the "Accept" option to consent. Note that Microsoft always shows the full set of permissions that our integration could possibly need. For two-way sync, you can immediately revoke the permissions for "Read mail in all mailboxes" and "Send mail as any user".
Once you've consented, the final step is to visit the Azure portal and navigate to the Skedda app in your list of Enterprise Apps. You specifically want to make sure that the app (1) is enabled, (2) doesn't require assignment, and (3) is not visible to users in their O365 dashboards (this particular Skedda app isn't designed to allow users to navigate anywhere useful if they were to click on the default "tile" in your organization's O365 dashboard). Here's a screenshot of how it should look:
Once you've added the Skedda app to your tenant, you can click the 'Save' button in Skedda. Skedda will then do a number of tests to make sure it can do everything it needs to do for the integration to work correctly. If these tests all pass, you're done connecting Skedda to your tenant and you can continue with the next step! If the tests don't pass, you've double-checked everything with respect to the validation error shown and you don't know how to proceed, reach out to Skedda support for assistance.
7. Create sync pairs in Skedda
Before you move forward with Step #7, please carefully read the following important note!
What happens when you activate Two-Way sync for your spaces/resources?
There are some significant impacts to enabling Two-Way Sync for your Skedda spaces and Microsoft resources that we've outlined below. You should only proceed with this step if you're happy with the following things happening to your systems when you begin mapping space-resource pairs in Skedda.
Before we enumerate the steps, it's worth commenting on the general approach we've taken for the initial sync procedure. We consider the Microsoft side the "primary source" of information for the initial sync, and the Skedda side a "secondary source". That is, our initial-sync procedure is designed to completely "clean out" the Skedda space (i.e. delete all existing Skedda bookings for the space), then fill it with all the information obtained from the events for the Microsoft resource, then perform a "best-effort" restoration of the Skedda-side bookings that were cleaned out. In this way, we're able to retain as much information as possible from both sides, while ensuring basic sync integrity once the process has been completed.
Here are the steps in detail:
(1) Finding and noting all upcoming bookings you have for the Skedda space
First, we'll find and note the upcoming bookings you have for the Skedda space being paired. We'll need these later in the process to achieve our "best effort" restore after populating Skedda with all events obtained from the Microsoft side. The upcoming bookings that we note in this step are those that align with the basic requirements for two-way sync:
Only those bookings for "today or later" are noted for later attempted restoration. Past bookings are not.
For clarity, we will remove all bookings from the past and not attempt to restore them. While we recommend exporting your booking data if you'd like to retain this information, please note that your in-Skedda analytics will be affected after these past bookings are permanently deleted (bookings cannot later be bulk-imported for two-way synced spaces).
If you have repeating bookings that have occurrences situated in the past, note that we will not restore these occurrences. We will only attempt to restore the occurrences that occur "today or later".
For example, if you have a repeating booking that has three occurrences in the past, and four more that have not yet taken place, we will attempt to restore only the four upcoming occurrences, and will not attempt to restore the three occurrences that have already taken place.
Only those bookings with an actual booking holder are noted for later attempted restoration because we require all bookings for synced spaces to have a booking holder with an active calendar on your provider (Microsoft). "Casual-user" bookings, "Internal" and "Unavailable" bookings are hence not noted for later restoration.
Bookings with an existing one-way sync relationship are noted for later attempted restoration (as long as they also satisfy the above conditions).
Bookings with an existing two-way sync relationship with an external MS365 event are not noted for restoration (such bookings will however have an equivalent event on the Microsoft side that will be copied over in the later step in the process, assuming the external resource in question is the same).
Note: Skedda won’t sync events that contain more than 10 booked synced resources, and will delete these in Outlook instead of placing them in Skedda during the initial sync. Before you proceed, please consider "breaking up" such resource bookings into individual events that do not reserve more than 10 resources at a time.
(2) Deleting any one-way sync bookings
Next, if any one-way sync bookings were found in the first step, we go and delete them from the "butler" calendar on the Microsoft side. The intuition here is that these events will end up being recreated directly in the "resource" calendar, so we need to remove the equivalent "butler" events in order to prevent a double-up.
If your users receive email alerts from Outlook about these occurrences, the communication will include a note from us explaining that these removals are part of a system-level update and that they will be replaced with equivalent bookings in the coming minutes.
(3) Deleting all bookings from the Skedda space
Next, we delete all bookings from the Skedda space. Bookings for multiple spaces will be retained on Skedda for their other spaces (i.e. if you're pairing space A on Skedda with resource X on Microsoft and there's an existing booking on Skedda for spaces A and B, then space A will be removed from that Skedda booking).
Note that we will not send any notifications from Skedda for bookings that are deleted. The intention here is to avoid bothering people with, potentially, 100s of email alerts while your initial sync is underway!
(4) Inspecting the external Microsoft resource for all upcoming events
Next, we inspect the external Microsoft resource, find all the upcoming events for it, and add these to the Skedda side. In certain edge cases, events may not be able to be added to the Skedda side at all (i.e. events that span midnight, events that violate a Skedda space-sharing relationship). In such cases, the relevant organizers will be notified that their event has been canceled.
In addition, some adjustments may be made to the events on the Microsoft side in order to make a 2WS relationship possible for them:
We will appropriately adjust any events in your Microsoft resource that do not have start and end times that end at 15-minute intervals.
We will shorten any repeating/recurring events in your Microsoft resource to be for 1,080 days into the future at the maximum. This is due to Microsoft-side limitations for room resources that do not allow repeating/recurring events to exceed 1,080 days into the future.
Please note that we do not touch any of your past events in Outlook. We are concerned only with bookings that occur from "today and onwards".
(5) "Best-effort" attempt to restore original Skedda bookings for the space
Finally, using the set generated from Step 1, we make a "best-effort" attempt to restore the original Skedda bookings for the space. There are also a few cases in which a given booking will not be able to be restored at all. These include:
If it conflicts with a booking that was added from the Microsoft side in Step 4 above,
If the booking holder doesn't exist in the Microsoft directory.
Note that Skedda bookings are restored without any check-in data, lock-in margins, custom fields, or pricing info they may have had originally.
Please also keep in mind that:
The initial sync process CANNOT be canceled once it has been scheduled, so make sure you triple-check your pairing before you add it!
During the initial sync process, be sure to prevent your users from making any bookings for spaces that are syncing. The process must continue uninterrupted to avoid irregularities.
Back to Step #7...
Important note: If you have at some point in the past changed (or you plan to change in future) the name or the email addresses of your room resources on MS365, there is a risk that our initial sync process will not work correctly.
If this is relevant for your case, please don't proceed further and reach out to us. Our Support Team will work with you to advise on the best course of action.
Now that you've connected Skedda to Microsoft, the last step involves creating sync pairs (mapping) between spaces in Skedda and their corresponding rooms/resources in Microsoft. This guide assumes that you have already created rooms/"resources" in Microsoft.
If not, please ensure that you have created your rooms in both Skedda AND Microsoft before proceeding, so that you can find each when creating sync pairs!
To create sync pairs, under the "Sync Resources" section:
Click "Sync new resource".
In the modal that appears, select from the respective dropdowns:
the Skedda space you want to sync.
the Microsoft resource/room you want to sync.
Click "Sync" to complete the pairing.
Skedda will perform some background work to action your request (this takes place for a few minutes after you've clicked "Sync", so keep an eye on your settings page to check the progress of this step!)
Once you've paired your FIRST resource, STOP! Wait a few minutes until our background work is completed, refresh your browser, and inspect both your Microsoft resource and Skedda space for any inconsistencies. In the unlikely event that something has not gone as expected, please reach out to us so we can investigate further before you proceed with further pairing (you should be inspecting your resource-space combo for any inconsistencies "from today onwards").
You can then move on to pair your next resource after confirming that your first pair has synced successfully.
8. Unsyncing space-resource pairs
You can unsync space-resource pairs by heading over to your "Microsoft 365 / Google Workspace" settings page, and clicking the "Unsync" button next to the space-resource pair you'd like to unsync.
FAQs
This section includes answers to a number of frequently asked questions about how Skedda's two-way sync feature works.
What happens if two-way sync "breaks"?
If two-way sync stops working for your organization, for any reason, our Support Team will reach out to you, as soon as we detect an error, with information on how to fix the issue. In general, the most likely reasons a sync will "break" are:
Resource deleted in provider: if you delete a resource on your provider side, but haven't unsynced the space-resource pairing in Skedda, then this will create an error and we'll see this flagged in our logs. Our team will reach out about this if we see it happen! (We do recommend, of course, that you "unsync" the pairing before you delete a resource in your provider to avoid this error altogether!)
Permissions revoked/error: Skedda relies on a number of permissions to be granted in order to make the two-way sync between your spaces and resources work. If these permissions are revoked for whatever reason, we will see this flagged in our logs. Our team will reach out about this if we see it happen. (Again, we recommend "unsyncing" their space-resource pairs in your Skedda account before changing any permissions you've given Skedda deliberately.)
If you delete a space in Skedda, we will automatically remove the sync pair that exists for the affected space, which will avoid triggering any errors on our side. The assumption here is that you are happy to take this action given that you're deleting the space on the Skedda side.
I've encountered the "Error while validating [your domain]: Access to OData is disabled" error - what do I do?
To correct this issue, please ask one of your Microsoft admins to run the following Powershell command (one of the ExchangePowerShell cmdlets) to see if any application access policies exist that are preventing Skedda from validating your domain:
Get-ApplicationAccessPolicy | Format-Table -Auto Identity,Description,ScopeName,AccessRight
This will help in diagnosing if there are any access policies that need to be removed or adjusted. If there are any policies that are returned in the results you see, please remove or modify the policy to allow Skedda to complete the validation process for your domain.
If you have any questions before you perform this action, please reach out to our Support Team and we'll assist where we can!
Are charged/paid bookings in Skedda supported by two-way sync?
No, charged/paid bookings in Skedda are not supported. This is because Microsoft/Google does not support the notion of chargeable bookings in the way Skedda does, and there's also no intuitive way to make users aware that they're making a booking for a space that will attract a charge via Microsoft/Google's interface.
Are overnight bookings supported?
No, overnight bookings are not supported. This is in keeping with our current platform logic and numerous customizable venue rules/logic that rely on booking durations being constrained to 24-hour calendar-day periods at the maximum.
If your users need to book out a meeting room for a purpose that will span across midnight, we recommend they create two bookings to cover the full duration across the two calendar days.
Are repeating bookings supported?
Yes, repeating bookings are supported! Microsoft will limit recurring bookings for up to 1,080 days ahead (if you've specified this to be the uppermost limit), and Google will limit recurring bookings for up to around 730 occurrences.
Does two-way sync respect my Skedda venue rules?
To allow for the smoothest booking experience, all two-way sync bookings from Microsoft will disregard venue rules in Skedda. MS365 doesn't respect Skedda's sophisticated rules engine and doesn't give us an opportunity to tell users that a booking they're making on the Microsoft side wouldn't be "allowed" by your Skedda venue's rules before it gets made.
With this in mind, disregarding venue rules for all bookings made from the Microsoft side allows for a no-hassle booking process for your meeting rooms, and allows your users to avoid the confusion that would have arisen from attempting a failed booking in Microsoft with no insights as to why it wasn't allowed before making it.
Can we use two-way sync and one-way sync at the same time?
No, you can only use two-way sync or one-way sync at any given time - not both.
Can we set up an integration with both Microsoft and Google at the same time?
No, you can only integrate with one tenant/provider at any given time.
How does two-way sync handle "race conditions"?
"Race conditions" refer to the rare case where two bookings come in requesting the same space/resource at exactly the same time, one from Skedda and the other from Microsoft/Google.
In these cases, we will treat Skedda as the "system of record/ground truth" and remove the Microsoft/Google booking that conflicts with the booking in Skedda.
What happens with bookings that don't begin and end at 15-minute intervals?
Skedda will require that all two-way sync bookings from Microsoft/Google must have durations that respect the 15-minute time intervals set in the platform. This means that, for example, a booking that runs from 10:12 am - 13:51 pm will not be allowed to stay this way when synced.
Here are a few examples of what we mean:
Original booking | Changes to |
1:53 PM-2:07 PM | 1:45 PM-2:00 PM |
1:55 PM-2:05 PM | 1:45 PM-2:00 PM |
1:59 PM-2:01 PM | 1:45 PM-2:00 PM |
1:45 PM-1:46 PM | 1:45 PM-2:00 PM |
1:52 PM-2:06 PM | 1:45 PM-2:00 PM |
2:01 PM-2:16 PM | 2:00 PM-2:15 PM |
2:02 PM-2:18 PM | 2:00 PM-2:30 PM |
What is the logic behind such behavior? We apply the following adjustment logic to all cases:
We will round all bookings up to the closest 15-minute interval step.
We will choose the 15-minute interval time-point start that allows the adjusted booking to maximally cover the original event that came from the Microsoft/Google side.
In cases where there are two bookings that require adjustment and that tie, we will resolve these by using the earlier 15-minute interval.
This results in a clash-free system that provides your users with as close a booking as possible to the original booking they synced from Microsoft/Google.
It's important to clarify that this logic applies only to bookings that don't start and end at 15-minute intervals. The vast majority of "regular" booking durations will not require adjustment, for example, an 8:00 am - 8:15 am stand-up meeting, a 10:00 am - 11:00 am board meeting, a 13:00 pm - 13:30 pm project planning discussion, etc.
What happens with bookings that are shorter than 15 minutes?
As outlined above, our "adjustment logic" will kick in to round all bookings shorter than 15 minutes up to 15-minute bookings.
What subscription is required to use two-way sync?
Two-way sync is available to all Premium-tier subscriptions at no additional cost!
Why do I need to disable pricing rules and online payments, and select a 15-minute time granularity to use two-way sync?
Pricing rules and online payments
Pricing rules and online payments are not supported by Skedda's two-way sync feature. This is because Microsoft/Google does not support the notion of chargeable bookings in the way Skedda does, and there's also no intuitive way to make users aware that they're making a booking for a space that will attract a charge via Microsoft/Google's interface.
15-minute time granularity
Skedda requires that venues have a time granularity set in the platform settings that enforce uniform start/end times across set intervals of time: 15 minutes, 20 minutes, 30 minutes, and 1 hour. Bookings are not allowed to have start/end times that do not land on the intervals as set in the platform settings.
With this in mind, to ensure that the highest number of synced bookings from Microsoft/Google come through successfully without needing adjustment (as outlined in this FAQ), we require that venues set the smallest time granularity possible - 15 minutes.
Does two-way sync support custom fields?
No, custom fields are not supported for two-way sync bookings. This is because Microsoft/Google do not have equivalent fields to support the reception, and editing, of such custom fields found in normal Skedda bookings.
You can make bookings on the Skedda side and include custom fields, but these fields will not be synced across to bookings in Microsoft/Google.
What happens if a booking from Microsoft/Google "can't work" in Skedda?
If a booking from Microsoft/Google for a meeting room can't be synced to Skedda, the relevant user will receive an email notifying them of the reason for this issue. Generally, the only reasons a booking won't get synced are:
There is already a booking in place for the space in Skedda (i.e. very shortly before they attempted to book the space, it was booked by another user).
There is already a booking in place for a dependent space in Skedda (this will only be relevant if you use space-sharing rules for your meeting rooms).
The user attempted to sync an overnight booking from Microsoft/Google to Skedda (as outlined in this FAQ, these are not supported).
What happens if a resource pairing fails while I'm setting it up?
Most likely, this will be as a result of a permission failure. When you click "Save" for the given space-resource pair, we'll add it to your list of pairs. At this point, we attempt to complete the subscription process. If we fail to complete the subscription process at this stage, we'll let you know with an error message.
In order to resolve this issue, we recommend that you double-check that you've assigned the correct permissions to Skedda, in order to support the two-way integration. These permissions are typically granted during the setup instructions that you'll find in the sections above. After this, you can remove the affected sync pair and attempt the pairing again.
If, after you've double-checked this, the error persists, please reach out to our team and we can assist further.
What happens if we unsync our spaces from our rooms/resources?
If you unsync your space pairings, we'll stop syncing bookings across Skedda and Microsoft/Google, and schedules between these two systems will no longer be kept current with each other.
Will our Google/Microsoft-side integrations work with two-way sync?
Bookings made from the Google/Microsoft side with all the relevant controls in the event composer will be able to fire off any integrations that you've set up in this way.
As with one-way sync, all known 3rd-party integrations will not work for bookings initiated in Skedda.
Can users without an active calendar on our tenant/provider book two-way sync spaces?
No, all bookings for two-way sync spaces must have holders with active calendars on the tenant/provider that you've connected to Skedda for your two-way sync integration. We require an active calendar in order to place the synced booking from Skedda into Microsoft, thus reserving the synced space.
If a user without a calendar on your tenant/provider attempts to make a booking, we'll remove the booking from Skedda and ensure that it is not synced to your external provider in order to ensure scheduling integrity across both platforms.
We enforce this constraint to ensure total scheduling integrity between your external provider and your spaces in Skedda. Without an active license (and, in turn, a calendar) the user in question wouldn't be able to access your resources in Microsoft / Google, and we therefore assume that you wouldn't want them making bookings for the same spaces in Skedda (which, as previously mentioned, would cause integrity issues across the two systems in any case).
Technically, what access to our Azure tenant does Skedda need for the 2WS integration, and why?
If you’re an IT admin for your organization, you’re likely interested in understanding how Skedda will access your Azure tenant. In line with best-practice security principles like “least privilege”, Skedda should be given the minimal set of permissions to your Azure tenant that allows the 2WS feature to function.
Below you’ll find the full list of permissions that Skedda requests when you are asked to consent, alongside a justification for each in the context of our 2WS feature.
Calendars.ReadWrite: Skedda’s 2WS feature depends heavily on this permission to function. For example, when Sally (a member of your organization) creates a booking in Skedda for a space Meeting Room 1, Skedda needs to be able to create a corresponding Outlook event on Sally’s Outlook calendar, and that event should also reserve the corresponding MS365-managed “Meeting Room 1” resource. The event is created on Sally’s calendar to make her the “Organizer” of the event, which allows her to manage the event from Outlook as well as from Skedda. Skedda needs write permissions to Sally’s calendar in your Azure tenant to achieve this. Sally is just one example of course: Skedda generally needs write permissions for the calendars of all your Azure tenant’s users to enable the same behavior for each of them. It’s worth noting that Skedda needs to read from the relevant Outlook calendars as well (e.g. if Sally were to make a change to her event on the Outlook side, Skedda needs to be able to fetch the full details of the event so that the changes can be propagated to the Skedda side).
Place.Read.All: Skedda’s 2WS feature depends heavily on this permission to function. Without it, Skedda would not be able to discover which “resources”/”rooms” exist on your Azure tenant, and would also not be able to “subscribe” to be notified when changes happen to events that reserve them. Without such notifications, Skedda would be left “in the dark” if someone used Outlook to create a new event for a resource, and hence Skedda would not be able to create a corresponding booking on the Skedda side.
Contacts.Read, People.Read.All: These permissions enable Skedda to list the “contacts” and “relevant people” of the users in your Azure tenant. This is required to provide the attendee-lookup functionality during the booking process on Skedda. For example, when Sally (a member of your organization) creates a booking for a meeting room in Skedda, she wants to search for all the people she wishes to invite as attendees. Without these permissions, Skedda would not be able to show Sally a list of matches in the attendees search-box as she types. Every user has a different list of “contacts” and “relevant people”, hence Skedda needs this permission for all users on your Azure tenant (not just Sally) to enable the same behavior for everyone.
User.Read.All: This permission allows Skedda to read the user-profile information of all users on your Azure tenant. In the context of two-way sync, Skedda needs this permission for two reasons. Firstly, imagine that Sally (a member of your organization) has never used Skedda before, but she creates an event on her Outlook calendar that also reserves “Meeting Room 1”, a MS365 resource that is “paired” with a corresponding space in Skedda. When Microsoft notifies Skedda about the new event that was created for “Meeting Room 1”, Skedda needs to create an associated booking on the Skedda side and set Sally as the “holder” of that booking. This implies that Sally needs to be created as a user on the Skedda side because she hasn’t used Skedda before and doesn’t yet exist as a user on the Skedda side. In order to create Sally’s user profile on the Skedda side, Skedda needs the ability to fetch Sally’s profile information from the Microsoft side. Sally is just one example of course: Skedda generally needs read permissions for the profiles of all your Azure tenant’s users to enable the same behavior for each of them. Secondly, assuming you check the relevant checkbox in the Skedda-side configuration, Skedda uses this permission to enhance the attendee-lookup functionality during the booking process on Skedda (i.e. allowing Sally to search for meeting attendees from the full organization when she creates a booking on Skedda, not just her personal “contacts” and “relevant people” lists).
Mail.Read and Mail.Send: These permissions are NOT required for the 2WS variant of our MS365 integration and we encourage you to remove them from your “Enterprise Application” instance in Azure immediately after you consent. To remove redundant permissions, refer to the relevant Microsoft documentation here. For context: this permission is only required for the one-way sync variant of our integration with MS365, because that variant has a particular need to interact with the so-called “butler’s” inbox (see the one-way sync article for more information).
Note that Skedda has strict internal security policies in place to prevent the misuse of permissions that you grant to Skedda (see here for more information). Please feel free to reach out to our support team if you have any questions.
Finally, please also note that you should generally not create any so-called Application Access Policies in your Azure tenant to limit the way that Skedda can access your Azure tenant. While this is possible and sensible for the one-way sync variant of Skedda’s MS365 integration (as discussed here), doing so for the 2WS variant will likely break the integration in various ways.
Are private events supported?
Skedda does not yet support the syncing of private/confidential/personal events, but support for such events is coming soon! For now, please create all events as public events, and be sure not to include any sensitive information in the event’s title, description, attachments/links, and any other available fields.