Patterns
Maintain people and product relationships
Keep person details lightweight while recording customer/prospect context per product.
On this page
User goal
Keep person details lightweight while recording customer/prospect context per product.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Open People and inspect the row summary. |
| 2 | Open the full profile for relationships and conversation history. |
| 3 | Add or edit a person using visible name/email/organization/owner fields. |
| 4 | Enable relevant product relationships, then choose Customer or Prospect. |
| 5 | For prospects, optionally set stage and follow-up; save to local people state. |
Decision and composition rules
- A person can have different kinds across products.
- Contact owner is not conversation assignment.
- One-off composer recipients need not become saved contacts.
Edge cases and recovery
- Name/email presence does not establish valid or unique addresses.
- Only one additional email is preserved by the editor.
- Static helpers can show stale contact information after local edits.
- No live Kit update is performed.
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/views/people-view.tsx | List/create |
| components/views/person-profile-view.tsx | Profile |
| components/views/person-editor-dialog.tsx | Record editor |
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