Properties Settings

Tell Prisma Calendar which frontmatter keys you use — and in what order they live on disk.

Property Order

The Properties tab lists every Prisma property in a single reorderable table. Each row shows the property's purpose and an input to rename its frontmatter key; drag a row (or use the arrow buttons) to change its position.

The row order is not cosmetic: it is the exact frontmatter order Prisma writes to disk. On every save, Prisma pulls its own properties together into one contiguous block in this order, placed where the first Prisma property already sits in the file. Properties Prisma doesn't manage — your own keys, or ones written by other plugins — keep their values and their order relative to each other, flowing above and below that block.

Why this matters: Obsidian appends new frontmatter keys at the end of the file, so the key order depends on the history of edits. Two synced devices accumulate different orders, and from then on every save produces textually different files with identical content — which sync tools (LiveSync, iCloud, Syncthing) report as conflicts, most visibly on auto-written keys like Sort Date. With a deterministic order, all devices converge to byte-identical files and those conflicts disappear.

What a save changes

Given the row order Start Date → Sort Date, a note whose keys arrived in a different order:

---
Project: Website Redesign
Start Date: 2024-01-15T09:00
Tags: [work]
Sort Date: 2024-01-15T09:00
---

comes back from the next save as:

---
Project: Website Redesign
Start Date: 2024-01-15T09:00
Sort Date: 2024-01-15T09:00
Tags: [work]
---

Project sat above the first Prisma property and stays there. Tags sat between two Prisma properties, so the block closes around it and it lands below — its value is untouched, and it keeps its order relative to every other key you own.

Choosing where the block lands

The block anchors on whichever Prisma property comes first in the file, so the keys you put above it decide its position. Keep one of your own properties at the top and the block sits underneath it, as above. Move your own keys below the first Prisma property — or delete them — and the block takes the top of the frontmatter:

---
Start Date: 2024-01-15T09:00
Sort Date: 2024-01-15T09:00
Project: Website Redesign
Tags: [work]
---

Either layout is stable: once the file matches the configured order, later saves leave it alone.

Notes:

• Convergence is eventual — a file adopts the configured order the next time Prisma writes to it. Use Normalize property order to converge everything at once.
• A file with only one Prisma property is left alone — there is no block to form, so nothing moves.
• Multiple planning systems (or plugins) on one directory coexist: each one only groups its own properties, at the position they already occupy — no plugin fights another for the end of the file.
• Keep the order setting itself in sync across devices (it lives in the plugin's data.json), so every device enforces the same order.
• Every explanation panel on the tab folds away once you've read it — click its header to collapse or reopen it. Each panel remembers its own state, on that device.

Normalize property order

The Scan and normalize… button on the Properties tab (also available as the Normalize property order command in the command palette) converges an existing vault in one pass:

1. Scan — every event file is checked against the configured order without writing anything.
2. Review — a dialog lists the files whose Prisma properties are out of order (the first 20, plus a count of the rest for large vaults). Cancel here and nothing changes.
3. Normalize — on confirmation, the listed files are rewritten with a progress bar; the dialog closes with a summary of how many files were updated (and any that failed, with details in the developer console).

Only Prisma's own properties are reordered; your keys keep their values and their order relative to each other, exactly as on any other save. Files already in order are never touched, so re-running it is harmless. Run it on one device after changing the property order and let sync propagate the result — running it on several devices at once would just make them race to write the same files.

Core Event Properties

• Start property (required): default Start Date
• End property (optional): default End Date
• All-day property (optional): default All Day
• Date property (optional): default Date (for all-day events)
• Title property (optional): default Title (falls back to file name when missing). See Title property below for details.
• Skip property: property name to skip/hide event from calendar (default: Skip)

Title property

When the Title property is set, Prisma Calendar uses its value as the event's display name everywhere — the calendar grid, the edit modal, the Gantt bars, the Timeline, the Heatmap day-detail panel, and the events lists. The filename still stores the event and keeps its ZettelID, but the visible title comes from the frontmatter key you configured.

Editing the title in the modal writes the exact text you typed back into that property. ZettelID suffixes and recurring-instance date prefixes live on the filename only — they are never mixed into the property value. This means a title like After Edit stays After Edit in frontmatter, not After Edit-20250101000000.

If Title property is blank, the event's title is derived from the filename (with any ZettelID or instance-date suffix stripped for display).

Priority when resolving an event's display title: Title property (user-controlled) → Calendar title property (auto-computed back-link) → filename.

Sorting Normalization

• Sorting normalization strategy: write a normalized datetime to a dedicated sort property so external tools (Bases, Dataview) can sort all event types by a single field. See Sorting Normalization for External Tools below for full details.
• Sort date property: frontmatter property to write the normalized datetime to. Separate from the Date property used by all-day events (default: Sort Date)

Identification & Tracking

• Calendar title property: auto-computed display title stored as a wiki link with ZettelID stripped (default: Calendar Title). Used for clean rendering in the calendar and Bases views. Always kept in sync automatically. See Event Naming for details
• ZettelID property (optional): when set, a timestamp-based ID is generated on creation/cloning (see ZettelID Naming System for details). Default: ZettelID
• Status property: frontmatter property name for event status (default: Status), used when marking events as done or undone
• Done value: value to set in the status property when marking an event as done (default: Done)
• Not done value: value to set in the status property when marking an event as undone (default: Not Done)
• Custom done property: overrides the default status property for manual mark-as-done actions. Uses the format propertyName value (e.g., archived true, priority 0). When configured, this is used instead of the status property for context menu, modal checkbox, and batch operations. It is also used to evaluate whether an event is done — the context menu shows "Mark as undone" when the property matches. Auto-mark past events is not affected and continues to use the standard status property. Values are auto-parsed: true/false become booleans, numeric strings become numbers, everything else stays as a string. Leave empty to use the default status property behavior (default: empty)
• Custom undone property: overrides what happens when marking an event as undone. Same propertyName value format (e.g., archived false). Requires "Custom done property" to be configured first. If left empty, the custom done property key is removed from frontmatter on undone instead. Default: empty
• Category property: frontmatter property name for event categories (default: Category), used for grouping in statistics views. Supports multiple comma-separated categories (e.g., Category: Work, Learning) — events are counted under each category separately in statistics.
• Location property: frontmatter property name for event location (default: Location), a single string (e.g., "Conference Room A", "Zoom"). Shown in the Create/Edit Event modal when configured. ICS Integration: Location is mapped to the standard LOCATION field when exporting to ICS format and automatically imported from LOCATION fields in ICS files from external calendars (Google Calendar, Outlook, Apple Calendar, etc.).
• Participants property: frontmatter property name for event participants (default: Participants), an array of strings. In the modal, enter comma-separated names (e.g., "Alice, Bob, Charlie"). Stored as a YAML list in frontmatter. ICS Integration: Participants are exported as multiple ATTENDEE fields with RFC 5545-compliant formatting (including mailto: URIs and CN parameters) and imported from ATTENDEE fields in ICS files. Full round-trip compatibility with external calendar applications.
• Break property: frontmatter property name for break time in minutes (default: Break), subtracted from duration in statistics
• Icon property: frontmatter property name for event icon override (default: Icon). Accepts any emoji or text string (e.g., 🎉, 📅, ★). The icon appears in the top-right corner of the event chip on the calendar, taking highest precedence over CalDAV account icons, ICS subscription icons, and recurring event markers. Shown as an input field in the Create/Edit Event modal when configured. See Event Icons for details.
• Prerequisite property: frontmatter property name for event prerequisites (default: Prerequisite). Stores wiki-links to other events that must complete before this event. Assign prerequisites via a searchable modal in the create/edit event dialog or the right-click context menu — events are shown with clean names, colored rows, and date/time labels. Stored as a YAML list of wiki-links in frontmatter.
• CalDAV property: property name for CalDAV sync metadata (default: CalDAV)
• ICS subscription property: property name for ICS subscription sync metadata (default: ICSSubscription)

Notification Property Names

These property names control per-event notification overrides. The notification behavior itself is configured in the Notifications settings tab.

• Minutes before property: frontmatter property to read per-event notification times for timed events (default: Minutes Before)
• Days before property: frontmatter property to read per-event notification days for all-day events (default: Days Before)
• Already notified property: frontmatter property to mark events as already notified (default: Already Notified)

Recurring Event Properties

• Future instances count property: property name for per-event override of future instances count (default: Future Instances Count)
• Generate past events property: property name for generating past recurring instances from source event start date (default: Generate Past Events)
• RRule until property: property name for the inclusive recurring end date (default: RRuleUntil)
• Instance date property: property name for the date of a recurring instance, used to track which occurrence in the series a physical instance represents (default: Recurring Instance Date)

Recurring (node-based)

• RRule property: recurring event type — 9 built-in presets (daily, bi-daily, weekly, bi-weekly, monthly, bi-monthly, quarterly, semi-annual, yearly) or a custom interval using the DSL format FREQUENCY;INTERVAL=N (e.g., DAILY;INTERVAL=5 for every 5 days, WEEKLY;INTERVAL=3 for every 3 weeks, MONTHLY;INTERVAL=4 for every 4 months)
• RRule specification property: weekdays for weekly/bi-weekly (e.g., monday, wednesday, friday)
• RRule until property: inclusive final occurrence day for the recurring series (e.g., 2026-05-22)
• RRule ID property: unique identifier for recurrence
• Source property: link to the source recurring event
• Ignore recurring property: when set to true, excludes the event from future instance generation count (useful for duplicated recurring events)

Example:

---
Start: 2025-01-15T09:00
End: 2025-01-15T10:30
RRule: weekly
RRuleSpec: monday, wednesday, friday
RRuleUntil: 2025-05-30
RRuleID: standup-2025
---

Display Properties

The Display properties section at the bottom of the Properties tab shows extra frontmatter properties inside event chips (scrollable when space is tight).

• Display properties (timed events): comma-separated list of properties to show in timed event chips (e.g., status, priority, project, tags). Shown in weekly and daily views, hidden in monthly view.
• Display properties (all-day events): comma-separated list of properties to show in all-day event chips (can differ from timed events). Shown in weekly and daily views, hidden in monthly view.
• Display properties (untracked events): comma-separated list of properties to show in the untracked events dropdown (e.g., status, priority, category)
• Display properties (heatmap): comma-separated list of properties to show in the heatmap day detail panel when clicking a day

Rendered example inside a chip:

Meeting with Team
status: In Progress
priority: High
project: Q4 Planning

See Also: Untracked Events documentation for details on the untracked events dropdown

How Prisma decides event type

Event type is resolved in two steps. The All Day property is checked first; if it is absent, the type is inferred from the value type of the date properties.

1. The All Day property, when present, decides the type:

• All Day: true → all-day event. The date is taken from the Date property, or, if Date is empty, the date portion of the Start property.

  ---
  Date: 2026-06-01
  All Day: true
  ---

• All Day: false → timed event. The time is taken from the Start property; with no Start value the note is untracked.

  ---
  Start: 2026-06-01T09:00
  End: 2026-06-01T10:00
  All Day: false
  ---

2. When the All Day property is absent, the value type decides:

• A datetime value (e.g. 2026-06-01T09:00) in the Start property → timed event. The End property may hold another datetime, or be left empty to use the default duration.

  ---
  Start: 2026-06-01T09:00
  End: 2026-06-01T10:00
  ---

• Otherwise, a date-only value (e.g. 2026-06-01) in the Date property → all-day event.

  ---
  Date: 2026-06-01
  ---

• Otherwise → untracked (the note is indexed but does not appear on the calendar). This includes a date-only value placed in the Start property with no Date value:

  ---
  Start: 2026-06-01
  ---

A date-only value must go in the Date property to render. A date-only value in the Start property with no Date value is untracked — datetimes belong in Start, dates belong in Date.

Always Include Date and Time Properties

Prisma Calendar automatically ensures that both date and time properties are always present in event frontmatter, regardless of whether the event is all-day or timed. This makes it easy to convert between all-day and timed events by manually editing the frontmatter.

For all-day events:

• The Date property contains the date (e.g., 2025-02-15)
• The Start and End properties are empty strings
• The All Day property is true

For timed events:

• The Start and End properties contain the full datetime (e.g., 2025-02-15T09:00:00)
• The Date property is an empty string by default
• The All Day property is false (or unset)

Benefits:

• Easy conversion: Change an all-day event to timed by adding values to Start/End and setting All Day: false
• Consistent structure: All events have the same property structure, making templates and scripts easier to write
• No missing properties: You can always reference Date, Start, or End without checking if they exist

---
Title: Holiday
Date: 2025-12-25
Start:
End:
All Day: true
---

---
Title: Meeting
Date:
Start: 2025-02-15T09:00:00
End: 2025-02-15T10:30:00
All Day: false
---

Sorting Normalization for External Tools

Event type is decided by the value you write, with the All Day property as an optional override (see How Prisma decides event type above):

• All Day: true → forced all-day, uses the Date property
• All Day: false → forced timed, uses Start/End
• unset → inferred from the value type (date-only Date → all-day; datetime Start → timed)

Sorting normalization strategy:

When a sorting normalization strategy is enabled in Properties Settings, Prisma writes a normalized datetime to a dedicated Sort Date property. This allows external tools (Bases, Dataview, Obsidian search) to sort all event types — both timed and all-day — by a single field.

The Sort Date property is separate from the Date property used by all-day events. This avoids conflicts between the all-day event date and the normalized sorting value.

Normalization modes:

Mode	Timed events	All-day events
None (default)	—	—
Timed only — start	Start datetime → Sort Date	—
Timed only — end	End datetime → Sort Date	—
All-day only	—	Date + T00:00:00 → Sort Date
All events — start (recommended)	Start datetime → Sort Date	Date + T00:00:00 → Sort Date
All events — end	End datetime → Sort Date	Date + T00:00:00 → Sort Date

All datetime values are written without the .000Z suffix. All-day events get T00:00:00 appended so they sort consistently alongside timed events.

Cleanup on event type change: When an event switches to a type the active strategy does not cover (e.g. a timed event converted to all-day while "Timed only — start" is selected, or an event becoming untracked), Prisma removes the stale Sort Date value from frontmatter so sort data stays in sync with the current event type.

Sort date property:

The property name defaults to Sort Date. Change it in the "Sort date property" setting if you prefer a different name.

Important: For Bases views to sort events correctly by this property, the Sort Date property must be configured as a Date & time property type in Obsidian's property settings. If it is set to "Text" or another type, Bases will sort alphabetically instead of chronologically. To fix this, open Obsidian Settings → Properties and change the type of Sort Date to "Date & time", or add "Sort Date": "datetime" to your .obsidian/types.json file.

Migration from previous versions:

In earlier versions, date normalization wrote directly to the Date property, which conflicted with the all-day event date. If you previously used the Date property for sorting timed events in Bases or Dataview queries, enable the sorting normalization strategy (recommended: "All events — start datetime") and update your queries to sort by Sort Date instead of Date.

Multiple planning systems on the same directory

If two planning systems point at the same directory (or one indexes a parent of the other with Index subdirectories enabled) and they disagree on the sort normalization strategy or the sort date property name, they would each rewrite the same events in different ways — leaving your notes in an inconsistent state.

Prisma detects this and:

• Shows a Sort date conflict warning banner in both planning systems' settings, naming the other system and the shared directory.
• Pauses Sort Date updates on both systems until the conflict is resolved — existing values stay untouched.

Resolve it by picking the same sort normalization strategy and Sort Date property on both systems, by giving them different directories, or by disabling one of them.

Auto-mark Past Events

When enabled in General settings, Prisma Calendar will automatically update the status property of past events during startup:

• For all-day events: Checks if the date is in the past
• For timed events: Checks if the end date/time is in the past
• Runs asynchronously: Doesn't block the calendar from loading
• Smart updates: Only writes to files when the status needs to be changed

Example behavior:

---
Start: 2025-01-10T14:00
End: 2025-01-10T15:00
STATUS: In Progress
---

After the end time passes, Prisma Calendar will automatically update it to:

---
Start: 2025-01-10T14:00
End: 2025-01-10T15:00
STATUS: Done
---