Members and invitations
A workspace is only as good as the people in it. Here’s how to let the right ones in, give them the right amount of power, and show the rest the door without losing their work.
Before you start
Section titled “Before you start”- Everything here lives under Settings › Members. The Workspace settings link at the bottom of the sidebar gets you there.
- Inviting, changing roles and removing people needs an Admin or the Owner. Members see the people list and their own Leave workspace action, nothing more. They don’t see invitation email addresses.
- Every human counts against the workspace owner’s plan. Free seats one human per workspace, so on Free there’s no room for a second person until the owner upgrades. When the workspace is full, the invite form says so before you type, and a Free owner can upgrade right there. Solo Pro seats three; Team has no cap, and each human is a seat on the owner’s bill. Agents don’t take seats. See Plans and billing.
- Membership, invitations and ownership are browser-only. No agent key can invite, remove, promote or transfer, however nicely it asks.
Invite someone
Section titled “Invite someone”- Under Invitations, type their Email and pick a Role: Member or Admin.
- Press Review invitation, read what that role can do, then press Send invitation.
- The invitation shows Pending · Expires with a date, plus its email delivery status.
The email comes from Hydrant Bots, bots@hydrant.dev. The person accepts by signing in as the address you typed: with a code sent to it, or with the GitHub account that has it as its verified primary email. Secondary GitHub addresses don’t count. No GitHub account? Fine. The code is enough. People who already use Hydrant can also accept from All workspaces, where pending invitations appear with Accept invitation and Decline.
Nothing happens until they accept. Opening the email, previewing the invitation or signing in grants no access.
- An invitation lasts 7 days.
- Resend sends a fresh link with a new 7 days. The old link stops working.
- Revoke ends the invitation for good. You can invite them again later.
- To change the offered role, revoke it and send a new one.
Change someone’s role
Section titled “Change someone’s role”Next to a person, pick the other role in their Role picker, read the review, then press Confirm role change. The picker only opens the review; nothing changes until you confirm.
- Admins can make or unmake other Admins. Nobody can change the Owner’s role or their own.
- Demoting an Admin to Member revokes the invitations they sent that are still pending. Their workspace access and assignments stay.
- Agent keys follow their person’s current role on the next request, in both directions.
Give someone a lane
Section titled “Give someone a lane”A lane says what a person is for, in a sentence or two: “Human design work” or “Impossible decisions”. It shows under their name here and in every assignee picker, and connected agents read it before picking an assignee.
Press the pencil on your own row (Edit your lane), or on anyone’s if you’re an Admin or the Owner. Write the Lane, optionally turn on Leave out of suggestions (still assignable by hand, just never volunteered, and marked Benched), then press Save changes. Named agents have lanes too; see Named agents.
Remove someone
Section titled “Remove someone”- Press Remove… next to them.
- The review lists their unfinished assignments: anything not Done, Canceled or in Trash, snoozed and iced work included.
- Optionally move work first: pick someone under Move work to, then press Reassign # on each issue. Each reassignment saves separately.
- Press Remove and retain to finish. Anything you didn’t move stays assigned to them.
What removal does, immediately:
- They lose access to the workspace.
- Every agent key and connection they created in it is revoked, permanently. Rejoining later doesn’t bring them back.
- Their pending invitations are revoked, and any ownership offer involving them is canceled.
- Their comments, edits and history keep their name. Their assignee identity stays, marked inactive, so nobody can assign them new work.
If a former member still holds unfinished work, Departed members’ work appears for Admins and the Owner. Press Review assignments to reassign it whenever you get round to it.
Leave a workspace
Section titled “Leave a workspace”At the bottom of Members, in the Danger zone, press Review leaving, check the work you’d leave behind, then press Leave and retain. Your access ends, your agent keys in that workspace are revoked, your unsaved drafts for that workspace are cleared, and you land on All workspaces. Your work keeps your name. Other workspaces and your sign-in are untouched.
The Owner can’t leave. Transfer ownership first. Someone has to hold the keys.
Transfer ownership
Section titled “Transfer ownership”A workspace has exactly one Owner. To hand it over:
- Under Transfer ownership in the Danger zone, pick a member under Choose a member and press Review transfer.
- Press Offer ownership. If your last sign-in is more than 10 minutes old, Hydrant asks you to sign in again first (with GitHub or an email code, whichever your account has) and brings you back to the same review.
- The recipient opens Members and sees the offer at the top of the page. They press Review ownership offer, then Accept ownership, with the same 10-minute sign-in rule. Or Decline offer.
The offer lasts seven days and grants nothing while it waits. You can Cancel offer until they accept. When they accept, you become a Member, and your agent keys lose their administrative permissions.
This moves authority inside Hydrant only. GitHub repositories, domains, subscriptions and company ownership stay exactly where they were. The workspace’s limits follow the new owner’s plan from then on; acceptance is never refused over plan limits, but new additions wait if the new plan is smaller, and a workspace over that plan’s humans limit follows When a paid plan ends.
When a paid plan ends
Section titled “When a paid plan ends”When the Owner’s Team or Solo Pro ends (canceled, unpaid, switched to a smaller plan, a trial that ran out or a grant that was revoked), nothing changes for 30 days. New people still wait for room, as they always do. After the 30 days, in a workspace with more humans than the new plan seats, the people past the limit are on read and comment:
- They can still read and search everything, comment, edit their own comments, react, resolve threads, follow issues, mark Sign-off as looked at, manage their notifications, request an export if they’re an Admin, revoke their own agent keys and connections, accept an ownership offer, leave, and change their own account settings.
- They can’t create or edit issues, change fields, or touch the library, catalog or settings. Their agents keep reading, but every agent write is refused, comments included, and they can’t connect a new agent here.
- Nothing is deleted. Nobody is removed, and every comment, issue and connection stays.
Who keeps a seat. The Owner always does. Under Settings › Members, the Full seats section shows the dates and, for the Owner, Who keeps a seat: pick up to one fewer than the plan’s seats, in order, and change it any time. On Free, which seats only the Owner, there’s nobody to pick: everyone else is on read and comment until the Owner picks a paid plan. Without picks, the earliest to join keep their seats and the most recently joined drop first; an Admin can drop like anyone else. Every member row says Full seat or Read and comment (during the 30 days, Keeps a full seat or Read and comment from the date), and everyone in the workspace sees those labels. Only the Owner sees and changes the picks.
Someone on read and comment sees a notice at the top of their workspace pages saying so, and whom to ask. They can hide it until their next session. Where they would connect an agent, Hydrant says what their agents can do instead.
Back to full. Paying again for a plan at least as big as the one that ended, or getting the workspace within the new plan’s limit, puts everyone back at once. A smaller paid plan keeps the 30-day clock and the restriction follows its own limit. Transferring ownership doesn’t reset anything. When the workspace is over the new Owner’s limit, they inherit the clock, or start a fresh 30 days if their plan is smaller. A carried clock covers the new Owner’s account, so it also applies to the other workspaces they own.
Who can do what
Section titled “Who can do what”Three roles. No custom permissions, no Viewer, no committee.
| Member | Admin | Owner | |
|---|---|---|---|
| Read everything in the workspace, including Insights, Roadmap and the Playbook | Yes | Yes | Yes |
| Create and edit issues, relationships, snoozes and images, comment and edit your own comments; trash and restore | Yes | Yes | Yes |
| Put issues into projects, milestones and cycles | Yes | Yes | Yes |
| Save personal views | Yes | Yes | Yes |
| Create and revoke their own agent keys and connections | Yes | Yes | Yes |
| See and revoke anyone’s agent keys and connections | Yes | Yes | |
| Edit your own lane and bench | Yes | Yes | Yes |
| Edit anyone’s lane, including named agents’; pick the default assignee | Yes | Yes | |
| Add a named agent | Yes | Yes | Yes |
| Rename, restyle or retire named agents; record who owns one | Yes | Yes | |
| Propose Playbook changes | Yes | Yes | Yes |
| Publish and review Playbook guides; edit agent prompts | Yes | Yes | |
| Grant agents Playbook permissions, protect guides, set workspace defaults | Yes | ||
| Labels and workspace saved views | When enabled | Yes | Yes |
| Turn on member access for labels and views | Yes | Yes | |
| Workflow stages and sizing | Yes | Yes | |
| Create and edit projects and milestones | Yes | Yes | |
| Cycle schedule, pausing and the planning calendar | Yes | Yes | |
| Workspace name, description and icon | Yes | Yes | |
| Invite people; change roles; remove members; reassign departed members’ work | Yes | Yes | |
| Read the workspace Usage page | Yes | Yes | Yes |
| Pay for the workspace’s plan | Yes, from their own account | ||
| Export the workspace | Yes | Yes | |
| Transfer ownership, delete the workspace | Yes | ||
| Leave the workspace | Yes | Yes | After transferring ownership |
Agents act with the current role of the person who connected them, and never more. Some jobs stay browser-only whoever connected the agent: membership, invitations, ownership, deletion, billing, the member-access switch and editing named agents’ names and faces. Lanes, benches and the default assignee are the exception: agents can set those, within their person’s role. In the Playbook, an agent also needs a permission the Owner grants under Settings › Playbook. A Member can also claim a named agent when Hydrant can verify they created it; see Named agents.
What you should see
Section titled “What you should see”- The People list with each person’s role and join date, and · you beside your own name.
- Pending invitations with their expiry and delivery status. Accepted, declined, revoked and expired ones stay listed as a record.
- After a change, a plain confirmation such as “Sam is now Admin.” or “Sam was removed. Their agent keys are revoked; retained assignments keep their attribution.”
If it goes sideways
Section titled “If it goes sideways”- “Free seats one human per workspace, and that chair is taken.” The owner’s plan is full. The owner upgrades from the notice above the invite form or under Settings › Billing, or someone leaves. This is the owner’s version, which also names the way up: Solo Pro seats three, and Team seats everyone at $12 a human a month.
- “… {owner} owns this workspace, so ask them about more room.” You’re an Admin, or you’re accepting an invitation, and the owner’s plan is full. It follows “that chair is taken” on Free and “every chair is taken” on Solo Pro and the trial. Only the owner can make room: they upgrade, or someone leaves. Admins never see what the owner pays.
- “Each new human on Team adds a seat to {owner}’s bill, so {owner} sends this one.” You’re an Admin on a Team workspace and this person would be a new seat. Ask the owner to send it, or invite someone already in another of their workspaces.
- “An invitation is already pending for this address. Review it before reissuing.” Use Resend on the existing one instead.
- The invitation email never arrived. Check the delivery line under the invitation. If it says bounced, blocked or failed, fix the address and send a new invitation. “Email delivered” still isn’t membership; only acceptance is.
- “Use the account whose verified email matches the invitation. Nothing has been accepted.” They signed in as a different address, or with a GitHub account whose primary email isn’t the invited one. They can sign in with a code sent to the invited address instead, or you can revoke it and invite the address they use.
- “This invitation has expired.” It meant that date. Send a new one.
- “Membership changed elsewhere. Review the current members before retrying.” Someone else changed the list first. Press Review latest members and decide again.
- “No victory lap yet. The result is unconfirmed.” The connection dropped mid-save. Press Retry same request. It can’t apply twice.
- You can’t find the Remove… button or the Role picker. You’re a Member, it’s your own row, or it’s the Owner’s row. None of those have one.