Appearance
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}/assignmentfor 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_idor equivalent lead-coach ownership when a relationship can have multiple coach-side members. - Add
default_scopetocoach_priority_view_preferencesfor team and personal default views. - Add
scopeandassignedToquery filters toGET /api/v1/workspaces/{workspaceId}/coach-priority. - Allow assigned relationships, unassigned team priority items, and all-workspace scopes only after access policy is explicit.
- Use
CoachClientRelationshipReassignedor 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.
CoachWorkspacecan later support assistants, staff membership, team permissions, billing, and settings.WorkspaceMembershipcan 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_tasksor 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?