New standard object: Events

[Bredo]

At its core, a CRM is meant to track the lifecycle of a customer relationship. Twenty should implement a standardised object to handle this. It's effectively a condensed Customer Data Platform within the CRM, and it would be worth it to consider implementing ClickHouse for large customers' analytics (potentially only for Enterprise subscribers) down the line.

How is this different than the Timeline?
Today, the timeline focuses on edits to the record. The timeline could appropriately change name to "History" or similar, so make it distinct for Events.

Inspiration

• HubSpot App Events
• Pipedrive Custom Activities
• Twilio Segment

Core implementation

• Support of Event Types, that can be configured in the UI and created by apps.
• An Event Type has a category, which guides how the UI should render these.
  • Apps should be allowed to build custom UIs.
  • Categories could also just be templates of UIs instead of having hardcoded basic options - decision to be made here.
• Events must be groupable by Context (see examples below).
• When an Event Type has been created by an app, allowing the app to render a default action as well as ancillary actions would make it very powerful (as front components with associated logic functions).
• And event type should ideally have a payload schema associated, to make it typed.
  • Typing it, whilst giving great control and DX benefits, will mean that updating the schema should be handled well for old records.

Should work with...

• Workflows
• Relations linked post-ingress of events (to avoid stalling events) - potentially just have that as workflow actions?

Examples

Example 1: LinkedIn DM sync

• Event Type:
  • Name: LinkedIn DM conversation
  • Type: CONVERSATION (standard)
  • Default action: [Reply to conversation]
• Events
  • Event # 1 payload {context: 'li:dm:4324', senderId: '23423', receiverId: '4090', timestamp: 1000000, message: 'Hi, how are you?', direction: 'incoming'}
  • Event # 2 payload {context: 'li:dm:4324', senderId: '4090', receiverId: '23423', timestamp: 1000005, message: 'I\'m good, and you?', direction: 'outgoing'}
  • ...
• Renders as chat interface with bubbles based on direction, and "reply with new message" as a front components in the bottom.

Example 2: Website visitor

• Event Type
  • Name: Website Visitor Session
  • Type: GENERIC_TIMELINE (standard)
  • (no action)
• Events
  • (event payloads follows standard CDP design, popularised by Segment and used by Mixpanel etc)
• Renders as events in a simple timeline

Example 3: Billing

• Event Type
  • Name: Invoice
  • Type: ?
  • (no action?)
• Events
  • Invoice created
  • Payment request sent to Stripe
  • Payment authorisation succeeded
  • Payment settled
  • Payment chargebacked
• Renders as events in a simple timeline

UI rendering

Small "timeline bubble"-widget for aggregates on a per-person/per-company level

Bubbles grouped by Event Context, size should be based of number of events (potentially with a configurable "bubble size per-event" on the Event Type?)

Final considerations

Could this be achieved today with custom objects? Probably. However, it would be very helpful having it as a primitive, to make it easier to extend and build on top of.
It could also be considered to, instead of having "event context" having "events" and "sub-events", to maintain a persistent state of a given parent event (e.g. billing invoice status).

[martmull]

@FelixMalfait @charlesBochet wdyt?

[FelixMalfait]

This is something I had in mind too (for me this would be the second tab in the data model, one for the OLTP data model, one for the event types/ OLAP, and rebuild the timeline on top of that). This is a very big workstream that almost makes Clickhouse a mandatory dependency so for me it was for end of 2026 at best :(

[marcnajera]

We're actually using a custom object named "Custom Events" to work around this limitation.

We're tracking just a few events per person, so it's manageable, and it allows us to really understand and capture relevant data (like DMs and activities that the CRM doesn't track automatically).

In fact, we're including emails and calls because querying one object is way easier than mixing activities and this object.

But the UX is terrible on the app itself. It's not possible to see all the events related to a person in a way they're easy to understand, and creating/updating them is cumbersome since they're an independent object rather than being linked directly to a person/company.

Either allowing us to create and manage custom timeline events or adding events as proposed here would help a lot.

[Bredo]

I'm also curious if ClickHouse really is the right solution here @FelixMalfait - if drill-downs on a per-account level is what is the desired outcome, it's going to be limited what performance boosts ClickHouse brings...

[FelixMalfait]

Clickhouse will be amazing but it requires a lot of work.
Clickhouse gives you infinite storage / throughput so you can store billions of events (pageViews etc), but yes you still need an aggregation layer on top (e.g. materialize pageviews as timeline activity grouped by hour etc). Currently we already have some ugly harcoded assumptions for timeline activities (e.g. listens to notes.updated but does not create a new timeline activity if it's within 15min). The goal will be to refactor all this (large scale event processing, aggregation engine, timeline activities) into a well defined and configurable abstraction