Collaboration
2.0 retires the thread-backed collaboration model. Tasks, suggestions, announcements, and system activity each move out ofthread_entity into purpose-built entities with their own tables, APIs and
permissions. Human conversations stay on /v1/feed.
Tasks become a first-class entity
Breaking. Affects API clients, bots, and workflow integrations reading/v1/feed/tasks/*.
Tasks are now backed by task_entity, with full CRUD and versioning at /v1/tasks (22 new
endpoints: list/create/upsert, resolve/close lifecycle transitions, scoped lists like /assigned and
/dataAccessRequests, bulk operations, version history). Required fields are id, name,
category, type, status, createdBy, and typed payload schemas ship per task type
(glossaryApprovalPayload, dataAccessRequestPayload, and nine others).
/v1/feed still exposes GET /v1/feed/tasks/{id}, PUT /v1/feed/tasks/{id}/resolve and
PUT /v1/feed/tasks/{id}/close, but creating a task thread through POST /v1/feed now validates
the task type and rejects anything outside the supported legacy set (description, tag, approval,
test-case-failure-resolution), plus enforces that about is non-blank and taskDetails is present
only on task threads.
Five new policy operations gate this: CreateTask, EditTask, ResolveTask, CloseTask and
ReassignTask (behavioural — affects non-admin users and application bots). The migration
backfills them onto the seed DataConsumerPolicy and ApplicationBotPolicy, but custom policies
that replaced those seeds are not backfilled — non-admins get 403 creating or editing tasks until
you add the operations yourself. Task authorization is also self-approval guarded: a task’s creator
cannot approve their own task, even where policy would otherwise allow it.
Suggestions become Tasks
Breaking. Affects AI and automation bots, and SDK users calling/v1/suggestions.
The entire /v1/suggestions namespace is removed:
The suggestion field path also moves from an entity link to
payload.fieldPath in dot notation
(columns.col_name.description). Existing suggestions are migrated into task_entity automatically.
Announcements become a standalone entity
Breaking. Affects anything reading or writing announcements through the feed API./v1/feed now rejects announcements outright — list, get, patch, create, delete, posts, and reactions
on an announcement thread all return 400 with Announcements are no longer served from /v1/feed. Use /v1/announcements instead. Announcements are full entities in 2.0 (versioned, soft-deletable,
restorable) at /v1/announcements, and the UI renders them in the entity header rather than only in
the feed widget.
System activity moves to a retention-bounded Activity Stream
Breaking, with a data-loss note. Affects anything treating the feed as an audit trail. System-generated activity (field changes, entity created/updated) no longer lives inthread_entity.
It moves to a time-partitioned activity_stream table at /v1/activity/**, and events older than
30 days are deleted automatically by default (activityStreamConfig.retentionDays, configurable
globally or per domain).
thread_entity itself is renamed to thread_entity_legacy post-migration (behavioural — affects
anyone querying the database directly); the feed repository resolves the legacy table dynamically so
migrated threads stay readable, but BI dashboards, or retention jobs querying thread_entity directly
need updating.
Alert filters are scoped and matched literally
Behavioural. Affects existing alert subscriptions. In 1.13, the entity-FQN filter returnedtrue unconditionally for thread change events — thread
activity bypassed the filter entirely. In 2.0 a thread event is matched against the fully qualified
name of the entity the thread is about. An alert scoped to service.db.schema that previously
fired for every conversation and task in the system now fires only for threads about entities under
that name; alerts that looked noisy will go quiet, and alerts you relied on for global thread
coverage will stop firing.
Filter functions also now match fully qualified names literally, not as regular expressions. An
alert whose filter used ., * or | to match a family of names no longer matches — enumerate the
names or rely on descendant matching instead.
A few smaller additive pieces round out the redesign
/v1/taskFormSchemas stores per-task-type form definitions, referenced from a Task via
taskFormSchemaId and taskFormSchemaVersion — this is what lets governance workflows render
custom task forms. changeEventType adds taskCreated, taskUpdated,
entityLineageAdded/Deleted/Updated for webhook and event-subscription consumers, and
changeEvent gains a recursive flag marking cascade deletes — a single event is recorded for the
deleted root, so consumers that previously counted per-child delete events must read recursive
instead. Both the feed list and task list APIs also accept startTs/endTs for server-side
time-range filtering, replacing client-side windowing.