The three sites in this model
The arrangement described here has three locations: a head office, a regional branch with an administrator working on site, and a smaller site with nobody administering it locally, whose work is mostly with outside clients.
The small site is the one worth watching. A location with nobody administering it either gets its administration from somewhere else by name, or quietly develops a local practice that nobody wrote down and nobody reviews.
Who performs which action
Each line has exactly one holder. A branch administrator works inside the permission groups the owner defined and cannot widen them. The owner does not approve individual guests at a branch, because the host running the session is the person who can see who is asking to join.
All three sites work inside one deployment, self-hosted and reached through its own domain. The organization and branch controls are what carry the table above from one location to the next without anyone re-deciding it locally.
Bringing a new branch on
This runs in order, and the order matters: a branch administrator cannot assign a permission group the owner has not defined yet.
When a person joins, moves, or leaves
- Joins: the administrator for that site creates the account and sets the permission group. Nobody signs themselves up.
- Moves between sites: the administrator at the new location takes over the account, and the permissions from the previous location are closed the same day.
- Changes role: permissions move to the group that matches the new role, including the right to invite outside guests.
- Leaves: access is withdrawn in one deliberate action, and the branch administrator checks that no shared device is still signed in under that account.
- Any of the four: the duplicate-session warning shows when an account is connected from a second place, which is a useful signal during a handover.
Guests from outside the organization
Outside participants are the reason many of these sessions exist. The standard for admitting them is written once at the head office and applied the same way at both branches.
- Owner: decides which permission groups may invite guests, and at which sites.
- Branch administrator: grants that permission to named staff and reviews the list.
- Host: sends the room link, then approves each guest from the waiting view before they appear in the participant grid.
- Host: declines anyone unexpected, and the session carries on without a pause.
The small site does most of its work with clients, so this is the path it uses every week. That is the argument for giving it a named administrator at head office rather than leaving it to improvise.
The review that catches drift
Everything above holds for as long as somebody checks it. The review is what turns up an account that was left open after someone left.
- Each administrator lists the accounts at their site and compares that list with the people actually working there.
- The owner reads the permission groups end to end and confirms they still describe real roles.
- Devices are checked by location. A machine in a meeting room at either branch is held to the standard the head office set.
- The operations team confirms that backups completed and that spare capacity still matches the volume of sessions being run.
- Anything that failed a check gets a name against it before the review ends.
- multi-site
- administration
- branches
- operations