Per-email threads visibility toggle (shared / private)

[petrbaloun]

Per-email visibility toggle (shared / private)

Problem

Currently, email visibility in Twenty is configured at the account (message channel) level —
users choose one of three options globally:

• Metadata only
• Subject + Metadata
• All Email Content

This creates a real-world privacy problem: a connected mailbox contains both business-relevant
emails (client conversations, deals, proposals) and personal or sensitive emails
(service registrations, password resets, bank notifications, 2FA codes, SaaS onboarding emails, etc.).

With the current global setting, users must choose between:

• Sharing everything with the team (including sensitive content), or
• Sharing nothing (losing the collaborative value of email sync entirely)

There is no middle ground.

Proposed Solution

Add a per-email (per-thread) visibility toggle that allows users to explicitly mark individual
email threads as shared with the workspace — defaulting to private.

Default behavior: All synced emails are private to the user who owns the connected account.
Action required: The user explicitly marks a thread as shared to make it visible to teammates.

This gives users full control over what enters the shared CRM context, without requiring a
separate mailbox or restrictive global settings.

Why This Makes Sense Technically

The infrastructure for this already partially exists in the codebase:

• EmailThreadNotShared component exists in
  /packages/twenty-front/src/modules/activities/emails/components/
• isShared prop is already passed to EmailThreadPreview
• Issue Use email visibility to display only the shared information (frontend) #3804 already addressed displaying visibility state in the UI

The missing piece is moving the visibility decision from the account level to the
thread level — adding a sharedWithWorkspace: boolean field on the message thread
record, and exposing a toggle in the email thread UI.

User Story

As a sales rep, I want to connect my work mailbox to Twenty so that client conversations
appear on contact records — but I want service emails, password resets, and registration
confirmations to stay private to me, without having to maintain a separate mailbox.

Suggested UX

• Email threads default to private (not shared)
• A visible "Share with team" toggle or button appears on each thread
• Once shared, the thread becomes visible on the relevant contact/company record for all
  workspace members (respecting the existing visibility level — metadata, subject, or full content)
• A "Not shared" label (already implemented via EmailThreadNotShared) is shown on
  private threads so the user knows the thread is only visible to them

Impact

• Removes the blocker for users who hesitate to connect their primary mailbox due to privacy concerns
• Makes email sync genuinely useful for mixed-use mailboxes
• Aligns with how users naturally think about CRM data: I decide what is a business
  conversation, not an algorithm
• Low implementation risk — builds directly on existing UI components and visibility logic

Related

• Use email visibility to display only the shared information (frontend) #3804 — Email visibility display in frontend
• Fix: "Not shared" label not visible due to extra long email subject #11492 — Fix: "Not shared" label not visible due to long subject

[benweissbehavehealth]

@petrbaloun This is a really good call-out here.

Very very very important issue, most CRMs don't do a great job of this, TwentyCRM has the foundation to do this best in class, but not as its currently built, as you called out really clearly here.

@FelixMalfait I don't know the scope of work to support this change, but feels like a small amount of effort to enable a huge amount of value.

One of the biggest reasons TwentyCRM is special is because its open-source and self-hosted, unlocking regulated industries use cases.

The current way email works in Twenty makes it nearly impossible to deploy in a regulated industry, it risks exposing sensitive emails, or locking down emails globally in the account so they produce no value.

[petrbaloun]

Thanks :-)
I came across this when I started thinking about using emails in practice.
Another easy extension could be, after deploying attachment synchronization, whether email attachments are also shared with the team, or just the email body.
What I'm looking forward to overall is working with email attachments, which many companies are solving so that attachments are not locked in an individual's email. CRMs often have this. They solve transferability. This also unlocks the possibility of working with both emails and their attachments in a team with agents. And thanks to this, agents can create, for example, offers for opportunities and control the entire sales process.
The more the world becomes agent-based, the more there will be a need for a center for every company that can handle it.

[FelixMalfait]

It's a fairly complex task unfortunately.
We have a robust permission system that handles object-level + field-level + row-level. Messaging and Calendar event have been built outside of this framework, I think the first step would be to try to merge this into it, which may imply some product compromise. Then the next step would be to define individual "tuple based" sharing for records, so create exceptions to the rule where for a given record we can create a tuple (recordId + userId / key) to override base settings. Again this would need to be designed as a general concept, not for message/calendar events only.
So realistically this is probably not something we will do before ~Q4 because the cost/ratio isn't the best compared to other product opportunities today. I fully agree that it should be solved/done though!

[petrbaloun]

What is the best current practice, how was this thought about? Does each user have a dedicated folder in their email that they share with CRM?
Because the email address designated for loading into CRM cannot work if users of the same tenant forward to it, which is omitted by default in loading into CRM.

[FelixMalfait]

Yes for teams that don't want to share everything I feel like creating a Label in gmail and only syncing that specific label is the best option. You can create rules to add that label automatically

[benweissbehavehealth]

I am debating the best way to handle emails now. I would hate to not use the built in functionality.

I see there being three groups of users

• Leadership and executives - very sensitive emails, and a few customer/sales/support related emails
• Management - lots of customer/sales/support related, and some very sensitive emails that should not be synced
• Front-line Sales/Support/Customer-facing roles, mostly emails to be synced, maybe the occasional sensitive email

@FelixMalfait I think leveraging the row-level permissions system already built-into the enterprise version is the most direct and obvious path to making email a first class standard object and leveraging that existing system to handle all the access controls.

I think I understand how this will solve it: "Then the next step would be to define individual "tuple based" sharing for records, so create exceptions to the rule where for a given record we can create a tuple (recordId + userId / key) to override base settings." which sounds like it would be a global override on top of existing row level permissions.

I would say that whatever compromises would need to be taken to get emails and events into a granularly controlled and permissions construct would be worth it, because email can have any sensitive item sent inbound with ZERO controls because you cannot control who sends you an email. This makes it the number one source of potential information breaching/leakage.....

Making a real TwentyCRM Standard Object for entities we know exist across all types of organizations is a logical step for TwentyCRM, I do appreciate how thoughtful you likely are around adding Standard Objects because of how permanent these are. There are some objects that every organization on planet earth has:

• emails
• events
• calls (sometimes related to an event but not always)
• meetings (often related to an event but not always)

there are some objects that some organizations have but maybe not all:

• sms messages
• other message services (whatsapp, discord, linkedin, etc.)

[AlexyBouvet]

Adding a migration use case to this discussion. We are migrating an existing CRM to Twenty Cloud, including the business email history already stored in the source CRM. We want that history to remain readable by the team in the native Emails tab, with its original senders, recipients, dates and links to contacts.

In a small API import test, we created a MessageThread, a Message with its original body, the participants and the link to the contact. The source text and relationships were verified after import. The thread appears on the contact, but shows "Not shared" because it has no MessageChannelMessageAssociation. A mailbox is already connected in the target workspace; the missing step is how to give the imported historical records the intended visibility.

One practical example is an email sent by one teammate that also exists in another teammate's mailbox. The migration needs to preserve the original sender, consolidate the source copies into one message and make the selected business history readable by the team. It also needs to reconcile that message with ongoing mailbox sync so that the same email is not created again later.

A sharing setting on the message or thread would let us explicitly mark the selected historical records as shared during import, while keeping unrelated mailbox content subject to its existing privacy settings. Converting these emails into notes would lose the native email experience we are trying to preserve.

Is there a supported API migration pattern for this today? If channel associations are required, what is the recommended way to map existing historical messages to them, preserve the intended sharing and avoid duplicates when the source CRM export does not contain Gmail or Outlook message IDs? And could explicit sharing of imported threads be covered by the permissions work discussed here?

[FelixMalfait]

@neo773 will be releasing "group emails" this week, I think it could be a good use-case for it ; you'd still have to created a mailbox but it will make more sense because it's a workspace-level mailbox so it can be legacy@mycompany.com and then you use that to push all messages.

Also we (@martmull !) are doing a very big refactoring on the way permissions work, which will impact Emails/Calendar, it should solve a lot of issues we have today with permissions

[FelixMalfait]

The work @martmull is doing is enabling record-level sharing (I share this email thread X to user A)