The Three Access Levels Back to top

Every calendar has its own permission list, managed on the Permissions tab of the calendar dialog (calendar actions menu → Edit; Admin access required). Each entry grants one of three levels:

Access level What this level can do
Admin Full control over the calendar:
  • Edit calendar name, color, description, timezone
  • Change the event source (Custom events / Project / JQL / Filter) and date-field mapping
  • Manage event types
  • Manage the permissions list (add/remove subjects, change levels)
  • Create, edit, move, and delete custom events
  • Delete the calendar (Jira issues are never affected)
Use Day-to-day event editing — but not configuration:
  • Create, edit, move (drag), resize, and delete custom events
  • View all events on the calendar
  • Cannot change calendar settings, event types, or permissions
  • Cannot delete the calendar
Read Only View-only access:
  • See all events on the calendar
  • Cannot create, edit, move, or delete any events
  • Cannot change any calendar settings
Permissions govern custom events and calendar settings. Jira issues shown on a Project / JQL / Filter calendar always respect each viewer's own Jira permissions — a calendar share can never reveal Jira issues a person couldn't already see, nor let them edit issues they can't edit in Jira. See Jira Integration.

Who You Can Share With Back to top

The Subject picker on the Permissions tab searches two kinds of principals, and a third can be added directly:

  • Users — individual Confluence users, matched by name.
  • Groups — Confluence groups (e.g. confluence-users, a team group). Access automatically tracks the group's membership.
  • Anyone on this site — every logged-in user of your Confluence site. The simplest way to publish a company-wide calendar.
Permissions tab showing the subject picker and an access table with a USER owner row and a GROUP row with ADMIN lozenges
Which to use?
  • Use Anyone on this site for org-wide calendars (holidays, all-hands, releases) — usually at Read Only.
  • Use a group for team calendars — membership changes in Confluence flow through automatically.
  • Use individual user entries for exceptions — e.g. one stakeholder gets Read Only on an otherwise team-only calendar, or one coordinator gets Admin.

The Owner

The calendar's creator is its Owner: always Admin, cannot be downgraded, cannot be removed. Everyone else's row shows a clickable access lozenge and a remove (×) control.

Changing a level, removing access

  1. Open the calendar's actions menu and choose Edit, then the Permissions tab.
  2. Click the access lozenge on a row to pick a different level.
  3. Click × at the end of a row to remove that subject entirely.
  4. Click Save — nothing changes until you save.

Deactivated users and deleted groups

If a user is deactivated or a group is deleted, their permission rows simply stop matching anyone — no access leaks. The rows remain visible in the dialog, marked "no longer available", so an Admin can prune them.

Sharing Is a Two-Step Process Back to top

  1. A calendar Admin grants access to a user, group, or everyone on the Permissions tab.
  2. Each recipient adds the calendar to their own sidebar via Add Calendars → Add existing (see Favorites).
Granting permission does not automatically push the calendar into anyone's sidebar. Each user manages their own list of calendars. After you share, tell the recipients to open Add Calendars → Add existing — otherwise they may never realize the calendar is available to them.

You can also send a direct calendar link (actions menu → Copy calendar URL) — recipients with access see it in their Shared Calendars row and can favorite it from there. A link is a pointer, not a grant: without a permission entry it shows nothing. See Calendar Hub.

What recipients can do

  • Admin — full actions menu once added: Edit, Delete, New event, permissions management.
  • Use — can create, edit, and delete custom events, but not touch calendar settings.
  • Read Only — can view events; every editing affordance is hidden or inert for them.

Removing yourself vs losing access

  • Remove from favorite — takes the calendar out of your sidebar only. You can always re-add it.
  • Permission removed by an Admin — the calendar disappears from your sidebars and from Add existing. There is no notification; admins should communicate the change.

Site Admins Back to top

Confluence site administrators have implicit Admin access to every calendar. This is a support and offboarding necessity: when a calendar owner leaves the company, a site admin can reassign shares, fix permissions, or delete the calendar.

One deliberate exception: site admins can not edit or delete another user's conditional color rules — those are personal, creator-owned settings.

Need Help?

If you have questions or need assistance, our support team is here to help.

Contact Support