This section covers the following frequently asked questions for configuring the interview scheduling functionality for Office 365. See also Configure the Schedule Interview Enabled Client Property
1. What level of rights are available to Dayforce when fetching information from Office 365?
2. Do we need write access. Can't it be read-only access?
3. Does Dayforce have full access to the authorizing user’s calendar?
4. Are the settings to enable free/busy sharing at a user level, or organization wide?
7. During configuration, why do you recommend setting the malware filters?
8. During configuration, why must we allow all iPhones as devices? What makes the iPhone special?
9. How does Dayforce manage and safeguard tokens during the integration process?
1. What level of rights are available to Dayforce when fetching information from Office 365?
Microsoft Graph API requires users to give full access to their calendars. This is the most granular permission supported by Microsoft Graph API. Dayforce only accesses the free/busy and room information. This permission doesn’t include access to email.
2. Do we need write access. Can't it be read-only access?
The write access is required to schedule interviews.
3. Does Dayforce have full access to the authorizing user’s calendar?
While full access to the calendar is required by Microsoft Graph API, we use the Microsoft Graph access token only to access the free/busy and room information, and none of the specific details of the events in the user’s calendar.
When a user sets up an interview they must provide full access to their calendar because this is a requirement for Microsoft Graph API. However, there is no code in Dayforce to read other information their calendars, such as private appointments.
4. Are the settings to enable free/busy sharing at a user level, or organization wide?
Once a user authorizes their calendar, they can use the interview scheduling feature and can see the free/busy calendar information for the organization. The settings that enable free/busy sharing for the organization are configured during email setup.
If the user can't see the calendar information after they authorize, it might be because they ignored the message that administrator approval is required. See the next question.
5. Why are users getting the "Need admin approval" message when they try to authorize their calendar?
This message is displayed when the user hasn’t been granted permission to authenticate themselves. To change this, see the next question.
6. How can I control whether users authenticate themselves or whether they require permission when authorizing their calendar for interview scheduling?
To set user permissions for authentication:
- Go to the Azure Active Directory Administrative Center.
- Click Enterprise Applications > User Settings.
- Set both of the following switches to yes if you want users to authenticate themselves. Set both of them to no to require administrative permission:
- Users can consent to apps accessing company data on their behalf
- Users can consent to app accessing company data for groups they own
7. During configuration, why do you recommend setting the malware filters?
In the Suggested Office 365 Settings, there is a section about malware filters. It's a good security recommendation to enable these filters. However, they don’t have anything to do with Interview scheduling and can be skipped.
8. During configuration, why must we allow all iPhones as devices? What makes the iPhone special?
The software we use to schedule interviews is listed as an iPhone device. If your organization doesn't allow iPhones, you must select another option to ensure the interview requests are excluded from the MDM quarantine. Another option is to include a PowerShell script for on-prem Exchange that can exclude by exact device name. Or, your administrator can pull out each device from quarantine manually, one by one.
The step to allow iPhone devices can be skipped; however, it might result in complications.
9. How does Dayforce manage and safeguard tokens during the integration process?
We use authenticated SSL sessions using private key authentication for our scheduling integration.
When users set up their Dayforce account, OAuth2 tokens are authenticated through third-party software for both their calendar provider (Gmail, O365, and so on) and Dayforce.
Dayforce doesn’t have the provider's OAuth2 token and can't make direct calls to the calendar provider; these calls are made through Nylas. The OAuth2 tokens are stored in the Dayforce database.
10. During the integration process is it possible for a malicious user to penetrate the system? If so, what is exposed during the connection?
Dayforce and its third-party authentication software request the minimum access required to schedule events, so only this access would be granted should security be breached. Dayforce only requests the free-busy information of the subjects of an event, as well as room resources. To complete these requests, the third-party authentication software only requests the calendar information of the person scheduling the event and caches this information so that it isn’t stored permanently.
With this calendar integration we request the least information from the calendar providers that we need to perform the scheduling. The permissions granted to us are more than we need, but the calendar provider doesn’t provide enough granularity in the permission settings they require. The permissions granted to us are the minimum we can request to do this scheduling.