Calendars and event types

A calendar is more configurable than it first appears. What an event type carries and what fields an event may hold are set per calendar, and a service can have as many calendars as it needs. That is how one service can run a release calendar and a leave calendar that look nothing alike.

A service holds as many calendars as it needs

A calendar is a container that belongs to one service. Two calendars in the same service share only the people who can see them. They have separate events, separate types, separate settings, and separate time zones.

That separation is the reason to split rather than to filter. A leave calendar in the team’s zone that opens on the Away view with timed events turned off is a different tool from a release calendar in UTC that opens on Month. One calendar serving both shows every viewer events they do not need.

Names must be unique within a service. When a service has two or more calendars, the calendar name in the header becomes a picker.

A type carries colour, an icon, and sometimes behaviour

An event type is mostly presentation. It gives an event a colour and an icon that follow it into every view, and it supplies the filter pills.

Six types ship with every calendar: Event, Meeting, Milestone, Deadline, Out of office, and Holiday. A calendar can define up to 24. The six built-ins can be renamed and recoloured but never removed.

One of them does more than that. Out of office is the type the availability system reads. The behaviour belongs to the type itself rather than to its name, so renaming it does not stop it closing bookable time. Absence and availability covers what that means in practice.

Colour never carries meaning on its own. Every event also shows its type icon and an accessible label naming the type, so the calendar still reads correctly for somebody who cannot tell two colours apart.

A calendar’s fields are a form

The event dialog is not a fixed layout. Each calendar owns a field set, which is a form in the platform’s own form builder. The dialog renders whatever that form defines, in the order it defines.

That is why Customise fields in calendar settings opens the Forms builder rather than a separate editor. The calendar’s fields and a service’s forms are the same kind of object, so the same tool maintains both.

The built-in fields are protected inside that builder. Title, type, all-day, start, end, who-is-away, attendees, repeats, location, reminder, meeting link, and notes can be relabelled and reordered, but never retyped or deleted. The calendar depends on them meaning what they say: a start that is no longer a date could not be placed on a grid.

Anything you add beyond them is a custom field, stored with the event and available as a column in the list view, a filter, and an option in event display.

What a calendar deliberately is not

Team Calendar is not a scheduling system. There are no resources, no capacity, and no approval step. An event does not consume anything and nobody signs it off, and adding an attendee notifies them rather than asking them.

The calendar is narrow on purpose. Its job is to show what is on and who is away, and to be the single place the rest of the platform reads availability from.