Skip to main content
A Collect represents a single data-collection run initiated by an authenticated user, typically driven by the browser extension (popup, side panel, or blueprint automation). Each run is bound to one People (the subject being enriched), one Workspace (stamped at creation from req.workspace and never re-derived), and optionally one Task (the automation trigger). The status lifecycle progresses from todo through in_progress to finalized or error. Workspace binding is nullable on legacy rows to handle orphaned people records; all workspace-scoped queries silently exclude those rows via Hasura RLS.
Internal object. Not currently exposed on the public REST API. The operations below describe the intended contract.

API operations

Data model

Attributes

Relationships

System-computed

  • collect_id β€” generated server-side via gen_random_uuid() defaultRaw; never accepted from client input
  • created_at β€” set once on insert via MikroORM onCreate hook (new Date())
  • updated_at β€” refreshed on every update via onUpdate hook (new Date())
  • deleted_at β€” soft-delete; set to current timestamp by CollectService.deleteCollect; null on active rows
  • workspace (workspace_pk) β€” stamped at creation time from req.workspace by CollectService.createCollect and never subsequently overwritten, even on PATCH calls; this immutability is the tenant-safety guarantee for in-flight runs
  • status default β€” CollectStatusEnum.TODO at row creation unless overridden by the POST body
  • idx_collects_status β€” partial index on status WHERE deleted_at IS NULL
  • idx_collects_people β€” partial index on people_pk WHERE deleted_at IS NULL
  • idx_collects_workspace_status β€” composite index on (workspace_pk, status) for active-run queries

Example

Source: /Users/maximechampoux/platform/apps/api/src/database/entities/Collect.ts Β· domain: ingestion Β· tier: Infrastructure