Patterns
Add teammate context without losing the customer
Keep internal collaborators distinct from the customer and assignment responsibility.
On this page
User goal
Keep internal collaborators distinct from the customer and assignment responsibility.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Inspect the participant avatar stack and open an identity popover if needed. |
| 2 | Use Add people to thread to choose available active teammates. |
| 3 | Confirm selected teammates; local participantIds update. |
| 4 | Review the composer’s seeded copy recipients after remount. |
| 5 | Use Remove people from thread for explicitly added participants. |
Decision and composition rules
- Assignee and existing message senders are fixed context in add options.
- Removal only lists explicitly added participant IDs.
- No recipient should silently become an account member.
Edge cases and recovery
- No available teammate gets an explicit empty state.
- Selected rows need programmatic selection semantics.
- Server infrastructure uses internal_cc/internal_bcc and excludes internal recipients from external provider recipient delivery.
- Frontend samples do not prove internal delivery behavior.
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/thread-participants.tsx | Participant selection |
| components/inbox/composer.tsx | Copy recipient seed |
| helpdesk-notes/Infrastructure Architecture.md | Internal/external boundary |
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