Member fields: assign people to records

A member field holds a person — not typed text, but someone picked from the database's member list. The demo shop's Orders table assigns each order to whoever is handling it: Laila, Omar or Salma. Because the value is a real member, the cell shows their name and avatar, and everyone spells the same person the same way.

Make one

1. Add a field and choose Member.
2. Allow multiple — off is one person per cell (an owner, an assignee); on is several (everyone reviewing this contract).

Choose once: single versus multiple is fixed after creation. To change it, delete the field and add a new one.

Picking a person

Click the cell and a picker opens over it, like a select's: the database's members with avatars, names and emails, a search box, and a clear option. The record panel has the same picker behind the field. Typing while the cell is selected opens the picker with your keystrokes already in the search.

The list is the database's members — owners, editors and viewers alike. People outside the database can't be picked; invite them first, or model them as records in their own table with a link.

What is actually stored

The cell stores the member's email — their account key. Names and avatars come from each person's profile at display time, so when Salma sets a display name or a new photo, every cell that holds her updates without any record changing.

That storage choice shows up over the API: a member field reads and writes as the plain email string, a multi-member field as a list of them.

"Assigned to": "laila@sakkaraplants.com"

Write a member's email to assign them. The screen's picker only offers real members; the API accepts any string and stores it as written, so an integration should write emails exactly as they appear in the member list.

Filtering, grouping, and the board

A member field filters as text against the stored email: Assigned to is laila@sakkaraplants.com, or is empty for unassigned work. Note that it's the email being compared — contains laila matches, contains Laila Hassan doesn't, because the display name isn't in the cell. A single member field sorts; a multi-member field, like any multi-value field, doesn't.

Both shapes group a grid, and the section headings show people by name rather than by address. A multi-member cell files its record under everyone in it at once — "Laila Hassan, Omar Farid" is one group, not two.

A single member field also stacks a board: one column per person, drag a card to reassign it. A multi-member field doesn't, because dropping a card on a column that already holds two other people has no single answer.

A saved view filtered to one person is the closest thing to a "my tasks" screen today — there is no me token in filters yet.

When someone is removed from the database

Removing a member never touches records. Every cell that held them keeps the stored email; with no member profile left to dress it, the cell shows the bare address instead of a name and avatar. Re-add the same person later and the cells read as before — nothing was lost in between, and their access rights return with them.

This is deliberate. "Who handled this order in March" is history, and revoking someone's access shouldn't rewrite it.

When you actually want a different field

• People who don't sign in to this database — customers, suppliers — belong in their own table, connected by a link, where they can carry phone numbers, notes and order history.
• A snapshot of who did something, taken automatically, isn't this field either — a member field is set by hand. Records do carry a creator internally, but the assignment story is the member field.