People and access

People & access (account menu → People & access, or ⌘K "people", "invite", "share") is the one screen for who can reach the books you run and what each of them can do there. It replaced the two places this used to live (Users & invites and Sharing), and both old links now open it. You need to be an owner or operator, on a book you act on; while you are looking at someone else's book read only the entry is not offered.

One list, a chip per book

Every person who has anything to do with a book you run is one row: name, email, a status chip (active, invited or disabled) and then one chip per book and role:

• a grey chip with a house glyph for their own book and the role their login carries there (Owner, Operator, Read only); that one travels with their login and is not yours to change;
• an orange chip for each book of yours they reach: Operator · ‹book› (they run it with you) or Read only · ‹book› (they can look and send feedback, never act). Orange means you can click it: a small menu offers Make operator / Make read only and Remove access.

So one person can hold several roles at once and the row shows all of them: Jim can be the Operator of Jim's book and Read only on yours, and that is two chips on one row, not two people in two dialogs. The house owner administers every login and therefore sees everyone and every chip; anyone else sees only the people of the books they run, and never learns who reaches a book they do not.

Search matches name, email or book; the status chips filter to active, invited or disabled with counts.

Add someone

One form at the top: an email and, optionally, a name. Bellwether decides what happens and says so in one sentence under the form before you press the button:

• They already sign in to Bellwether (the list knows them): you choose what they get on your book, Read only or Operator, and the button reads Give access. No invite, no second login; the access lands on their next request. An Operator role on your book is capped by their own login's role, so a read-only login never writes anywhere.
• They are new (house owner only): you choose where they land, and the button reads Send invite:
  • Their own book + read only on yours (the default): a completely separate book (own broker account, own agents, own settings) of which they are the Operator, and read-only access to your book, created together in one step. After setup they land on Connect your broker for their own keys and find your book in their switcher.
  • Their own book only: the same, without access to yours; add it later from this screen if you change your mind.
  • Your book · Operator or Your book · Read only: their login lives on your book with that role. You can name their book; left empty it becomes "‹Name›'s book".
• You are an operator, not the house owner, and the email is unknown: the answer says so (only the house owner invites new people) and nothing is created.

If you run more than one book (a second book of your own, or one you were made operator of), a Which of your books picker appears; the access is written and audited in that book.

Adding someone asks for your authenticator code (one from the last 30 minutes counts). The answer panel repeats what happened in a sentence and, for an invite, shows the one-time setup link with Copy and whether it was emailed or only recorded; the same link then stays under the person's row.

Pending people keep their setup link

An invited person's row carries the live setup link inline until they use it: the link itself, Copy, Resend (mints a fresh link, so the old one stops working, and emails it again), how long it has left, and Emailed to them or Not emailed, copy the link and send it yourself depending on whether a mail provider is configured. Because that link is what lets someone set the account's password and authenticator, it is only put on screen next to a recent authenticator code of yours: right after inviting (that code counts for 30 minutes) it is simply there; later the row says the link is kept and offers Show link, which asks for a code and then reveals it. When the link's own 30 minutes are up the row says Setup link expired with a one-click Send a new link. A row invited before links were kept here says so and offers the same button. Only the house owner ever holds a link; an operator sees that the person is invited and has not finished setup yet.

Changing and removing access, disabling a login

From a chip or the row's ⋯ menu:

• Make operator / Make read only on one of your books: asks for a code; the previous access row is closed and a new one opened, so the history stays in the audit log.
• Remove access to one of your books: a tightening, so no code; it takes effect on their next request and a live screen they have open on your book closes within about 30 seconds. Their own book and login are untouched.
• Open ‹their book› as read only: when you may look at their book (the house owner always may), jump straight into its read-only view.
• Send a new setup link, Disable login, Enable login: house owner only; each asks for a code from the last 5 minutes because a fresh link re-enrols that person's password and authenticator and a disable signs them out everywhere at once. Nothing is deleted by a disable.

Two things this screen deliberately will not do: change or remove the chip through which a book's owner reaches their own second book, and change your own access to a book (someone else does that). Changing the role a login carries on its own book (turning a read-only colleague on your book into an operator) is not here yet either; today that is a server-side change.

Every action on this screen writes an audit row in the affected book, visible under Activity with the config filter, and notes whether a code was presented.

Where the old screens went

Users & invites and Sharing · ‹book› are gone as separate places; their links (?users=1, ?sharing=1), the ⌘K entries "Users & invites" and "Share my book", and the Share read-only button on the track record all open People & access. The mail Outbox and API tokens stay their own owner-only entries in the account menu. What a read-only visitor actually sees, and how a role on a book you run is capped by your login, is unchanged and described in sharing and viewers.

Coming next

Groups (naming a set of people once, "family" or "desk", and giving the group a role on a book) are the next layer on top of this list; passkeys as a second sign-in method; and changing a login's own role from the console.