Public Calendar
A public calendar is a shared Salesforce calendar that holds a schedule of events for a group of users rather than one person.
Definition
A public calendar is a shared Salesforce calendar that holds a schedule of events for a group of users rather than one person. Admins create it in Setup, then decide who can see it and who can add events to it. Common uses include company holidays, training sessions, sales events, project milestones, and team shift schedules.
Public calendars sit alongside individual user calendars and resource calendars. They give a team one agreed place for events that everyone needs to see, so people do not have to clutter personal calendars or copy dates by hand. A sales department, for example, can keep one calendar of expos and demo days that the whole team reads from.
How public calendars fit into Salesforce activity management
What a public calendar actually is
A public calendar is one record in the Calendar object, with its Type set to mark it as public rather than a default user calendar, a resource calendar, or a holiday calendar. It is not tied to a single user. Instead it belongs to the org and is shared out to the users or groups who need it. The events on it are standard Event records, so they behave like any other activity in reporting and the activity timeline. Think of it as a noticeboard for dates. A regional team can keep one public calendar for trade shows. A support group can keep one for on-call rotations. Because the events are real Salesforce records, you can relate them to accounts, contacts, or opportunities where that makes sense, and they show up in calendar views next to a rep's own meetings. The point is shared visibility. Everyone reads from the same schedule, and nobody has to maintain a copy in a spreadsheet or an outside tool. That single source is what makes a public calendar worth setting up instead of just emailing dates around.
Public calendar versus resource calendar
Public calendars and resource calendars are created in the same place and look similar, but they answer different questions. A public calendar answers what is happening and when, for a group. A resource calendar answers whether a shared asset is free to book, such as a conference room, a demo truck, or a piece of equipment. Both are Calendar records, and both are shared through the same sharing screen. The practical difference shows up in how people use them. With a public calendar, most users get view access so they can see the team schedule. With a resource calendar, you usually grant add-event access so users can reserve the asset for a time slot, much like checking a book out of a library. Salesforce documents both under the same Setup node, Public Calendars and Resources, which is why the two get confused. If your goal is to publish a shared schedule, build a public calendar. If your goal is to stop two people booking the same room at once, build a resource calendar. Many orgs run both.
Who can see it and who can add events
Access to a public calendar is controlled on its own Sharing screen, not by profiles alone. After you create the calendar, you open it, click Sharing, and add the public groups, roles, or users who should have access. For each one you pick a calendar access level. The levels run from Hide Details, through Hide Details and Add Events, Show Details, Show Details and Add Events, up to Full Access. Hide Details lets someone see that time is busy without reading the event itself. Show Details lets them read event titles and details. The two Add Events variants also let people create events on the calendar. Full Access lets a user view, edit, and delete events plus change the calendar's own sharing. Pick the lowest level that still does the job. Most readers only need Show Details. Reserve the editing levels for the small group who actually maintain the schedule, so a stray edit does not move a company-wide date for everyone.
The Public checkbox and event detail access
There is a gotcha worth knowing before you blame your sharing setup. Calendar sharing controls whether other users can see that an event exists on the calendar. It does not by itself grant access to the underlying Event record's detail page. Those are two separate gates in Salesforce. For viewers to open and read an event's details, the event generally needs its Public checkbox selected, and the viewer needs the right activity permissions. If a user can see a block of time on the public calendar but gets an error or a thin popup when they click it, the cause is usually the event's own visibility, not the calendar's sharing. So when you publish a shared calendar, decide early whether the events should be readable by everyone. If they should, make sure the people creating those events mark them Public. This single setting is behind a large share of the support tickets people raise about shared and public calendars.
Classic, Lightning, and the permissions that gate it
Public calendars predate Lightning Experience and work in both Salesforce Classic and Lightning, though the place you view them differs. In Classic, users switch to a public calendar from the calendar's Change link. In Lightning Experience, users add the calendar from the calendar sidebar so it appears alongside their own. The setup work, creating the calendar and sharing it, is the same in both. Some abilities still depend on the user's permissions, not just calendar sharing. Creating events at all needs the Edit Events permission. Working with activities needs access to activities, and a user who lacks it can hit an error. Some sharing options can also be hidden by organization-wide default settings, so if an access level you expect is missing, check your activity sharing model first. None of this is hard, but it explains why a calendar that looks correctly shared can still behave oddly for one person. When you troubleshoot, separate three layers: the calendar's sharing, the event's Public flag, and the user's activity permissions.
Practical patterns and what to avoid
The healthiest orgs treat public calendars as a small, curated set, not a sprawl. Each calendar earns its place by serving information a real group genuinely shares: company holidays, a training schedule, regional events, a release calendar. When every team spins up its own near-duplicate calendar, users end up toggling a dozen overlays and trust the schedule less, not more. A few habits keep them useful. Name calendars clearly so people know what each one holds at a glance. Decide one owner or small group who maintains each calendar and give only them the add or edit levels. Tell users the calendar exists and show them how to add it in Lightning, because a calendar nobody knows about gets no value. Mark genuinely shared events Public so viewers can read them. Review the set once or twice a year and retire calendars that have gone quiet. Treated this way, public calendars stay a lightweight, reliable layer on top of personal calendars instead of another thing people have to manage.
How to create and share a public calendar
Create a public calendar in Setup, then share it to the right audience. You need an admin who can reach the Public Calendars and Resources page.
- Open the setup page
From Setup, enter Public Calendars and Resources in the Quick Find box and select it. This page lists both public calendars and resource calendars.
- Create the calendar
Under Public Calendars, click New. Enter a clear Name that tells users what the calendar holds, select Active, and click Save.
- Open the sharing screen
On the calendar's detail page, click Sharing, then Add. Choose the public groups, roles, or users who should have access to this calendar.
- Set each access level
For each group or user, pick a calendar access level. Give most people Show Details, and reserve the Add Events or Full Access levels for those who maintain it.
- Add and publish events
Add events to the calendar, and select the Public checkbox on any event whose details viewers should be able to read. Tell users how to add the calendar in Lightning.
The calendar's display name. Make it specific, like Company Holidays or APAC Sales Events, so users can tell calendars apart.
Marks the calendar as available for use. Leave it selected so users can see and share the calendar.
- Calendar sharing only controls visibility on the calendar. To let viewers read an event's details, select the event's Public checkbox too.
- Users without the Edit Events permission cannot create events, even on a calendar shared with an Add Events access level.
- Some sharing access levels can be hidden by your organization-wide default activity settings. Check the activity sharing model if a level is missing.
- Do not over-create calendars. Too many public calendars clutter the calendar view and make users trust the schedule less.
Prefer this walkthrough as its own page? How to Public Calendar in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Public Calendar.
- Create and Manage a Public Calendar or a Resource CalendarSalesforce
- Calendar SharingSalesforce
Hands-on resources to go deeper on Public Calendar.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Public Calendar in Salesforce used for?
Q2. Who creates a Public Calendar and controls who can view or edit it?
Q3. Which use of a Public Calendar reflects the recommended approach for orgs?
Discussion
Loading discussion…