The questions asked before opening a tool to the team are always the same. Who can see what, who can change what, does one department's data leak into another's?
In Orbi the answers sit in three places. Roles, the invitation method, and the boundary between workspaces.
Three roles
Roles are per workspace. The same person can be an admin in one workspace and only a viewer in another.
An admin manages projects, members, connections and the subscription side. Every write operation is open.
A member opens tasks, writes comments, adds records to collections and sets up their own personal connections. All of the daily work runs on this role.
A viewer only reads. The right choice for stakeholders who watch the board but do not touch it.
Authorisation does not stop at the interface. Every server endpoint is protected by role, so an operation you are not allowed to make is refused when called directly, just as it is missing from the screen.
What only an admin can do
Some things are deliberately kept in one pair of hands. Opening and deleting projects, inviting members and changing roles, adding a workspace-wide service connection, putting a collection in the menu as a permanent screen, and managing the subscription.
Personal connections are outside that list. You do not need an admin to connect your own account.
Two ways to invite
The first is a personal invitation. It goes to a specific email address, and clicking the invitation link counts that address as verified. The right method for people whose name and address you know. When sending the invitation you can also write the person's title, and it goes onto their membership when they join.
The second is a shareable link. Anyone who gets the link joins with the role you chose.
Keeping the shareable link narrow
There used to be a single permanent link per workspace. That is no longer the case, and the difference is useful when moving a team over.
When opening a new link you choose three things. The role can be admin, member or viewer. The lifetime can be unlimited, one day, seven days or thirty days, and seven days is preselected. The usage limit can be unlimited or capped at one, five, ten or twenty-five people.
Several links can exist side by side. You open a permanent member link for the team and a seven-day, five-person viewer link for a client, and both sit in the same list. The list shows each link's role, how long it is valid, how many times it has been used and who opened it.
A link whose time or limit has run out closes on its own, is marked with a badge in the list, and you delete it if you want. Someone clicking a closed link sees why, so they can ask you for a new one. Deleting a link does not affect the membership of anyone who already joined through it.
One thing has not changed. You can never trace who a link reached. In a sensitive workspace, prefer personal invitations or put a short lifetime and a small limit on the link.
Work does not stop when the invitation email fails
The invitation email is sent in the background, and if the server cannot deliver it for the moment, it retries at growing intervals.
If you do not want to wait, the invitation link is always at hand. You copy it and pass it to the person yourself, and the link works exactly as if it had come from the email.
The most annoying moment when opening a new tool to a team is nobody being able to get in because of an email setting. This detail solves exactly that.
The reverse of an invitation exists too
Someone viewing a page your team has shared externally can send you a join request with the button at the top of the page. The request needs an Orbi account, so you always know who it came from.
When a request arrives, admins get a notification and an email. In the join requests section of the Team screen you see the person's name, email and which page they came from, pick a role and approve or decline. The role picker starts on viewer, because the person arrived from a view-only link.
If you never want that button shown, you switch off the sharing toggle in settings. Pending requests are not deleted.
Title and description are not only for humans
Every member can have a workspace-specific title and a short description. The title is one line, and the description says what the person does and what they decide on.
The interesting side of these two fields shows up with agents. Agents see the team list on every run and look at a person's description when writing to them. To the designer they write user impact instead of technical detail, to the engineer they write short and concrete. When you say "assign this to the designer", they find the right person from the title.
An admin writes the title for everyone, and every member can edit their own line.
Agents are open to everyone
There are no personal or hidden agents. All agents are open across the workspace.
It was built that way so anyone can assign any agent to a task. Because an agent is thought of as a team member, who may call whom is not tied to a separate permission list.
Editing an agent affects everyone who uses it. What you are changing is a shared resource.
What an agent can touch is a separate matter. Connection access is granted per agent, so an agent everyone can call does not have to have access to every service.
An agent takes a seat too
The Team screen tells you how many agents you have, and that number is more than an information note.
Adding an agent uses one of the team member seats in your plan. The seat count puts humans and agents on the same footing.
It may feel odd at first, but it is a consistent choice. If an agent behaves like a member on the board, it is counted like one on the cost side too.
There is a wall between workspaces
Every workspace's data is self-contained. A member of one workspace cannot see the tasks, files or collections of another workspace they are not a member of.
Not even if they know its identifier directly. Guessing a record's number or getting hold of a link is not enough.
On the agent side the scope comes from the same place. Which workspace an externally connected client sees is resolved from the key it uses, not from a field the client claims.
Three things that stay personal
The answer to "does the admin see everything" is no, and the line is drawn in three places.
Your personal service connections load only in runs you start and cannot be assigned onto an agent. When another member runs the same agent, your account does not come into play.
Nobody, admins included, can see your personal-scope memory notes. Preferences like "give me short summaries" live there.
Your chats do not enter workspace search either, because they count as personal correspondence and are not indexed.
Leaving is an operation too
Leaving, deletion and closing the account are all done from the data tab in settings, and all three go through a confirmation step. The rule is the same for all of them, because a workspace is never left without an admin. If you are the last admin you cannot leave. You first make another member an admin.
A deleted workspace waits in the bin for thirty days, and during that time any admin can restore it.
From the same data tab you can download the entire workspace as a single archive. The archive carries projects, tasks, collections, files, agents, flows and the audit log. Nothing that carries authority goes into the archive, so API keys, connection credentials and tokens stay out. That is a deliberate choice, because someone who gets hold of a backup file should not also get access to the team's accounts.
Where to start
Do not move the team over in one go. Bring two or three people in first with personal invitations.
Start the roles narrow too. The member role is enough for most people, and you raise the number of admins as needed.
If you are bringing in someone from outside, open the shareable link with a short lifetime and a limit. A seven-day viewer link given to a client is far easier to manage than a permanent admin link.
If you do not want different departments' data to see each other, set up separate workspaces. Separating projects gives order, but isolation is built at the workspace level.
Role permissions, invitation methods and isolation are covered in Roles and invitations in the help center. For the security side, see Plans and security.
If you want to try it, you can open a free account and set up your first workspace.