Org Implementation Checklist
Purpose
This file is now a status-based handoff for the shipped org client-work slice.
Use it to see:
- which org routes are already live
- which ones are still partial
- what the next implementation order should be
Global Reality
- every current org client-work route resolves the active org viewer first
- every current client-work query/mutation applies client scope through
clients/scope.ts - owners have global client visibility
- non-owners only see clients linked by active
clientAccessAssignments - billing is the only current client-work area fully tied into the broader org capability model
Route Status
org/(dashboard)/overview
Status: live.
What exists:
- real operations dashboard summary backed by the workspace summary surface
- organization and subscription summary
- portal and settings quick links
- scoped attention metrics across the current org workspace
What is missing:
- analytics drill-in for trends, finance reporting, and longer-horizon operational questions
org/(dashboard)/customers
Status: live.
What exists:
- visible client-account list
- create client-account flow
- inline client-account editing
- primary-contact portal provisioning anchored to the client account and canonical primary person when portal access is enabled
- owner-only staff assignment management per client account
- visible assigned-member summaries
Current access rules:
- any active org member can load the page
- owners see all client accounts in the org
- non-owners only see assigned client accounts
owner,admin, andaccount_managercan create and edit client accounts- only
ownercan manage client-access assignments
What is still missing:
- the multi-company portal access grant model that allows one portal identity to hold parallel company access inside one agency organization
- portal-side self-service people management
org/(dashboard)/customers/[clientId]
Status: live.
What exists:
- client account summary and profile editing
- tabbed information architecture across overview, people, projects, files, billing, and activity
- first-class create/edit workflows for client contacts
- person-level portal access state and role now surfaced directly in the
Peopletab - assigned staff visibility and assignment management
- contacts, projects, documents, customer billing, invoices, subscriptions, and recent activity in one workspace
What is still missing:
- the multi-company portal grant rollout that replaces the current one-company-per-portal-membership assumption
- portal-side self-service people workflow
- further polish where summary, relationship management, delivery, files, and finance workflows still need tightening
It is now the control center for:
- client account summary
clientContacts- assigned staff
- project snapshot
- time snapshot
- billing snapshot
- document snapshot
org/(dashboard)/projects
Status: live.
What exists:
- project list across visible client accounts
- create project flow
- visibility, status, summary, and target-date display
Current access rules:
- any active org member can load the page inside their client scope
owner,admin, andaccount_managercan create projects
What is still missing:
- remaining list polish and parity work where needed
org/(dashboard)/projects/[projectId]
Status: live.
What exists:
- project detail workspace
- surfaced
projectUpdates - draft versus published update workflow
What is still missing:
- only the next layer of workflow depth after the current org list and detail consistency pass
org/(dashboard)/time
Status: live.
What exists:
- timer and entries modes in one route
- recent time-entry list
- own time-entry creation
- optional project linking
- billable flag and approval state capture
- grouped dense entries review with detail drill-in
Current access rules:
- any active org member can load visible time entries inside their client scope
- any active org member can create their own draft time entries inside that scope
What is still missing:
- edit and correction workflow
org/(dashboard)/time/[timeEntryId]
Status: live.
What exists:
- read-only time-entry detail route
- metrics, metadata, and summary context for a single entry
What is still missing:
- only the next layer of edit and correction workflow if the product needs it
org/(dashboard)/billing
Status: live and capability-gated.
What exists:
- grouped invoice and subscription collections with Stripe connection health and attention state
- Stripe-backed invoice and subscription authoring from the org billing workspace
- inline customer creation/provisioning during invoice authoring
- invoice record list with detail drill-in
- subscription record list with detail drill-in
Current access rules:
- billing route access depends on the existing org billing capability set
- client scope still applies after billing access is granted
What is still missing:
- richer invoice line-item/detail visibility
- post-send invoice lifecycle depth such as revisions, credits, or refunds when those product phases land
- richer subscription timeline/history visibility
- billing reporting and analytics depth
What now exists in the backend foundation:
- agency Stripe connection setup, reconnect, and onboarding health via the client-billing Stripe connection surfaces
- Stripe webhook sync for agency connection state, invoices, and subscriptions
- hosted billing portal launchers tied to real Stripe customer mappings
Billing Profile Route Policy
Status: intentionally removed.
Current rule:
- there is no longer a dedicated user-facing billing-profile detail route
- internal billing mappings stay behind the client account plus invoice/subscription routes
org/(dashboard)/billing/invoices/[invoiceRecordId]
Status: live.
What exists:
- invoice detail route
- hosted invoice and PDF actions
What is still missing:
- richer finance workflow beyond visibility and outbound actions
org/(dashboard)/billing/subscriptions/[subscriptionRecordId]
Status: live.
What exists:
- subscription detail route
What is still missing:
- richer subscription operations beyond visibility
org/(dashboard)/documents
Status: live.
What exists:
- recent document list
- storage-backed upload flow
- client-visible versus internal visibility capture
- optional project linkage
Current access rules:
- any active org member can load visible documents inside their client scope
- any active org member can upload documents inside that scope
What is still missing:
- document detail workflows
- richer metadata edits
- file request flows
org/(dashboard)/analytics
Status: live.
The dedicated reporting surface now includes:
- delivery health, completion predictability, estimate variance, and retainer consumption
- tracked/billable trends plus permission-safe team utilization against per-day working schedules, dated targets, leave, and holidays
- currency-separated invoice, collection, recurring-revenue, receivables, unbilled-aging, and revenue-concentration reporting
- lifetime client and project gross profitability from invoiced revenue and confidential dated labor-cost inputs; margins are withheld until all delivery hours have a cost rate, and project margins additionally require complete project revenue attribution
- collaboration response, completion, backlog, and overdue signals
- record-level drill-ins and explicit unavailable/configuration states instead of misleading partial percentages
Analytics configuration lives under organization settings and has separate permissions for utilization viewing, confidential profitability viewing, and input management.
Current Slice Summary
Complete enough to call live:
customerscustomers/[clientId]projectsprojects/[projectId]timetime/[timeEntryId]billingbilling/invoices/[invoiceRecordId]billing/subscriptions/[subscriptionRecordId]documentsoverview
Partial or legacy:
- none of the current org client-work routes are still placeholder-only
Missing and still required to finish the phase:
analytics
Next Build Order
- list polish and interaction consistency across the rebuilt org collections
- row-level quick actions across the org collections
- tabbed IA where the detail pages have outgrown a single stacked layout
analyticsclientContactsmanagement insidecustomers/[clientId]- deeper billing and document operations on top of the current detail routes
- portal parity for published updates, shared documents, and billing snapshots
Acceptance Rule
Do not call the org client-work phase complete until:
- the existing schema-only tables (
clientContacts,projectUpdates) are surfaced in the app - the org workspace has a real analytics drill-in route for business and finance reporting
- the major org routes have consistent list and detail interaction patterns
- client-access scope remains consistent across those detail routes
- the portal starts consuming the same relationship data instead of remaining only an account/support shell