Calendar views
- How any custom type can be displayed as a calendar
- Where the calendar configuration lives and what every key does
- When a type gets a calendar view and how to open it
- How the scheduling example uses calendar views for appointments
- How recurring entries work
In AutoTalk a calendar is a way to view a custom type — not a separate built-in app. Any custom type whose records carry a Date or Date & time field can be shown on a calendar, so you can browse and manage those records by day, week, or month instead of as a flat list.
When does a type get a calendar?
A custom type shows a calendar view when its definition includes a calendar configuration — at minimum, which date/date-time field marks the start of each entry. You can also point it at an end field, a title, a color, and a recurrence field.
Once a calendar is configured, the type gains a calendar view next to its normal list view, reachable from that type's entry in the sidebar. Types without a date field — or without a calendar configuration — appear as a list.
Adding a calendar configuration
The switch is a single field on the type definition: Calendar, on the Custom Types form. It is a raw JSON box — no picker and no placeholder — and the in-app empty state calls what goes in it a calendar block.
The smallest block that works names the start field:
{
"startField": "startTimestamp",
"defaultView": "month"
}
Save, and the type becomes a group in the sidebar with a List view and a
Calendar view under it. A non-empty startField is exactly what that check
looks at: without one the type stays a plain list, whatever else the block
contains.
A fuller block, adapted from the Agendador example's Events type:
{
"startField": "startTimestamp",
"endField": "endTimestamp",
"recurrenceField": "recurrence",
"groupByField": "employeeId",
"colorExpr": "'#23a538'",
"defaultView": "month"
}
The keys
Four of them are dot paths to fields on the record:
| Key | What it points at |
|---|---|
startField | Required. The Date or Date & time field that marks where an entry begins. A record with nothing there is left off the calendar |
endField | Where the entry ends. Without it, the calendar draws a one-hour block from the start |
recurrenceField | A field holding an RRULE string — see Recurring entries |
groupByField | A field to group entries by, such as the employee an entry is assigned to |
defaultView picks the view the calendar opens on — day, week, month or
agenda. Leave it out and it opens on month. A ?view= in the URL overrides
it, which is what makes a particular view shareable as a link.
The other four keys are CEL expressions, not paths:
| Key | What it sets |
|---|---|
titleExpr | The label drawn on each entry |
colorExpr | The entry's colour, as any CSS colour string |
allDayExpr | Whether the entry is drawn as an all-day band |
tooltipExpr | The hover text |
These four are evaluated once for the whole view, with your company in scope
— not the record being drawn. An expression written against the record's own
fields does not fail loudly; it quietly produces nothing, so colorExpr gives
every entry the same colour and allDayExpr is never true.
Until that changes, use them for values that do not depend on the record —
"colorExpr": "'#23a538'" — and let each entry's label come from the record's
own name field, which the calendar falls back to whenever titleExpr produces
nothing.
Two more keys turn up in the Agendador example's blocks — availabilityFromType
and workingHoursType — and nothing reads them. The working-hours overlay finds
that type by its working_hours slug, not through this block, so copying those
two keys into your own type has no effect.
A worked example: appointment scheduling
Nothing provisions a scheduling product for you — a calendar is something you get by giving one of your custom types a date field and a calendar configuration. The quickest way to see a complete one is to import the Agendador example, whose ZIP ships a ready-made set of custom types for appointment scheduling:
| Type | What it holds |
|---|---|
| Events | The appointments themselves — date/time, who, and what |
| Services | Bookable services, each with a duration and price |
| Working Hours | Each employee's normal weekly schedule |
| Employee Periods | Time off and one-off availability overrides |
Events ships with a calendar configuration already in place, so it opens directly as a calendar. This is the same mechanism you can add to any custom type — the example is just a pre-built set tuned for bookings.
The calendar views
A calendar offers four ways to look at the same records:
- Day — a single day, hour by hour. Best for a detailed look at one day's entries.
- Week — the current week across all working hours. Good for spotting gaps and overlaps.
- Month — a full month at a glance. Good for an overview.
- Agenda — a chronological list of upcoming entries.
Use the navigation arrows to move between periods, and filters to narrow down which records are shown (for example, by the employee an Event is assigned to).
Creating an entry from the calendar
Using that example's Events type:
- Navigate to the date with the arrows or by switching views.
- Click a time slot (Day/Week view) or a date cell (Month view) to start a new Event.
- Fill in the record's fields. For Events these are the contact, the service(s), the assigned employee, and the start/end time — but the form always reflects whatever fields your custom type defines.
- Save. The entry appears on the calendar immediately.
You can open any entry to edit it, drag it to a new slot to reschedule, or delete it. For Events, the end time and title can be filled in automatically by the example's workflows (for example, computing the end time from the selected services' durations).
Recurring entries
If the calendar configuration declares a recurrence field, entries can repeat on a schedule instead of being re-created by hand. Recurrence is stored as a standard RRULE string, so a type can express daily, weekly, or monthly patterns (for example, a weekly session every Tuesday at 10:00).
A recurring entry is stored as a single record, and the calendar expands it into one event per occurrence in the visible range. Editing it edits that one record, so a change applies to the whole series rather than to a single occurrence.
How records connect (scheduling example)
In that example, each Event links three other records together:
| Field | What it answers |
|---|---|
| Contact | Who is the appointment for? |
| Service | What is being done? |
| Employee | Who is providing it? |
The Contact is a real contact record, so an Event references the contact rather than copying their details. The example's workflows also stamp a lastScheduledEventAt timestamp onto the contact (used, for example, to follow up after a period of inactivity); the appointments themselves are not listed on the contact's profile. This three-way link is specific to that example's design; your own calendar-enabled types can reference whatever records make sense for them.
Next steps
- Creating a Custom Type — define a type and its fields, including Date / Date & time fields
- Managing records — add, edit, and filter records
- Using Custom Types with AI agents and MCP — let agents read and write calendar records