Patterns
Configure teammate access
Explain intended access inheritance while keeping role classification and billing seats separate.
On this page
User goal
Explain intended access inheritance while keeping role classification and billing seats separate.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Open Team and identify Active, Invited and Owner records. |
| 2 | Edit a non-owner teammate or open Add teammate. |
| 3 | Choose work classification independently of scope. |
| 4 | Grant a company, a product, or specific inboxes. |
| 5 | Read inherited descendants and their disabled state. |
| 6 | Save access or prepare an invitation locally. |
Decision and composition rules
- Company grant includes nested products/inboxes.
- Product grant includes nested inboxes.
- Owner always sees the workspace.
- Active and invited members count toward sample billing regardless of scope.
Edge cases and recovery
- Parent selection disables descendants without deleting their explicit local selections.
- Source save/invite only closes with toast.
- No authentication, permission enforcement, email invitation or durable membership change is verified.
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/team-view.tsx | Hierarchy and local draft |
| components/views/billing-settings.tsx | Seat counting |
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