Team, roles and groups

Every account belongs to a workspace. Accept an invite and you stop standing on your own: from that moment the owner's plan is your plan.

Quota, device seats, the proxy library, groups and the log all come from the owner's plan, so the team draws from one paid pool and one bill. A seat is a person in that workspace, and the owner always holds one.

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. A higher role opens everything a lower one opens.

A role applies to the whole workspace, so it alone cannot say that a freelancer works on one client. Groups do that: press Groups on the colleague's row, tick the ones they may see, and their list narrows to those groups.

The restriction holds in two places, and it has to. A colleague will not see a profile outside their groups in the list, nor by opening it straight from its id, because ids travel in links, exports and scripts.

You pick colleagues in the Share with the team dialog and choose for each person: can start, can edit or full access. The profile appears in their list marked shared with you · can start, or with another level. Targets must belong to your workspace, and only someone with full access can share a profile they do not own.

The dialog changes only the people you ticked, unticked or gave a new level, so access given from another computer stays. When you revoke, the profile disappears from the colleague's app on the next sync.

• Fingerprint and settings

  travel with the profile, so the colleague opens the same identity rather than a copy; hand-picked fingerprint values and a chosen browser version stay on the computer where they were set, and the sharing dialog warns about it

• Cookies and logins

  do not travel with the share itself; Sync sessions carries them when both of you have it on with the same folder and the same passphrase, and then the session continues instead of starting again

• Library proxy passwords

  a manager reads them from the library; an operator gets one only with a profile shared to them

• The mark in the list

  a profile shared with you carries the mark shared with you with your level, and instead of Delete it has Remove from my list

Two people opening one profile at the same time produces two live sessions of one account from two places. Your machines do not see each other, so a profile has one lock for everyone.

The lock is held by time, not by promise. Pull a machine from the wall and nothing is left to renew the lock: three minutes later the profile opens again.

1. 1

   Whoever gets there first

   Two starts in the same second cannot both go through: one person opens the profile, the other gets a refusal.

2. 2

   You see who has it open

   The refusal names the machine holding the profile, since when it has been held, and whether it is your own other computer.

3. 3

   You can only take it deliberately

   You can take the profile, but only after a separate confirmation.

4. 4

   Renewal every minute

   Only the machine that took the lock 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 frees itself, so nobody has to call support.

6. 6

   The server unreachable

   The app starts the profile anyway, because the lock guards you from a colleague's window rather than permitting your own work.

Every action worth arguing about leaves one row in the log: who, what, when, and which workspace. The workspace stays in that row for good, so removing a colleague does not empty the owner's history.

• Profiles

  create, update, delete, restore, start, stop

• Proxies

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

• Team

  invite, invite withdrawn, invite accepted, role changed, group 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

Names in the log stay as they were that day, so renaming a profile today does not rewrite last week. Reading the log is an admin or owner action, in three views over the same rows.

Machines are the second kind of seat. The plan gives you a number of them across the whole workspace, and the machines that registered earliest hold them.

The app remembers an unlink: the seat is free immediately, and the machine itself is told the truth on its next heartbeat. Anyone may unlink their own machine, and only an admin or the owner may unlink somebody else's.

People leave. The path is the same whether the owner removes them or they leave on their own, and nothing in the list below is done halfway: no access is left open behind them.

Everything below happens at once, 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 leaving with them.

2. 2

   Their lock is lifted

   Otherwise a profile they left open would still look busy to everyone else, and anyone who opened it would get an error.

3. 3

   Work profiles move to the owner

   Profiles created after they joined were made in your quota, so they stay with the workspace.

4. 4

   Library proxies stay behind

   They do not take your library proxies with them, while a proxy they bought themselves is left alone.

5. 5

   Their devices leave with them

   Their machines stop holding seats, and those device seats come back to the workspace.

6. 6

   Unused invites are burned

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

7. 7

   Group limits are cleared

   Otherwise your restriction travels with the person and locks them out in their next workspace.