Tenant management
Your tenant is your organisation's own space in the system. Sites sit inside it, robots and maps belong to a site, and every person's authority is expressed as a role — either at one site or across the whole tenant.
Tenant, sites and robots
Everything in the Robot Management Toolbox hangs off three levels.
A tenant is your organisation's space: its sites, robots, users and data, separate from every other customer's.
A site is a place robots work — a building, a floor, a campus. It owns the robots stationed there and the maps they navigate by, and it is the unit most roles are granted at, so someone can be an Operator at one site and an Observer at another.
A robot belongs to one site and is assigned one map. Which map, and which version of it, is what the rest of this page is about.
Roles
| Role | Scope | Can |
|---|---|---|
| Observer | One site | See the site and its robots. No commands, except the E-Stop, which every role at a site may use — releasing it afterwards is an Operator action |
| Operator | One site | Everything an Observer can, plus command robots — dispatch, teleoperate, E-Stop |
| Site Admin | One site | Everything an Operator can, plus manage and activate that site's maps — including its saved locations — and change a robot's name, model, capabilities and assigned map |
| Auditor | Whole tenant | Read operational and audit logs across every site. No commands, no changes |
| Tenant Administrator | Whole tenant | Site Admin authority at every site, plus managing users and roles. Sites themselves are provisioned by Weston Robot |
Observer, Operator and Site Admin are granted per site, so the same person can hold different roles at different buildings. Auditor and Tenant Administrator apply across the whole tenant at once.
Each role contains the one below it, so assigning access is one decision per person per site rather than a set of switches.
Admin is used throughout this documentation as a general term for a user with administrative permissions. Where an action requires a specific role, the required role is named explicitly.
One thing worth planning around: authoring a map and activating it are both administrative authority at that site, so a single administrator can take a map from draft to live. Where a process calls for a second person to approve it first, that approval comes from the process rather than from the system.
Creating users and granting roles
A Tenant Administrator creates the tenant's own users — there is no need to ask us for an account. From Users, select New User:
| Field | What it is |
|---|---|
| Display Name | The name shown against the account throughout the toolbox |
| The address the person signs in with. It is the login identifier, and must be unique across all tenants | |
| Password | An initial password you set for them — at least 12 characters, and different from their last three |
| Require password change on first login | Leave this on, so the person replaces that password themselves |
Tenant Role is authority across the whole tenant:
| Tenant Role | Grants |
|---|---|
| Tenant Administrator | Site Admin authority at every site, plus managing users and roles |
| Auditor (read-only) | Reading operational and audit logs across every site, with no commands |
| None | No tenant-wide authority — the account takes what it can do from its Site Roles instead |
None does not mean no access. It means the account holds nothing tenant-wide. Under Site Roles you then pick a site and the role the person holds there — Observer, Operator or Site Admin — and Add Site Role again for each further site. Someone who works in one building normally has Tenant Role None and a single Site Role; the two are combined, so a tenant-wide role and per-site roles can be held together.
Create finishes the account.
Sites are the one exception. A Tenant Administrator manages the tenant's people, but sites themselves are provisioned by Weston Robot — a tenant with no sites yet, or one that needs another, is what to contact us about.
A site's maps
A site does not hold one map; it holds a map lineage — a named map that is revised over time. A new revision is added to that lineage rather than replacing what was there — so r4 and r5 are the same map at two points in its life and the older one is still on record. Revisions arrive either as a push from the Robot Deployment Toolbox or by uploading a map bundle here.
A revision moves through draft, then published, and one published revision at a time is activated. Activation is the decision that says "this is the revision robots should be running", and it is what the rest of the fleet reacts to. Revisions that are finished with can be archived without being deleted.
A site can hold more than one lineage where it needs them — a second building, or a floor mapped separately — and a robot is assigned to one of them.
How a map reaches a robot
Maps are drawn in the Robot Deployment Toolbox, but a map only reaches a robot through the Robot Management Toolbox, and only once an administrator activates it. The path runs one way.
A revision reaches robots through three steps, and the Robot Deployment Toolbox performs only the first.
| Step | Who | What it does |
|---|---|---|
| Push | Robot Deployment Toolbox, or an upload here | Puts the finished map into the Robot Management Toolbox as a draft revision, either starting a new lineage or adding to an existing one |
| Publish | Site Admin for that site, or Tenant Administrator | Marks the draft as a finished revision, ready to be used |
| Activate | Site Admin for that site, or Tenant Administrator | Makes it the revision robots are given |
The deployment toolbox stops at the draft. Publishing and activating are both actions taken here by a person; the deployment toolbox can do neither, and never talks to a robot at all.
Until a revision is activated, robots keep the map they already have — so a robot never changes map part-way through a job.
How a robot is assigned a map
Two facts are tracked for every robot, and the difference between them is the whole story:
| Target | The map and revision the fleet wants this robot to be running — its assigned lineage, at whatever revision is currently activated |
| Reported | The map and revision the robot last said it is actually running |
While the two agree, the robot is up to date. Activating a new revision changes the target for every robot assigned to that lineage at once, which makes them all out of date until each one catches up.
Applying a map to a robot is not a background operation. The robot stops navigating and restarts its stack, then re-acquires localisation before it can work again — so it is a change to make deliberately rather than to a robot mid-task.
Catching a robot up to the map
Activating a map does not finish the job. A robot keeps the map it already holds until it confirms the new one, and while it is behind, its missions are switched off and cannot be edited or dispatched — rather than run against waypoints that may have moved.
Two of those readings are worth knowing the first time you meet them. downloaded, not applied means the robot has fetched the new map and is still running the old one, so it counts as behind until it switches over. And where a robot's management agent is offline, the dialog says so, and the update waits until it is back — When a robot reads as offline covers what that state means.
The dialog names the map, the revision the fleet activated and the revision on the robot, so it is clear how far behind it is. The recovery is Take control & update, then wait for the robot to confirm; then check the missions and switch them back on. If the switch fails it can be retried from the same place, and the missions unlock when it succeeds.
Two things to plan around. Updating a robot's map restarts navigation, which then has to re-acquire localisation — so it is not a change to make to a robot part-way through something. And it needs robot-management permission at that site, which an Operator holds as well as a Site Admin.
The audit log
Actions taken across your tenant are recorded in an append-only log, readable by Auditors and tenant administrators. Audit log covers the two trails, what each entry records, and how to filter and export them.
Common questions
Can someone have different roles at different sites?
Yes, for the three per-site roles. Observer, Operator and Site Admin are assigned per site, so someone can be an Operator at one and an Observer at another. Auditor and Tenant Administrator apply across the whole tenant at once.
We activated a map but the robots are still using the old one
A pushed map arrives as a draft, and has to be published and then activated before robots are given it. Until then they keep the map they already have, so a robot never changes map part-way through a job. If a robot is still behind after activation, it catches up when it confirms the new map — see How a map reaches a robot.
Who can activate a map?
A Site Admin for that site, or a Tenant Administrator. The Robot Deployment Toolbox cannot publish or activate at all — it pushes a draft, and both later steps happen here.
Can an Auditor stop a robot in an emergency?
No. The Auditor role is read-only by design. Anyone who may need to intervene needs Operator at that site.