Team members

The Members section of a workspace's settings page. Each person gets one row with their avatar, name, email, when they were last active, their role and a way to remove them. Above the list are the seat count and Invite people, which opens a dialog where you can paste a whole list of addresses. Pending invites sit under the list, where they can be resent or revoked. Role changes show at once and roll back with an inline error if the server says no. The section won't remove or demote the last owner. People who can't manage the team see the same list without the controls, along with a line saying why.

It's a block: a whole section built from Avatar, Badge, Button, Select, SearchField, ChipGroup, Dialog, ConfirmDialog, Alert, EmptyState and Tooltip. It takes data and promise-returning callbacks and never fetches anything itself.

import { TeamMembers } from "@/components/ui/team-members/team-members";<TeamMembers  workspaceName={workspace.name}  members={members}  invites={invites}  currentUserId={session.userId}  seats={{ used: members.length + invites.length, total: plan.seats }}  canManage={me.role === "owner" || me.role === "admin"}  loading={status === "loading"}  error={status === "error" ? "We couldn’t reach the server. Your team is fine." : null}  onRetry={refetch}  onInvite={async (emails, role) => {    const created = await api.invites.create({ emails, role });    setInvites((list) => [...created, ...list]);  }}  onChangeRole={async (id, role) => {    const updated = await api.members.update(id, { role });    setMembers((list) => list.map((m) => (m.id === id ? updated : m)));  }}  onRemove={async (id) => {    await api.members.remove(id);    if (id === session.userId) return router.push("/workspaces");    setMembers((list) => list.filter((m) => m.id !== id));  }}  onResend={async (id) => {    const invite = await api.invites.resend(id);    setInvites((list) => list.map((i) => (i.id === id ? invite : i)));  }}  onRevoke={async (id) => {    await api.invites.revoke(id);    setInvites((list) => list.filter((i) => i.id !== id));  }}  onUpgrade={() => router.push("/settings/billing")}/>

Callbacks that reject with an Error show its message where the action happened. A message that says what to do next is better than a code: "Acme couldn’t remove them just now. They still have access; try again."

When to use it

• The people page of a workspace, team, organization or project: anywhere there are roles, invites and a seat count.
• A shared account where some people can manage the team and others can only look.

When not to

• Sharing a single document or page with people. Use a share dialog with an access list; this section manages the whole workspace.
• Directories with hundreds of people, SCIM or groups. Use a Data Table with server-side search and pagination. This section shows every member in one list and only filters on the client.
• Sign-up or accepting an invite. That's the invitee's screen, not this one.

States

The invite dialog.

Props

The section never changes your data. It shows optimistic roles while a change is saving, but members and invites must be updated by you.

Customizing

• Roles. Pass your own roles, most powerful first. Someone can change rows and hand out roles at their own rank or lower, which is how an admin can't touch owners. If your rules are different, such as admins promoting to owner, merge those roles or check on the server and reject with a message.
• Copy. The description defaults to supper-planning words from the demo, so pass description with a line about your product. The confirm text says what removal does in Acme; check that it's true for yours ("Suppers and notes they made stay").
• Seats. If pending invites don't use a seat in your billing, don't count them in used. Then change the "Pending invites count as seats" line in invite-dialog.tsx.
• Invite expiry. The dialog says invites last 7 days. Edit that sentence, and set expiresAt to match.
• Columns. The row puts everything on one line once the section is 600px wide, measured on the section with a container query. Below that, the role and last active move under the name. Your own row's Leave is a word, not an icon, so on a phone it takes its own line under your role and last active, and your name and "You" keep the whole top line. --team-role and --team-active set the column widths.
• Edges. The toolbar's search field and role filter are full-size fields, and the list's card takes the same outline (--ui-edge, the field edge color), so the controls and the box under them read as one set. Rows are split by the lighter divider (--ui-border); the role selects inside rows are quiet sm pills with no edge. Keep that if you restyle: one outline color for the boxes, one lighter color for the lines inside them.
• Sorting. Rows show in the order you pass. Owners first, then by name, reads best.

Layout

The title sits --ui-gap-block above the list and the invites a full --ui-gap-section below it; rows are padded --ui-pad-card at the sides (16 narrow, 24 from 560px), so every edge moves together.

An email address too long for a phone row breaks after its @, so the name and the domain each stay whole where they fit.

Accessibility

• The section is a <section> named by its heading. Each list is named by its heading.
• Avatars are decorative, because the name is written beside them. "You" is real text in the row.
• Each role select is named "Role for Maya Lindqvist". Disabled options keep their reason as their description, so it's read with them.
• Icon buttons are named "Remove Theo Marchetti" and "Revoke invite to felix@…". A tooltip shows the same words on hover.
• Leave, when blocked, uses aria-disabled and stays focusable. It's described by the note under the list that explains why.
• A role-change, resend or revoke failure uses role="alert" in its row, with Try again next to it. Successes are announced once through a polite status region: "Maya Lindqvist is now an admin.", "Olu Bankole removed.", "2 invites sent as members."
• Confirm dialogs start on Cancel. After a removal, focus moves to the next person's role or button, not the page.
• The invite field is a real labelled input, described by the line under it, which lists the problems. Each red chip's accessible name includes its problem ("chef@acme, isn’t a full address"). Chip removal is announced and focus moves to a neighbour.
• Search and the role filter update the "3 of 14" count, which is a polite live region.
• Rows open and close by height. Under reduced motion they only fade.

Before / after

Before: a table with a role dropdown that saves silently, a delete button that just deletes, and an invite field that takes one address at a time.

{members.map((m) => (  <tr key={m.id}>    <td>{m.name}</td>    <td>      <select value={m.role} onChange={(e) => api.setRole(m.id, e.target.value)}>        <option>owner</option><option>admin</option><option>member</option>      </select>    </td>    <td><button onClick={() => api.remove(m.id)}>Delete</button></td>  </tr>))}<input placeholder="Email" /><button>Invite</button>

After: you can't remove the last owner, a failed change says so and puts the old role back, removal asks first and names the person, a pasted list of 20 addresses is checked before sending, and seats are counted before the server has to refuse.

<TeamMembers  workspaceName="Hearth & Hare"  members={members}  invites={invites}  currentUserId={me.id}  seats={{ used: members.length + invites.length, total: 20 }}  canManage={me.role !== "viewer" && me.role !== "member"}  onInvite={invite}  onChangeRole={changeRole}  onRemove={remove}  onResend={resend}  onRevoke={revoke}  onUpgrade={openBilling}/>