Skip to content

Post-V1 / Workspace Collaboration

Assistant coaches, staff assignment, and team queues are intentionally outside Public V1.

This page preserves the collaboration concepts removed from V1 baseline implementation docs. The V1 baseline should keep coach workflows single-owner and avoid building assignment, team triage, assistant permission, or team queue behavior until the product needs it.

Page status

  • Post-V1
  • Assistant roles
  • Task assignment
  • Team queues

Preserved Scope

These are future ideas, not current V1 baseline requirements.

Future Capabilities

  • Assistant coaches and staff roles inside a coach workspace.
  • A lead or primary coach concept for each coach-client relationship when more than one workspace member can support a client.
  • Task assignment, reassignment, unassignment, and assignee history.
  • Unassigned team queues for work that should be claimed or routed later.
  • Assigned-to-me, all-visible-client, all-workspace, and team-scope filters.
  • Team-level priority actions, pins, suppressions, and shared triage workflows.

What Stays Out Of V1 baseline

  • No assistant coach onboarding or workspace invitations.
  • No team queue, team assignment, or staff handoff API.
  • No assignment columns or assignee filters on coach web or mobile screens.
  • No assistant/staff permission matrix in active feature docs.
  • No team-level daily review, team-level pinning, or cross-coach priority queue.

Task Inbox Extensions

The removed task inbox material centered on assignment records, team queues, and assistant handling rules.

Domain Model

  • CoachTaskAssignment: assignee record for assistant coaches, staff handoff, or unassigned team queue.
  • CoachTaskAssigned: event to notify an assignee when team queues are enabled.
  • Assignment changes, dismissals, and handoffs should be audit logged with actor id.
  • Only one active assignment should exist per task.
  • Assignment should be allowed only when the assignee can view the client and source type.

UI And API

  • Add assignee and team filters to GET /api/v1/workspaces/{workspaceId}/coach-tasks.
  • Add assigned-to-me counts to GET /api/v1/workspaces/{workspaceId}/coach-tasks/summary.
  • Add PATCH /api/v1/workspaces/{workspaceId}/coach-tasks/{taskId}/assignment for assign and unassign actions.
  • Coach web can show assignee columns and multi-select assignment actions.
  • Coach mobile can group tasks by assigned-to-me when team workflows exist.

Deferred assignment table

apps/api/src/coach-workflow/db/coach-tasks.schema.ts

ts
export const coachTaskAssignments = pgTable("coach_task_assignments", {
  id: uuid("id").primaryKey().defaultRandom(),
  taskId: uuid("task_id").notNull().references(() => coachTasks.id),
  assignedToUserId: uuid("assigned_to_user_id").notNull(),
  assignedByUserId: uuid("assigned_by_user_id").notNull(),
  status: text("status").$type<"ACTIVE" | "ENDED">().notNull().default("ACTIVE"),
  assignedAt: timestamp("assigned_at", { withTimezone: true }).notNull().defaultNow(),
  unassignedAt: timestamp("unassigned_at", { withTimezone: true }),
}, (table) => ({
  oneActiveAssignment: uniqueIndex("coach_task_assignments_active_uq")
    .on(table.taskId)
    .where(sql`${table.status} = 'ACTIVE'`),
  assigneeStatusIdx: index("coach_task_assignments_assignee_status_idx")
    .on(table.assignedToUserId, table.status),
}));

Priority View Extensions

The removed Priority view material described team handoff and team-scoped triage.

Team Handoff

  • Workspace owners or lead coaches can view all visible priority items for the workspace.
  • Assistant coaches see only relationships and source categories their role permits.
  • Task reassignment can update the priority item assignee summary and move work between team and personal queues.
  • Team filters should not change the underlying score; they only change which relationships are visible in the list.
  • Daily snapshots should preserve the order a coach or team lead saw at the start of the day.

Data And API

  • Add primary_coach_user_id or equivalent lead-coach ownership when a relationship can have multiple coach-side members.
  • Add default_scope to coach_priority_view_preferences for team and personal default views.
  • Add scope and assignedTo query filters to GET /api/v1/workspaces/{workspaceId}/coach-priority.
  • Allow assigned relationships, unassigned team priority items, and all-workspace scopes only after access policy is explicit.
  • Use CoachClientRelationshipReassigned or a similar event when handoff workflows exist.

Access Rules

Assistant and staff access must be permission-scoped, source-aware, and auditable.

General Rules

  • Assistant and staff roles do not inherit owner-level access from workspace membership alone.
  • Client profile, private notes, health, nutrition, media, messages, and risk details each need explicit permissions.
  • Assistants can see redacted priority reason summaries when allowed to triage but not allowed to open the source detail.
  • Manual pins and suppressions are actor-specific unless a lead coach applies a team-level action.
  • All handling, dismissal, manual creation, and assignment actions are audit logged with actor id.

Feature-Specific Rules

  • Profile: assistants or staff need scoped permissions and should not inherit owner-level access automatically.
  • Progress: assistants or staff need explicit progress permissions and should not inherit body photo access from generic client read access.
  • Risk flags: assistants can see flags only when role grants client visibility and risk flag permissions.
  • Risk actions: administrative outreach can be delegated, but nutrition, health, or program interventions need source-specific permissions.
  • Risk operations: assistants cannot change rule sets unless granted workspace operations permissions.

Workspace Model

CoachWorkspace remains in the V1 baseline, but assistant/team behavior belongs here for later planning.

  • CoachWorkspace can later support assistants, staff membership, team permissions, billing, and settings.
  • WorkspaceMembership can later grow beyond owner/coach roles into assistant, staff, lead coach, operations, or support roles.
  • Future workspace invitations should define role, permission grants, expiration, revocation, and audit history.
  • Future client visibility should distinguish workspace membership from relationship-level access.

Open Decisions

Resolve these before reintroducing assistant or team behavior.

Product Decisions

  • Should the first post-V1 role be assistant coach, admin staff, lead coach, or operations user?
  • Which task types can assistants resolve, and which must stay with the coach?
  • Should clients see assistant names, only the coach brand, or both?
  • Should team queues be available on mobile from day one of the team feature?

Technical Decisions

  • Should task ownership remain on coach_tasks or move fully into assignment history?
  • How should relationship visibility be represented when several workspace members can support one client?
  • How should team-level pins and suppressions interact with personal pins and suppressions?
  • What retention policy applies to assignment and handoff events?

CoachMe internal planning documentation.