Data Collaboration

ODD Platform's Data Collaboration feature lets users start in-app discussion threads anchored to specific data entities, with replies tracked back from a Slack workspace via OAuth + the Slack Events A

ODD Platform's Data Collaboration feature lets users start in-app discussions about a specific data entity, with replies tracked back into the platform from a messenger. Conversations stay attached to the entity that anchored them, so an operator returning to a dataset months later can read the original threads — context, decisions, and follow-ups — without leaving the catalog.

The feature is exposed as a Discussions tab on every data entity's detail page (per-entity scope; not a global hub). At the moment Slack is the only supported messenger; integration with other providers would extend the same per-entity threading model.

The feature is disabled by default (datacollaboration.enabled=false). When disabled, every /api/datacollaboration/... route plus the /api/slack/events webhook return 404 Not Found — the controllers are gated by @ConditionalOnDataCollaboration.

The Discussions tab is visible even when Data Collaboration is disabled. The tab itself is currently rendered regardless of the flag (only hidden when the entity status is deleted). On a deployment that has not configured Data Collaboration the tab is visible but its content fails to load — operators who do not plan to enable the feature should be aware of this until the platform gates tab visibility on the flag.

How a discussion flows

• A user opens the Discussions tab on a data entity, picks a Slack channel from the bot's autocomplete, and posts a thread-root message. The platform writes the message to its own message store and queues it for delivery into Slack.

• A background sender (DataCollaborationMessageSenderJob) drains the queue. Each message is retried up to datacollaboration.sending-messages-retry-count times (default 3) before being marked failed.

• When a Slack user replies in the thread, Slack POSTs an event_callback to the platform's /api/slack/events webhook. The platform translates the reply into an in-platform message linked to the same data entity, and the new reply appears under the original thread on the Discussions tab.

• Per-entity history is queryable: thread-root messages and replies are paginated by entity ID. The platform retains its own copy of every message, so historical threads stay available even if the Slack channel rotates or the Slack workspace is migrated.

Slack — the full Slack app, not the alert webhook

The Slack integration that powers Data Collaboration is a full Slack app, distinct from the outgoing webhook the Notifications subsystem uses for alert messages. The data-collaboration app uses OAuth (datacollaboration.slack-oauth-token) and the Slack Events API to read replies back into the platform — bidirectional. The alerting Slack integration is a one-way incoming webhook that the platform POSTs alert messages to (notifications.receivers.slack.url) — no replies, no thread state.

An operator who has already set up the alert webhook still needs to set up the Slack app separately to enable Discussions; the two configurations are independent. See Main Concepts → Terms & Aliases for the canonical side-by-side comparison.

Where to set it up

• Operator setup — config keys, the Slack app manifest, advisory-lock IDs, message-partition rationale, retry behavior: Configure ODD Platform → Enable Data Collaboration.

• HTTP API — the seven /api/datacollaboration/... routes plus the inbound /api/slack/events webhook contract, channel autocomplete, per-entity message paging: API Reference → Data Collaboration.

Where to next

• For the Slack alert webhook (a different Slack integration on the same workspace) → Notifications → Slack incoming webhook.

• For the system-driven per-entity event stream the platform emits alongside user-authored discussion messages → Activity Feed.

• For the canonical side-by-side comparison of the two Slack integrations → Main Concepts → Terms & Aliases.