Team, roles and folders

Every account belongs to a workspace. If you signed up alone, you own yours and you are its only member. When you accept an invite, your account stops resolving against itself and starts pointing at the owner's workspace.

From that moment the owner's plan is your plan. Profile quota, device seats, the proxy pool, folders and the log all resolve against the owner, so the team draws from one paid pool and one bill. That is why a member cannot pay separately to get more room: the room belongs to the workspace.

A seat is a person in that workspace, and the owner always holds one. A plan with three seats means the owner plus two colleagues. Extra seats cost $3 each per month and are added to the plan price before the term discount, so a quarter takes 10% off the total and a year takes 20%.

The seat count lives on the account's entitlement record, not in the plan name. Seats are bought one at a time, so the app reads the number the server sends instead of deriving it from a label. When those two disagreed, people who had paid for three colleagues saw one seat and could invite nobody.

Free

1 seat

Professional

1 seat

Business

3 seats

Enterprise

20 seats

The owner holds one of those seats. Buying more seats adds $3 per seat per month to the plan price.

There are five roles. Owner belongs to whoever created the workspace and is never handed out. The four below it are the ones you assign, in the invite or later from the roster.

Roles are ranks, not checklists. Each route on the server declares the minimum rank it needs, and a higher role satisfies a lower requirement. A role the server does not recognise resolves to rank zero, so a typo grants nothing rather than everything.

Be aware of one honest detail: operator and member carry the same rank today. The two names exist so a roster can read the way a team actually talks, not because the rights differ. Everything a member may do, an operator may do, and the other way round.

A role applies to the whole workspace, so it alone cannot say "this freelancer works on one client". Folders do that. Open a member's Folders dialog, tick the groups they may see, and their list narrows to those groups.

The rule is read in two places, and it has to be. The profile list filters to the allowed folders, and opening a profile by its id runs the same check. Without the second one the restriction would be decoration, because ids travel in links, exports and scripts. A profile outside the allowed folders answers "not found", not "forbidden", so the difference between the two answers cannot be used to map what the neighbours have.

A profile filed in no folder is hidden while a restriction is set. Otherwise the limit is dodged simply by not filing the profile. Access rows are written against your workspace, so a limit set by a previous employer does not follow the person into their next one.

Only the owner or an admin hands out folders, and only to members of their own workspace. Folder ids are checked against your groups before they are stored, so a stranger's id cannot be used to grant access somewhere you are not the owner.

Sharing is what replaces sending logins around. You pick colleagues in the Share dialog, the server writes one row per person, and the profile appears in their list with a mark saying it was shared with them.

The call sets the full set rather than a delta. Anyone missing from the request loses access, which is exactly what makes unticking a name work. Targets must belong to your workspace, and you cannot share a profile you do not own, so the dialog says that before the server has to.

When you revoke, the profile disappears from their app on the next sync. The browsing data already sitting on their disk is left alone on purpose: a revoked share can just as easily be a reshuffle, and wiping someone's work without asking is worse than a folder staying behind.

• Fingerprint and settings

  travel with the profile, so the colleague opens the same identity rather than a lookalike copy

• Cookies and logins

  travel through profile sync when it is turned on, so the session is continued instead of started again

• Pool proxy passwords

  a manager reads them from the pool; an operator gets one only together with a profile that was actually shared to them

• The mark in the list

  a shared profile is flagged as someone else's, so "delete" on it does not quietly mean what it means on your own

Two people opening one profile at the same time produces two live sessions of one account from two places. That is the behaviour the whole product exists to avoid, so it cannot be left to good manners. Machines do not see each other, so the server holds the lock.

The lock is held by time, not by promise. A machine pulled from the wall stops renewing and the profile frees itself. And when the server is unreachable, or answers with an unknown route, the app starts the profile anyway: the lock protects you from a colleague's window, it is not the permission slip for your own work.

1. 1

   Start claims it

   The app sends its machine id and hostname. The claim is written conditionally, so two simultaneous starts cannot both believe they won.

2. 2

   A refusal names the holder

   The second machine gets a 409 carrying the holder's machine name, its id, since when, and whether it is your own other computer.

3. 3

   Takeover is deliberate

   You can take the profile, but only from the exact holder you were shown. Two takeovers racing each other cannot both succeed.

4. 4

   Renewal every minute

   While the profile is open the app extends the lock. Only the same machine that took it can extend it, not another machine of the same person.

5. 5

   Three minutes and it lapses

   A crash or a power cut stops the renewals, and the profile is free again once the lock expires. Nobody has to call support.

6. 6

   The loser is told

   If your lock was taken while you worked, the next renewal fails, your windows close and a notification says what happened.

Every action worth arguing about writes one row: who, what, when, and which workspace it belonged to. The workspace is stamped at the moment of writing. That single detail is why removing a colleague no longer empties the owner's history, which is precisely when history is needed.

Each row carries a small JSON detail block. When the call arrived through an API key, the key id is written down too, so "Ivan did it" can be read as "Ivan's script did it" and one leaked key does not mean revoking all of them. Names are frozen as they were that day, so renaming a profile today does not rewrite last week.

Reading the log is an admin or owner action. There are three views over the same rows: everything, browser open and close, and logins with device registrations carrying IP, country and machine name.

• Profiles

  create, update, delete, restore, start, stop

• Proxies

  create, update, delete, check, rotate, plus every time a stored password was handed out

• Team

  invite, invite withdrawn, invite accepted, role changed, folder access changed, removal or departure

• Devices and access

  device registered, device unlinked, login, login locked after failed attempts, two-step turned on or off

• Money and keys

  plan change, refund, manual access cut or grant, API key created and revoked

Machines are the second kind of seat. The plan gives you a number of them, counted across the whole workspace, and the earliest registrations hold them. The order is deterministic on purpose, so the same machine does not drop out of the pool on one heartbeat and back in on the next.

Unlinking is remembered. It used to be a plain delete, and the app registered again on the next heartbeat: you unlinked a machine and watched it come back a minute later. Now the row is marked as unlinked, the seat is free immediately, and the machine is told the truth on its next heartbeat instead of quietly reclaiming its place.

Anyone may unlink their own machine. Only an admin or the owner may unlink somebody else's, because any member being able to unlink any machine meant a member could lock the owner out of the owner's own product. Signing out on the machine itself is a different act: the row is deleted, because a person sitting at that keyboard is not a remote decision.

People leave. The path is the same whether the owner removes them or they leave on their own, because two paths to one event will eventually disagree about something and one of them will forget to revoke access.

Everything below happens in one transaction, in this order.

1. 1

   Access is cut both ways

   Their access to your profiles goes, and so does anyone's access to the profiles that leave with them. Shares on the profiles that stay are kept, so colleagues who remain are not silently left without work.

2. 2

   Their lock is released

   Otherwise a profile they had open would look occupied for three minutes and then answer "not found", which reads as a profile that vanished.

3. 3

   Work profiles move to the owner

   Profiles created after they joined were made in your quota, so they stay with the workspace. Profiles they brought with them, created before joining, leave with them.

4. 4

   Pool proxies stay behind

   The link to your pool is cleared from the profiles they take, and the saved copy inside the profile is wiped when it matches your pool by host, port and login. A proxy they bought themselves is theirs and is left alone.

5. 5

   Devices are dropped

   Their machine rows go, so those device seats come straight back to the workspace.

6. 6

   Unused invites are burned

   A second, never-accepted code issued to the same address would otherwise be a working key back in.

7. 7

   Folder limits are cleared

   Otherwise your restriction travels with the person into their next workspace, where those folder ids do not exist, and locks them out of everything there.