Allow Apps to Extend the Message Threads Timeline

[MB-Jan]

Allow Apps to Extend the Message Threads Timeline

I started exploring how to integrate additional communication channels (such as LINE Messenger) into Twenty CRM and noticed that doing so currently requires modifying Twenty's core, which I'd prefer to avoid.

Instead, I think it would be beneficial if the existing Email functionality could become an extension point that apps can hook into.

The Idea

Rather than limiting the timeline to email conversations, allow apps to register additional communication providers that contribute to the existing Message Threads object.

Examples could include:

• Email
• WhatsApp
• LINE
• Facebook Messenger
• Telegram
• SMS
• Microsoft Teams
• Slack
• ...or any future communication channel built by the community.

From a user's perspective, it might even make sense to rename the Email tab to something more generic, such as Communications or Messages.

Each conversation could simply display its source with a small badge or icon while still appearing inside one unified timeline.

---

Why This Matters

One of Twenty CRM's biggest strengths is providing a complete history of interactions with a Person, Company or Opportunity.

Today, conversations are increasingly spread across multiple communication platforms. As a result, the history becomes fragmented.

Instead, every communication could appear in a single chronological timeline regardless of where it originated.

John Smith

──────────────────────────────

📧 Email
"Proposal attached."

💚 LINE
"Can we move tomorrow's meeting?"

💬 WhatsApp
"Received, thank you!"

📧 Email
"Invoice has been sent."

──────────────────────────────

This provides users with a true 360° communication history without requiring separate custom objects or custom timeline implementations.

---

My Current Workaround

To achieve this today, I have:

• Created a custom object for LINE Messenger conversations.
• Hidden the default Email tab.
• Built my own combined communication timeline that merges Email and LINE conversations.

It works surprisingly well, but ideally all of this information should come directly from the existing Message Threads object instead of duplicating functionality.

---

Benefits

• ✅ One communication timeline for every relationship
• ✅ No duplicated timeline implementations
• ✅ Keeps Twenty's core clean
• ✅ Encourages community-built communication apps
• ✅ Makes future integrations much easier
• ✅ Gives users a complete interaction history regardless of channel

---

Possible Architecture

Instead of implementing support for every messaging platform in the core, Twenty could expose a simple interface for communication providers.

Something along the lines of:

interface CommunicationProvider {
    channel: string;
    syncConversations(): Promise<void>;
    sendMessage?(...);
    receiveWebhook?(...);
    mapToMessageThread(...);
}

Apps could then register themselves as communication providers and contribute conversations to the existing Message Threads timeline.

This keeps Twenty focused while allowing the community to build integrations independently.

---

Related Discussions

This idea naturally extends some previous feature requests:

• Whatsapp Business sync #7296
• WhatsApp integration #20983
• Opening up accounts/channels #20244

---

Why I Think This Fits Twenty Well

One of Twenty CRM's goals is to be highly extensible through apps.

Communication channels are evolving rapidly, and it wouldn't make sense for the core team to build and maintain integrations for every platform.

Instead, providing a generic communication extension point would allow the ecosystem to grow organically while keeping Twenty's core focused and maintainable.

The result would be a CRM where users can see every conversation with a contact in one place, regardless of whether it happened via email, WhatsApp, LINE, Messenger or any future platform.

I think this would become a powerful foundation for the app ecosystem and make Twenty feel much more like a true communication hub rather than an email-centric CRM.

[MB-Jan]

Update after building the workaround end to end (on 2.21.0, self-hosted):

We shipped the merged timeline as an app: a custom object stores LINE message bodies, a front component fetches both messageParticipants (with the nested message) and our custom objects, merges them by timestamp, and tags each row with its channel. For thread detail we deep-link into the native viewer with openSidePanelPage({ page: ViewRecord, objectNameSingular: 'messageThread' }), which nicely inherits the native reply flow. So a workaround exists and works.

But it is second class in ways only a native extension point can fix. The app polls instead of receiving updates. The channel tag exists only at read time in our component, so nothing else in Twenty (timeline activities, last-contact fields, search) knows the conversations exist. And the native path is closed for good reasons to document here: TimelineThreadDTO carries no channel field, MessageChannelType is limited to EMAIL, SMS and EMAIL_GROUP with channel creation gated to user context only, and the sync reconciler in messaging-message-list-fetch.service.ts hard-deletes any foreign rows written into message or messageThread on the next full sync. That last one is a silent data-loss trap for anyone who tries the obvious hack, which I think is the clearest sign this needs to be a supported surface.

The SDK already exposes ViewRecord on message threads and a ComposeEmail side panel page to app front components, so apps can read and link into native messaging today. A registration path for additional channels feels like the natural completion of that surface.

[martmull]

I think this is a great idea. Thanks for sharing it! We're gradually moving toward introducing a Communication entity in the product, so your point is definitely relevant. @FelixMalfait @Bonapara, what do you think?

[FelixMalfait]

Yes it's part of the roadmap! The vision is pretty clear for me, but still some work to get there 😅

[MB-Jan]

Perfect! Please let me know if there is anything I can do to contribute. Looking forward to this!