Per-property message templates
Architectural shift in

Why per-property
Properties differ enough that one global template doesn't fit:
- Different door-PIN-delivery format per property
- Different parking instructions (some have garage, some street, some both)
- Different WiFi sign-on details
- Different building-entry quirks (intercom code, lift card, gate ringer)
A global template forced operators to either (a) handle these via placeholders (which got long and brittle) or (b) accept generic copy that's wrong for half the properties.
each property has its own template set; operator edits per-property without spillover.
Where the editor lives
V28 → Properties → pick property → Message Templates tab.
Per-property mode:
- Each template slug carries a per-language body.
- Edit one property's
checkin_instructionswithout touching the others. - Diff view: "show me what's different between Vydrica and Prístavná" → highlights divergent placeholders.
Inheritance
For templates an operator hasn't customized per-property, the platform falls back to the global template (still present, accessible via the V28 Message Templates editor). So operator can:
- Author a sensible default at the global level.
- Override per-property only where needed.
When you open the per-property editor, templates fall into two groups:
- Overridden (per-property body in effect)
- Inherited (using global default — listed with an
Overridebutton)
Picker shows the right templates
The V28 Inbox REPLY WITH TEMPLATE dropdown previously showed templates with property scope NO TEMPLATES · N OTHER because propertyFkId was a string vs the filter expected number. Fixed; the picker now shows the right per-property templates.
If a property has no per-property templates AND no global default for a slug, the picker shows the inherited fallbacks marked (inherited).
Where templates live
There is no separate global templates table in V28 navigation. Message templates are managed under Properties → pick property (per-property) or Properties → All Properties (defaults).