Invite teammates and set access

How an invitation travels, what each role can do, and why a read-only account cannot publish.

Runi is worth roughly nothing at one seat and a great deal at three, so this step decides whether the trial tells you anything. Invite the colleague who works nearest your code first, not the whole company.

Send an invitation#

Open the invite dialog#

From the account menu at the bottom of the sidebar, or from Settings → Members. Owners and admins can invite; members and viewers cannot.
Enter addresses and choose a role#

The role is set on the invitation, so somebody joins as what you intended instead of as a default you then have to remember to change.
They accept, install, connect#

Your colleague creates their account from the invitation, installs the app, and connects their own agents. They do not need their own trial, because they are joining yours.

Note

An invited teammate does not get a workspace of their own. They join the one they were invited to. If they later want their own team, they start a trial on the website like anybody else.

The four roles#

Access is a ladder, not a set of flags: owner over admin over member over viewer.

Role	Can
Owner	Full control, including transferring ownership and deleting the workspace. Cannot be removed.
Admin	Manages members and viewers, invitations, workspace settings, repositories, retention, and can moderate a teammate's memory entry.
Member	Publishes sessions and edits tasks, shared work and notes. The normal role for an engineer.
Viewer	Reads everything, writes nothing, enforced by the database and not by hiding buttons.

Rank decides who may administer whom#

One rule, with the same answer everywhere it is asked: administering someone requires being strictly above them. An admin cannot remove another admin, and nobody outranks themselves.

A viewer's machine cannot publish#

This is the consequence people meet first, and it is easy to read as a broken install. A viewer's daemon is refused when it tries to write, and says so:

output

 FAIL  publish   last attempt failed: access-denied — this account is
                read-only in the workspace, or was removed; ask an owner
                or admin for member access

The same message covers a removed account, because from the daemon's side the two are indistinguishable: the workspace refused the write.

Careful

Refused writes pile up as dead letters. Somebody who worked for a week as a viewer will have a large number of them once promoted. They can be retried or discarded in bulk, and a week of stale sessions is usually worth discarding rather than replaying. See Queued and rejected writes.

Removing someone#

Settings → Members. Their machine stops publishing immediately. What they already contributed stays with the workspace, attributed by name. A team's shared record is not rewritten because a contributor left.

Owners have obligations#

An owner cannot simply leave a workspace. They transfer ownership or delete the workspace, because a workspace without an owner is one nobody can bill, manage or shut down. Deleting an account is blocked by an owned workspace for the same reason.

Invitation troubles#

The invitation email never arrived

Check

Spam, then the exact spelling of the address on the pending invitation in Settings → Members.

Fix

Revoke and re-send. If the invite step shows an amber notice, mail delivery is unconfigured or failing on our side rather than yours. Tell us and we will look. Runi is built never to let "unavailable" look like "succeeded", so that notice means what it says.

“This address cannot start a workspace”

Cause

An address with no trial and no workspace of its own is refused. Signing up is not by itself a route to a free workspace.

Fix

Either accept an invitation to an existing workspace, or start a trial at tryruni.com/start.