Enable the Emails / Calendar reader on custom objects (the read path already looks generic)

[tolandmike]

What I'm trying to do

We run a construction business on Twenty. Our real unit of work is a Project (a custom object) that a deal converts into. We'd love the Emails tab — the actual inline thread reader — to appear on a Project record the way it does on People, Companies, and Opportunities, so the correspondence for a job is readable on the job.

Today custom objects don't get the Emails/Calendar tabs. From reading the code, that looks deliberate rather than missing (see #19544, "Skip email/calendar tab creation for custom object record page layouts"), and I completely understand why it was scoped out. But the surprising thing is how close the rest of the stack already is to supporting it, so I wanted to raise it as an idea and offer to help.

What I found in the code (main)

The read path is almost entirely object-agnostic already:

• Frontend reader is generic. EmailsCard (packages/twenty-front/.../activities/emails/components/EmailsCard.tsx) resolves the current record via useTargetRecord() and asks the backend for that record's threads — no per-object special-casing.
• Tab visibility isn't an allow-list. getTabsRenderableForTargetObject.ts deliberately exempts Emails/Calendar from the "must have a relation field" rule (per the comment in WidgetTypesRequiringRelationField.ts).
• The backend query is generic. timeline-messaging.service.ts filters threads with innerJoin('messageThread.messageThreadTargets', …).where('messageThreadTargets.<fieldName> = :recordId') — it takes whatever target field it's handed.
• The generic target-junction read path already shipped behind IS_MESSAGE_CALENDAR_TARGET_READ_ENABLED (Read Calendar and Email timelines from target junctions #24782).

The one hard gate is a single ~15-line util, get-target-field-name-for-object-record.util.ts:

switch (objectNameSingular) {
  case Person:      return 'targetPersonId';
  case Company:     return 'targetCompanyId';
  case Opportunity: return 'targetOpportunityId';
  default:          return null;   // every custom object stops here
}

null makes MessageCalendarTargetReadinessService treat the object as "not ready," so the reader shows nothing. Alongside it, MessageThreadTargetWorkspaceEntity / CalendarEventTargetWorkspaceEntity hardcode the three target* relations.

Proposed direction (open to your preference)

1. Generalize target-field resolution instead of the three-way switch: for a given object, resolve the target<Object>Id column that the thread/calendar target relation actually exposes, and return it for any object that has one. Widen the TargetFieldName type accordingly.
2. Let the thread/calendar target junctions point at custom objects — either by making the target relation extensible, or (what already works via the metadata API today) letting a workspace add a target<CustomObject> relation on the junction and having the resolver honor it.
3. Allow the Emails/Calendar widget on custom-object page layouts (reverse the skip from Skip email/calendar tab creation for custom object record page layouts #19544, or make it opt-in per object in the layout editor).

The part you deliberately deferred: population

I suspect the reason custom objects were skipped is that there's no generic way to populate the links — email auto-matching is intentionally people/companies-by-address, and opportunities are populated out of band. That's fair. From a user's side, two population paths already cover us and don't need core changes:

• Manual "Relate" — a person filing a thread onto a Project.
• An automation — we already run one that links threads to the right Opportunity by point-of-contact; the same pattern populates a custom object's junction.

So this request is really about the read/display side working once the links exist; the auto-match behavior can stay exactly as it is.

Why it matters

For anyone modeling their real workflow with custom objects (projects, matters, cases, deals-after-close), the email history is the point — and right now it dead-ends on the object people actually live in. Given the target-junction read path is already generic, this feels like a small, high-leverage addition rather than a rewrite.

Happy to open a PR along the lines above if the team is open to the direction — wanted to check appetite and preferred approach first.

(Code references verified against github.com/twentyhq/twenty main, Sept 2026.)

[BOHEUS]

Duplicate of twentyhq/core-team-issues#51