There are two different ways to share calendar and event data with others.
Firstly, you can share an entire calendar, with a specified level of access. For example, you can create a team calendar, and then do things like:
- Grant all members of your team the right to add and modify events in the calendar
- Grant your boss the right to see the events on your calendar
- Grant your customers the right to only see when you are free or busy, but not the details of the events
You can also adjust the access to individual events on the shared calendar.
Alternatively, you can invite others to individual events on your calendar. Inviting someone to an event will put a copy of that event on their calendar. The invitee can then accept or reject the invitation, and to some extent also modify their copy of the event — for example, change the color it has in their calendar, and add a reminder.
The owners of a calendar can share the calendar by giving access to other users. The sharing settings of a given calendar are represented by the ACL collection (access control list) of that calendar. Each resource in the ACL collection grants a specified grantee a certain access role, which is one of those listed in the following table:
|Role||Access privilege granted by the role|
||Provides no access.|
||Lets the grantee see whether the calendar is free or busy at a given time, but does not allow access to event details. Free/busy information can be retrieved using the freeBusy.query operation.|
||Lets the grantee read events on the calendar.|
||Lets the grantee read and write events on the calendar.|
||Provides ownership of the calendar. This role has all of the permissions of the writer role with the additional ability to see and manipulate ACLs.|
The possible grantees are:
- another individual user
- a user group
- a domain
- public (grants access to everyone).
By default, each user has owner access to their primary calendar, and this access cannot be relinquished. Up to 6,000 ACLs can be added per calendar.
For Google Workspace users, there are also domain settings that might restrict the maximum allowed access. For example, suppose your domain has a setting that only allows free-busy calendar sharing. In this case, even if you grant writer access to the public, users outside the domain will only see the free-busy details.
Once the calendar is shared, you can adjust the access to individual events on a calendar by changing the visibility property of the event. This property has no meaning for non-shared calendars. The following table lists the possible values of the visibility property:
||The visibility of the event is determined by the ACLs of the calendar.|
||The details of this event are visible to everyone with at least
||The details of this event are only visible to users with at least
Inviting attendees to events
You can share an event with other people (or group calendars and resources) by adding them as attendees. This sends an invitation email to the attendees and places the event on their calendar.
Shared event properties
The calendar where the event is created is the organizer calendar. This calendar owns the shared event information (id, start and end time, summary, description, etc.). When this information is updated on the organizer calendar, the changes are propagated to attendee copies.
Private event properties
Not all information is shared between all the event copies. Some properties are private, such as reminders, colorId, transparency, or the extendedProperties.private property. These properties are controlled by the attendee's settings and not by the organizer calendar.
Attendees can also change the shared properties of the event. However, these changes are only reflected on their own copy and might be lost if the organizer makes a change.
The only event change that is propagated from attendees back to the organizer is the attendee's response status, stored in the attendees[ ].responseStatus property.
The following diagram explains the dynamics. At first Jack creates an event on his primary calendar (and thus owns the organizer copy). Then he invites Susan and the Cello lesson group secondary calendar. Attendee’s copies are created on the invitees calendars. Then Susan responds and the change gets propagated back to the organizer, updating the organizer’s copy with Susan’s response. These changes made to the organizer's copy of the event then get propagated to all the other attendees.