Where should a CRM reminder live? Proposal: two-way calendar sync so follow-ups land in the user's own calendar

[Moritz-Staat]

Context

We run self-hosted Twenty (main) with the Microsoft messaging and calendar providers configured. A team member surfaced a gap that I think is worth discussing openly, because I'm not sure whether the right fix is a feature, a design choice, or a bit of both.

The user story is small and extremely common:

"Call customer X in two weeks and talk about the offer — remind me."

Today in Twenty that becomes a Task with a due date. That's where it stops: Twenty does not actively remind you. There's no time-based in-app notification, no email digest for upcoming/overdue tasks, and no way to have that follow-up appear in the calendar or to-do app the user already lives in (Outlook, Google, mobile calendar, etc.).

So the workflow effectively relies on the user remembering to open Twenty. For teams using Twenty as their daily driver, that's a real blocker — and it's the same reason a lot of us have an active wish for "proper Outlook sync".

Important privacy note up front: this kind of follow-up is a personal reminder for the CRM user, not a meeting with the customer. Even though the Task or reminder is linked to a Person record, the related contact must not be added as an attendee, must not receive an invitation email, and must not see the event. The customer should have no idea that a cold-call reminder for them sits in the salesperson's calendar. Anything else would be a hard blocker for real-world use.

What's already in the product — which is a lot

Credit where it's due: Twenty is closer to solving this than it first appears.

The CalendarEvent and CalendarChannel entities exist. The Microsoft Calendar provider is implemented and gate-able via CALENDAR_PROVIDER_MICROSOFT_ENABLED. Google Calendar is even further along. There's a first-class Calendar view type that can visualise any object with a date field — Tasks-with-due-date included. Workflows, Webhooks, OAuth, and an auto-generated REST/GraphQL API are all there. For the read direction, external events already land as records linked to People/Companies/Opportunities.

The deliberate gap is the write path: calendar events are intentionally read-only in the UI (#9638), because they're owned by the external provider. Nothing connects a Task (or any CRM-originated reminder) to a provider event it could emit.

Why I think reframing helps

The temptation when asking for "reminders" is to ask for a new native notification layer inside Twenty — a bell, a digest email, a mobile push. I'd argue this is the wrong direction for an open-source CRM competing on focus: users already own a calendar and a reminder system, and they're opinionated about which one. A CRM that re-implements that will always be the second-best version of the one they already use.

So the framing that seems to scale better is:

Twenty is the source of CRM follow-ups. The surface where they show up — Outlook, Google Calendar, Apple, a CalDAV server, Slack, whatever — is chosen per-user.

Under that framing, one feature pays several debts at once:

1. CRM reminders write back to the user's connected calendar → every reminder inherits that calendar's push/email/mobile UX "for free."
2. Two-way sync → when the user reschedules or cancels the reminder in Outlook, the CRM record updates.
3. Stronger meeting workflows later (e.g. "prep notes on this meeting" attached both ways).

Prior art / adjacent threads

I want to be explicit this isn't a blind duplicate — here's what's adjacent and why none of it fully covers the ask:

• #8583 feat: Outlook sync — closest Issue; framed as "capture meetings as interactions", i.e. provider → CRM. Doesn't really discuss the write-back direction or the reminder framing.
• #16735 Native integrations — the integrations roadmap (Q3/Q4 2026 window). Under Calendar it lists Apple / cal.com / Zoho / Proton; a Microsoft write path isn't explicitly on the list, probably because Microsoft is already there as read.
• #11701 mail & calendar integration via third-party services — Proton/CalDAV oriented, closed.
• #8777 Calendar and emails — CalDAV/Nextcloud angle, closed.
• #12389 Support Apple as E-Mail and Calendar Provider — Apple provider.

Possible approaches, ascending in commitment

Across all stages, the privacy contract from the context section holds: the provider event is a personal reminder, created with no attendees beyond the CRM user themselves, sendUpdates=none (or the Graph equivalent: no invitation, isReminderOn=true, potentially sensitivity=private). The linked CRM contact is never added to the event by default. That's non-negotiable for the feature to be useful.

Stage 1 — a Workflow action Create/Update/Delete Calendar Event on user's connected provider.
This is the smallest useful unit. Reuses the existing OAuth tokens and Microsoft/Google Graph clients. A workspace admin can then wire up "Task created with due date → event in that user's Outlook" without touching the frontend. It doesn't require changing the readonly semantics of CalendarEvent or designing any new UI. The action defaults to attendee-less, no-notification events so the privacy contract can't be violated by accident.

Stage 2 — a model-level Task ↔ CalendarEvent lifecycle link.
Optionally a Task (or any record with a due date, configurable) owns a mirrored provider event. Edits and deletes propagate. Still uses existing clients. No two-way sync yet — the provider event is CRM-originated, so conflicts are minimal. This is where the feature becomes visible to end users without workflow plumbing. Because the semantics (private, attendee-less, CRM-originated) differ from externally-synced CalendarEvents, this is also where a distinct subtype might be warranted — see question 3 below.

Stage 3 — full two-way sync with provider push subscriptions.
Graph / Google webhook subscriptions instead of polling, conflict resolution, and manual event creation from the Calendar view enabled (possibly behind a feature flag during stabilisation). This is the "real" Outlook sync that #8583 implies.

Questions I'd love input on

1. Does the product direction agree with the framing — "user's own calendar is the reminder surface," rather than building a native due-date notification system inside Twenty?
2. Is the #16735 Q3/Q4 2026 integrations window a plausible home for Stage 1 or Stage 2? Is a Microsoft write path on the radar, or consciously deferred?
3. Data model — does a mirrored CRM event belong on the existing CalendarEvent (currently readonly, externally-owned, may have attendees) or as a distinct subtype, so the read/write contract and the "no attendees, no invites" privacy rule are both encoded in the type rather than enforced by convention?
4. Multi-user: MS Graph writes are per-mailbox. Assumption is each user's own OAuth is used (not a service principal / delegated app). Does that match the existing provider design?
5. For teams not on Outlook — would the community prefer Stage 1 to ship as a generic provider-agnostic workflow action with per-provider adapters (MS / Google / CalDAV), or is single-provider first acceptable?

Happy to help

A bit of context on where we're coming from: we use Twenty in production at our company, and while I'm not personally writing the code, we can realistically allocate developer time from our team if there's a design path the maintainers are open to. So this isn't a drive-by feature request — it's an offer to help move Stage 1 or Stage 2 forward in coordination with the core team.

What would help us commit most usefully: a rough signal on direction (is this on the right track, or is there a reason the write path is intentionally out-of-scope?), and a sense of where the CalendarEvent readonly contract is load-bearing enough that a subtype is the better path. With that, we can scope something concrete.

Feedback, counter-proposals and "you're looking at this wrong because…" are very welcome. Thanks for reading, and for the work on the existing Microsoft integration — the fact that this is close to feasible is a compliment to what's already shipped.