Refer to the following frequently asked questions for information on commonly encountered questions when setting up Google Calendar integration for your environment.

• Q. What is the normal flow from reserving a room in iOFFICE and the reservation displaying in Google Calendar?
  
  Using the client's Google credentials, we connect to the calendar via the Calendar API by impersonating the room being reserved. Once that connection is made, the room resource then invites the currently logged in user, and any attendees added onto the reservation.
   
• Q.  What kind of permissions does the service account need?
  
  The service account needs access to all rooms in the integration, in addition to needing the ability to edit room calendars.
   
• Q.  Why do you handle permissions through a service account?
  
  iOFFICE's approach is in line with the principle of least privilege and is specifically designed to limit the amount of access we have to your user information. We use a service account so you have complete control over the resources you want to define as in scope, providing you with complete control and visibility into the integration. We feel this approach is preferable as it limits our access to only what is required to complete the scoped tasks, and nothing more.
   
• Q.  Why does the Calendar API scope need to be included in the project?
  
  There are two parts to the communication process in Google Calendar: 1) the Calendar API used to communicate and 2) the service account that is authorized to communicate as defined in the project. The Calendar API needs to be activated for both the project and the service account (client) so this communication can take place. Once defined, the project makes calls using the Calendar API and the service account (client) is authorized to carry out those API calls on the room resources defined as in scope for the service account. Click here for more information on the Calendar API.
  
  We are aware that there are other methods of defining this process within Google Calendar; however, those methods require businesses to allow third-party providers a higher level of access that includes the following:
  
  1. See and download all of your Google Account email addresses (this means everyone!)
  2. Manage the calendar settings of users on your domain (this is access to all user calendars)
  3. See and download your contacts (ability to view and/or download all of your contact information)
  4. See, edit, share, and permanently delete all the calendars you can access using Google Calendar (total deletion of all calendars certainly wouldn't be ideal, and remember, you are agreeing to grant manager permissions to all user calendars on your domain using this permission structure, so saying "all the calendars you can access" is the same as saying all the calendars on your domain)
  
  When granting these permissions, Google even warns you to make sure you trust the company asking for these super privileges within your environment. At iOFFICE, we believe that we should only have the access that is required and nothing more. Using the Calendar API and service account method, we limit our control and available access within your environment to only the calendar resources you explicitly grant to the service account. We believe this approach limits the potential for issues on both sides of the integration since we more clearly define the scope of access, allowing us to completely avoid your user calendars and focus on only the required room resources.
   
• Q.  Does granting access to the Calendar API give it access to all user calendars?
  
  No. By design, we do not want direct access to your user calendars. The Calendar API scope is limited as follows: "See, edit, share, and permanently delete all the calendars you can access using Google Calendar." This means that so long as the Service Account is only granted access to the room resources, user calendars are not visible to the service account and the service account cannot perform changes on user calendars. Furthermore, there are additional checks beyond the API scope that prevent the service account from using the API to perform actions on calendars that are not explicitly defined. 
   
• Q.  Why do you require us to allow external sharing for primary calendars?
  
  Because iOFFICE's access is limited, we need this permission to be able to manage room resource calendars using the service account. It should be noted that simply allowing external sharing as an option does not automatically share all information externally. The only other way to provide for this level of access is to make a third-party a super-user as described above, with control over all your user calendars by default.
  
  If your organization does not allow employees to share their calendar externally, we recommend enforcing this control through policy rather than using the External Calendar Sharing setting.