Your team
Nodrik has no per-seat price on any tier. Inviting your whole team costs exactly the same as using it alone, because what Nodrik actually spends money on is investigations, and an investigation costs what it costs whether one person reads the card or nine do. So the reason to think about who is in your workspace is not the bill — it is who can change the plan.
Everything on this page lives on the console’s Team page.
Inviting a colleague
Section titled “Inviting a colleague”Team ▸ Invite a colleague, an address and a role, and an email goes out. Only an admin can send one.
The email carries a link, and it is the link that admits somebody —
not the address it was sent to. That is worth being direct about, because
it has a consequence: forward the email and whoever opens it joins your
workspace. Nodrik does not gate acceptance on the address matching,
deliberately. No sign-in provider promises us that an address it reports
has been verified, so refusing on a mismatched address would be enforcing
a rule with an unverifiable claim — which is the shape most account
takeovers have. What the console does instead is show the mismatch:
somebody signed in as ada@personal.example opening an invitation sent to
ada@corp.example is told so, in those words, before they join. And every
acceptance is recorded, with the identity that accepted it, in the
history.
The bounds worth knowing:
- An invitation lasts seven days, then stops working. That survives a weekend, a bank holiday and somebody being on leave when it lands; much longer and a link sitting in a mail archive is a standing key to your workspace.
- It works once. Accepting spends it. A refused attempt does not — a forwarded link that somebody else fails to use cannot lock out the colleague it was meant for.
- Twenty invitations can be outstanding at a time, and ten can be sent in an hour. Neither is a seat limit; they bound how much mail one workspace can send. Accepting or withdrawing frees a slot at once.
- We never store the link. What is kept is a one-way hash of it, so a copy of our database is not a set of working invitations.
Pending invitations are listed under the form with the role each was sent as and how long it has left, and Withdraw stops one immediately. To change the role on an invitation somebody has not accepted yet, withdraw it and send another — the role is fixed at the moment it is sent, so that a forwarded invitation cannot quietly become a different one.
The three roles
Section titled “The three roles”| Role | Can do |
|---|---|
| Admin | Everything, including money: the plan, add-ons, the Stripe portal, who else is here, and leaving |
| Member | Everything except money: projects, access, Slack, GitHub, test alerts, acting on a card |
| Read-only | Sees investigations, configuration, usage and the history. Changes nothing at all |
The roles nest exactly: a member can do everything a read-only user can, and an admin everything a member can. There is nothing an admin cannot do that somebody else can.
Three rather than two, because “member” without a wall around the billing means everybody you invite can cancel your subscription. Three rather than four, because nobody has asked for a fourth — and a role nobody needs is a row in a table that has to be right for ever.
Whoever signed the workspace up is an admin. Everybody else is whatever their invitation said.
The line falls at your project limit
Section titled “The line falls at your project limit”The one place the member/admin boundary is not obvious is projects, so it is worth stating: adding a project inside your plan’s limit is an ordinary change — any member can do it, nothing is quoted and nothing is bought. Adding one beyond the limit is a purchase, and a purchase is billing, so it needs an admin.
A member who reaches the limit is told the limit and told that an admin can raise it. They are never shown a checkout they cannot complete.
Removing a project is always an ordinary change, even when it lowers a quantity you are paying for — it can only ever spend less. The prices are on Plans and billing.
Your own tools need an admin
Section titled “Your own tools need an admin”Connecting your own read-only tools is an admin action, and it is the one thing on the configuration side of the product that is. Slack and GitHub are consent screens on apps we registered, where the boundary is what you approve on somebody else’s page. A tool source is different in kind: it stores a credential you issued, and it adds an outbound call from Nodrik to an address somebody typed, whose answers land in an investigation transcript. That is closer in consequence to billing than to choosing where Nodrik posts.
Changing a role, and removing somebody
Section titled “Changing a role, and removing somebody”Both are on the same page, both are admin-only, and both take effect immediately — there is no invitation to re-send and nothing to accept.
A workspace always has at least one admin. The last one can be neither removed nor demoted, including by themselves, and the console says so rather than offering a button that fails. A workspace with no admin cannot change its own plan, invite anybody or close itself, and getting it back needs us — so an admin who is leaving promotes somebody first.
If that did not happen — the only admin has left the company and nobody else can pay the bill — email us. Restoring an admin is something we can do for a person already in the workspace; it is deliberately not something that can add somebody new, because that would be a way into a workspace that does not go through an admin.
What an invitee sees
Section titled “What an invitee sees”Following the link asks them to sign in with Google or GitHub, exactly as signing up does, and then shows them the workspace they are joining and the role they are joining as. Two things can stop them, and both say so plainly:
- The link has expired or been used. Expired, already accepted and withdrawn all read the same way — “ask for another” — because distinguishing them would tell whoever holds a spent link something about your workspace, and would not help the person who actually needs a new one.
- They are already in another workspace. An account belongs to exactly one Nodrik workspace. They can sign in with a different account, or leave the one they are in, but the invitation cannot move them. Nothing is spent by the failed attempt, so the same link still works afterwards.
An invitation to somebody who is already in your workspace is refused rather than applied. That is on purpose: if accepting could change a role, then an admin-roled invitation forwarded to a read-only colleague would be a promotion no admin ever performed.
The history
Section titled “The history”Every change anybody makes in your workspace is recorded, and the record is on Team ▸ History: who did it, which sign-in identity they used, the role they held at the time, what changed, and when.
Invitations sent, withdrawn and accepted; people removed and roles changed; projects added, removed and bought; access granted; Slack and GitHub connected; tool sources added, tested and removed; test alerts; card actions; mutes ended; plan and add-on changes — and the changes Nodrik makes to your subscription by itself, attributed to Nodrik rather than to a person. That last one is the reason the log is worth having at all: a charge nobody pressed a button for is exactly the entry a disputed invoice needs, and a history containing only human actions has its gap in precisely the wrong place.
Everybody can read it, not only admins. A history only the powerful can see invites the suspicion it exists to answer.
It names what changed, never the material. A plan change records the two tiers, not the card. There are no request bodies in it, no tokens and no secrets.
Two things are deliberately absent, and their absence is not an oversight:
- Revoking Nodrik’s access to a project. That happens in your own Google Cloud project, under your own authority, and Nodrik never observes the moment — it simply goes blind. An entry nothing can write would be a gap dressed up as coverage. Your own Cloud Audit Logs have it; Verify access has the query.
- Disconnecting Slack. There is no disconnect action to record, because moving the channel means reconnecting through Slack’s own consent screen.
The log is kept for 396 days — a billing year plus the period before it, because the change behind a charge somebody is querying usually happened in the period before the one they are looking at. It is deleted with your workspace when you leave, including the entry that records the leaving. Retention and what it never contains are also on Security and trust.
Where billing email goes
Section titled “Where billing email goes”To every admin, worked out at the moment each one is sent. Members and read-only users are left off deliberately — they cannot pay, and mail to somebody who cannot act on it is how a team learns to ignore the channel. The detail is on Plans and billing.