Patterns
Configure identities and signatures
Keep company/product/inbox structure and outgoing identity understandable before connecting real persistence.
On this page
User goal
Keep company/product/inbox structure and outgoing identity understandable before connecting real persistence.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Choose Companies, Products, Inboxes or Signatures from Settings sections. |
| 2 | Open a named editor from the list. |
| 3 | Review parent company/product and public From identity. |
| 4 | For inboxes, choose purpose, default signature, teammate access and active state. |
| 5 | Save the prototype draft and verify the current persistence boundary. |
Decision and composition rules
- Public email identity is separate from internal private routing.
- Product purpose is not authorization.
- Signature ownership and usage scope are independent fields.
Edge cases and recovery
- Save callbacks return no structured entity payload.
- Source lists remain static arrays after local toast.
- View domain is currently an inert affordance.
- Production needs validation, mutation payloads, pending/error feedback and reload reconciliation.
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/settings-view.tsx | Settings lists |
| components/views/settings-editors.tsx | Editors |
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