Skip to content

Why Slack, Teams and Notion Needed Different Models

· 1 min read · 0 views

Integration ArchitectureLLM EngineeringSystem DesignSoftware Engineering

Slack, Microsoft Teams and Notion can all produce work items for TimeSense, but they should not be modeled identically.

Slack and Teams contain noisy message streams. An LLM has to determine whether a message contains an action item, and the result remains pending until the user confirms it.

Notion databases are different. A row is already a structured task with fields such as title and due date. Running the same detection pipeline over it would add cost and reduce clarity.

So I used two boundaries:

Message sources for conversational streams.
Task sources for structured work systems.

I also resisted prematurely combining every Slack and Teams table into one generic schema. Two similar implementations are not always enough evidence for the right abstraction.

The tradeoff is some parallel code.

The benefit is that each integration honestly represents the source it connects to.

Good abstraction removes accidental complexity. Bad abstraction hides meaningful differences.

Why Slack, Teams and Notion need different models: Slack and Teams are message or conversation sources that require action-item detection, while Notion is a structured task source with direct task import. Different sources, different shapes, different handling.

Originally posted on LinkedIn.