Patterns
Assign responsibility and classify work
Make conversation ownership explicit while preserving independent support/sales/general meaning.
On this page
User goal
Make conversation ownership explicit while preserving independent support/sales/general meaning.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Inspect the thread’s product/inbox and existing participants. |
| 2 | Choose an active teammate in Assign conversation, or leave Unassigned. |
| 3 | Choose Support, Sales or General as work type. |
| 4 | For Sales, set a meaningful stage separately from the queue state. |
| 5 | Review the row’s ownership context and relevant filter result. |
Decision and composition rules
- Assignee is not the same as contact owner or copied teammate.
- Work classification does not grant access.
- A queue state expresses next attention, not sales pipeline position.
Edge cases and recovery
- Invited teammates are excluded from assignment options.
- Changing filters may remove a newly assigned conversation from view.
- Authorization checks are pending in the tenant-facing server boundary.
Persistence boundary
The demonstrated frontend uses local React state or static fixtures. Read the readiness topic before connecting these actions to authenticated persistence. A visible toast, badge or timer is not a server acknowledgement.
Source references
| File | Responsibility |
|---|---|
| components/inbox/conversation-detail.tsx | Toolbar |
| lib/types.ts | Independent metadata fields |
Examples from the app
Actual Sonarist components with fictional conversations, people, example.com addresses and simulated operational states. Captured at 2× resolution or higher. Select an image to inspect it full size.
Related topics
Source audit: 2026-10-08 · Revision 10f45d1377b5 · Documentation v1.0.0