Calendar Invites
An e-mail template can carry a meeting invitation, with its details mapped from the record the e-mail is about.
Where to find it
Architect Panel → Layout & Pages:
- E-mail Templates — the template that carries the invite
Architect Panel → Integration & Connections:
- E-mail Accounts — the mailbox that becomes the organiser
Mapped from the record
Start, end, location, notes and any online meeting link come from the record, using the same field and variable vocabulary the subject and body already use. So one template produces a correct invitation for every appointment.
Described early, rendered late
The invitation is resolved into a description when the e-mail is generated, and turned into calendar data only at the moment of sending. That split is deliberate and it is what makes the invitation work.
Generation knows the record but not the recipients or the sending mailbox — the caller supplies those. And both matter:
- Gmail shows no RSVP controls unless the recipient’s own address appears as an attendee.
- Outlook shows no Accept or Decline unless the organiser is a real mailbox.
An invitation built any earlier would be addressed to nobody and be silently impossible to accept — which looks exactly like a working feature until somebody tries.
Sent twice, on purpose
Every invitation goes out both as a calendar part inside the message and as an attached file, carrying identical content.
Outlook shows its Accept and Decline banner only for a calendar part whose method matches the payload; some other clients look only at attachments; and Google’s own outbound mail sends both, so both is what client de-duplication expects.
Use a real mailbox as the sender
The practical consequence. An invitation sent from an address that is not a genuine mailbox loses its RSVP controls in Outlook, and no amount of configuration elsewhere recovers it.
Updates and cancellations
Each invitation carries a sequence number and a method. An update raises the sequence so calendars supersede the previous version rather than adding a second entry; a cancellation withdraws it from the recipient’s calendar rather than leaving a meeting nobody attends.
Send the cancellation. A meeting silently abandoned stays in everybody’s calendar.
The joining link is stored
Rather than regenerated. That is what keeps a reminder e-mail pointing at the same meeting as the original invitation — a link that changes between the invitation and the reminder is a meeting people cannot join.
Links are emitted in the forms Teams and Google Calendar each recognise, so the join button appears rather than a bare URL.
Replies are captured
Acceptances and declines arriving back at the monitored mailbox are picked up, so attendance is visible in the platform rather than only in somebody’s inbox.
Get the time zone right
An invitation carries one, and an hour’s error is the most noticeable failure this feature has. Check an invitation against your own calendar before sending any to customers.
Test in more than one client
Outlook and Gmail at minimum, and a phone. They differ in exactly the areas that decide whether somebody can accept.
Worked example
An appointment confirmation carries an invitation mapped from the booking, sent from a genuine monitored mailbox. Changes raise the sequence so calendars update in place, cancellations are sent rather than implied, and the joining link is the same one in the reminder. Testing in Outlook, Gmail and on a phone found the RSVP controls missing until the sender was changed to a real mailbox.
Recommendations
- Send from a real, monitored mailbox or RSVP will not work.
- Always send cancellations rather than abandoning a meeting.
- Check the time zone against your own calendar first.
- Test in Outlook, Gmail and on a phone.