Integrating IBSS with Microsoft 365 Calendar has a number of mutually exclusive scenarios. This article intends listing the available options and limitations for you to make the most appropriate choice for your organisation.
There are four options for data to communicate between Microsoft 365 Calendar and IBSS through Graph API. These scenarios cannot be combined:
- IBSS Microsoft 365 Calendar Integration
- IBSS Outlook add-in* (coming soon)
- Microsoft 365 Sync Service
- Connector (Integrations Library)
To select one of these integration options, consider permissions, legal constrains that are applicable for your organisation, and the preferred app where your organisation wants employees to make space bookings.
| IBSS Microsoft 365 Calendar Integration | Connector (Integrations Library) | Microsoft 365 Sync Service | IBSS Outlook Add-In | |
|---|---|---|---|---|
| Primary app for space booking | IBSS to Outlook | IBSS to Outlook | Microsoft 365 Calendar | Microsoft 365 Calendar |
| Privacy concern/Graph API permissions | Delegate permissions |
Delegate and application permissions depending on to which calendar it’s speaking |
Application permissions to resource calendars | Delegate permissions |
| Limitations and constraints | Integrates only with the private calendar for non-M365 Enabled Spaces |
For the M365 Enabled Spaces You have to configure each space individually with this parameter: [Meta_Ext_Booking_System = 1] |
Sync of the Teams meeting link is possible only for this integration option. IBSS features become unavailable such as catering, equipment, etc. Booking policies are disregarded even if they are set. |
For Collaborative spaces. There should be resource in Outlook enabled. |
How it works
Understanding Microsoft Graph Permissions
Microsoft Graph uses a permission model that includes both delegated permissions and application permissions.
Delegated Permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests, and the app is delegated permission to act as the signed-in user when making calls to Microsoft Graph.
Basic path for delegated permissions for IBSS Microsoft 365 Calendar Integration
Delegate Permissions used to create bookings on behalf of a user:
-
Process initiation
The user interacts with IBSS and creates a booking and chooses to sync their calendar. -
User Authentication and Authorisation
The user who is already logged in to the same AAD as their Calendar is successfully authenticated. The user also authorises the necessary permissions (i.e., Roamer > User Preferences > Synchronise Calendar) -
Acquisition of Access Tokens
An access token is created for the user.
This access token grants permission to act on behalf of the user. -
Syncing With User Calendar
Using the access token, IBSS calls the Microsoft Graph API to access the user's Outlook calendar data.
IBSS sends data (bookings) to the user’s calendar via the Graph API.
As a result, the booking created in IBSS is now copied/reflected in Microsoft 365 Calendar.
Basic path for delegated permissions for IBSS Outlook Add-In
- (prerequisite) Installing IBSS Outlook Add-In by admin
-
Process initiation
The user interacts with IBSS and creates a booking. -
User Authentication and Authorisation
The user who is already logged in to the same AAD as their Calendar is successfully authenticated. The user also authorises the necessary permissions (i.e., Roamer > User Preferences > Synchronise Calendar) -
Duplicating User Calendar
Add-In will create the booking before one is created in m365 Calendar.
As a result, the booking created in IBSS is now copied/reflected in Microsoft 365 Calendar.
Application Permissions are used by apps that run without a signed-in user present. For example, apps that run as background services or daemons. Application permissions can only be consented to by an administrator (Microsoft 365 Sync Service).
Basic path for application permissions
Application permissions are used for server-to-server interactions and are common for background services. Here is the general flow:
-
Administrator Consent
An administrator consents to IBSS Sync Server having the specified level of access to all users' calendar data within the organisation (e.g., read all calendars). -
Getting Application Token
The admin generates the token, which is stored against the Sync Service in our configuration. This isn't tied to any specific user but grants access to data based on the permissions consented to by the admin. -
Accessing Calendars Organisation-Wide
With the application token, the Sync Service retrieves calendar data from all users within the organisation and looks for relevant bookings where the room resource matches with a space in IBSS.
The token allows the Sync Service to call the Graph API and pull the relevant booking information from various calendars. -
Syncing Data with Room Booking System
The Sync Service processes these meetings and then creates the appropriate bookings in IBSS for the corresponding user. If changes are made to the booking in the Calendar, these changes are also made to the IBSS booking.
Choosing the Right Permission
Given your organisational choices, you will need to decide which of the above methods are acceptable to your setup:
- If you opt for delegated permissions, you will need to handle consent for each user whose calendar you want to sync. This is currently done via Roamer/Flex user preferences (and should be added to Outlook Add-in). This might be more cumbersome, but it provides additional security by ensuring that each user has agreed to have their bookings synced. But it does also mean that the primary booking information should always be considered to live in IBSS.
- If you opt for application permissions, you will need administrative consent to access all users' calendars within your organisation without individual user approval. This approach is more scalable but also increases responsibility to maintain the security and privacy of the data being accessed. It will also mean that the primary source of information will need to be the Microsoft 365 Calendar, rather than IBSS.
Understanding the Required Calendars Permissions
To read events from calendars, IBSS needs to have specific permissions depending on the type of access (delegated or application). For instance:
- Delegated permissions: Calendars.Read, Calendars.ReadWrite
- Application permissions: Calendars.Read, Calendars.ReadWrite
Privacy and Legal Considerations
Accessing users' calendar data is a significant privacy concern for many organisations. ICONICS via the IBSS platform always handles data compliantly with local laws and regulations, including data protection regulations such as GDPR if applicable. We will also only store the minimal amount of information required about the meeting in our system: meeting title, start and end time, date, attendees, Teams meeting links that are anonymised (for Sync Service and Connector). We don't store the meeting description, any attachments, added services, nor cancellations or check-in times.
Upcoming changes
We are looking to make the following improvements:
-
Change Notifications and Delta Queries
We are currently looking into Microsoft Graph's change notification and delta query capabilities. These should allow us to track changes in data over time without having to repeatedly poll the service. Thereby it will allow reducing the number of API calls that we need to run and only getting the changed data, not the whole set of booking data.