After ensuring this feature is the right fit for you by reading the Introduction and Configuration article, you'll be ready to set it up!
Step 1: Unlock the feature for your domain
If you don't already see your domain listed on the SSO and Microsoft 365/Google Workspace settings pages then the first 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 MS365 tenant) for security reasons.
Step 2: Create your butler user
The next step is to create the user account in your MS365 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. Although you're free to customize most of the details of the butler user, there is one "must do" and also a few recommendations.
Must do: Prevent others from viewing the butler's calendar
Considering that the butler will be managing many events on behalf of many users in your organization, it's important to ensure that the information isn't shared. Once you've created your butler account, go to its calendar settings and ensure that nobody is able to view/access its primary calendar.
Log in as the butler, go to the calendar view of Outlook and choose the Sharing and permissions option for the butler's calendar. In the modal dialog that opens, choose Not shared.
General recommendations for your butler user:
Choose an account name that will make the nature of the account clear to everyone. We often recommend "Rooms and Desks Butler" (i.e. first name "Rooms and Desks", 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 MS365. 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).
If you're planning "large-scale" usage of the integration, we recommend reviewing this FAQ.
Step 3: Connect Skedda to MS365
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.
Enter the email of the butler(s) you created in Step 2 in the Butlers field.
Under Conferencing service, we recommend leaving the default selection (MS Teams for the MS365) unless you specifically know that your tenant is special and needs one of the other options.
If you want Skedda to forward RSVP notifications from the butler to the actual booking holder, check the corresponding checkbox. See this FAQ for further information on this option. Note also that this option increases the number of "scopes" that you need to grant when you give Skedda permissions in your tenant (which we'll discuss below).
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 in your tenant.
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 document 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 gives you some information for this, but here's more info.
The person taking these steps needs to have the ability to add (and grant permissions to) Enterprise Apps to the MS365/Azure tenant.
If your MS365 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 MS365 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 granting the verified Skedda app the required permissions for the integration (screenshot below). Review the information and click the "Accept" option to consent. Note that MS365 always shows the full set of permissions that our integration could possibly need. If you don't need to forward RSVP notifications and/or you don't want users to be able to search the full organizational directory, you can remove some of the permissions after you consent (unfortunately Microsoft doesn't seem to make it possible to remove them before you consent). For more information, see the corresponding FAQ below.
Once you've consented, the final step is 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.
Step 4: Create sync rules in Skedda
On the Settings page in Skedda, create your desired sync rules. Head back to this section in the introduction article to learn more.
How can I revoke the MS365 permissions that aren't needed for my configuration?
Microsoft offers the ability to revoke redundant permissions granted to the Skedda app. See the setup section for an explanation of why this might be necessary. To remove redundant permissions, refer to the relevant Microsoft documentation here. Remember to remove only those permissions that you know aren't needed:
If you aren't using the RSVP-forwarding feature, you can remove Mail.Read and Mail.Send.
If you aren't using the full-directory searching feature and you also aren't using the photo-sync feature, you can remove User.Read.All (i.e. each of those features require the User.Read.All permission/scope)
There's also a further step you can take if you want to restrict Skedda's access to your MS365 tenant as much as possible. The consent screen shown in the setup section namely states that you're giving Skedda access to read and write calendars for all your mailboxes, even though Skedda will only ever read and write calendars for your butler user. In this light, after consenting, it's possible to explicitly restrict Skedda's access to only the resources of your butler user.
To do so, simply follow the steps from the Microsoft documentation here. Specific notes for helping you complete the change:
Skedda's App Id is:
PolicyScopeGroupId is the email address of your butler or the email address of a mail-enabled security group containing all the email addresses you wish to grant access for (e.g. if you have multiple butlers).
The PowerShell command to execute then looks like:
New-ApplicationAccessPolicy -AppId 0f198a3c-ad80-44d5-af34-61cfd28e022e -PolicyScopeGroupId <replace with your butler/group email> -AccessRight RestrictAccess -Description "Restrict Skedda app to required user(s) only."
Note that there is a trade-off associated with restricting Skedda's access to your tenant in this way. By preventing Skedda from accessing resources of all mailboxes, certain parts of the integration will cease to function:
When a user is creating a booking in Skedda and searches for people to add to their booking as attendees (e.g. as part of booking a meeting room), Skedda won't have access to query that user's list of associated "people" or "contacts" to show as search matches for selection. However, as long as you check the Allow users to search the full organizational directory checkbox (see the setup section), the user will still be able to query the full directory of users in your Microsoft tenant, with any matches then appearing as selectable attendees on the Skedda side. The user can of course also manually type/paste a full email address of a desired attendee as a fallback.
The photo-sync feature won't function, because Skedda won't have the ability to query the photos associated with all mailboxes.
We have a conferencing "add-on" (e.g. Cisco Webex, Zoom) configured on our MS365 tenant. Can bookings be created on the Skedda side that use this add-on?
No, not at this time. The basic reason is that Skedda uses the standard Microsoft APIs for creating events on MS365, but these APIs have little to no support for using add-ons for the conferencing aspect. That is, Skedda is constrained to use the standard conferencing service in each case (i.e. Microsoft Teams). If the Microsoft APIs become more flexible in this respect in future, we may be able to support conferencing add-ons.