Hierarchical organisation of Shippers, ShipperTeams, and ShipperUsers, including Orbit Hub access, switching teams in Orbit Hub, why some order fields are inherited from the address book, and shipper-only visibility.
Was this article helpful?
Did not find your answer?
Ask Luna, or write to our support team.
Note
A Shipper is the customer a transport is booked for. In Orbit MissionControl you organise each shipper, its teams and people, and its saved locations, and each shipper sees only its own bookings through Orbit Hub.
In Orbit, shippers are organised in a hierarchical structure consisting of Shippers (companies), ShipperTeams (organisational units), and ShipperUsers (individual users). This structure enables efficient organisation and precise control over access rights and operational capabilities.
A Shipper represents a company or business entity that needs to send goods via road transport. Shippers are the top-level entity and contain core company information such as:
ShipperTeams are organisational units within a Shipper entity. Teams help organise users and manage access within the Shipper's organization. Common uses for teams include:
ShipperUsers are individual users who belong to a Shipper organization and can be assigned to specific ShipperTeams. Each user has:
A ShipperUser can optionally be granted access to Orbit Hub, the customer-facing portal where they can independently book and manage transports. When creating a ShipperUser with Hub access, you choose between two account activation modes:
The recommended approach. The ShipperUser is created and receives an activation email with a link to set their own password. No password is shared or transmitted in any communication.
The operator creates the ShipperUser in Orbit MissionControl (or via the API with inviteToSetPassword: true)
The user receives a branded activation email with a Set Password link
The user clicks the link, receives a verification code by email, and sets their own password
After setting the password, the user is automatically signed in to Orbit Hub
This mode ensures that passwords are never included in emails, aligning with security and compliance requirements (e.g., NIS2, TISAX).
The operator sets a password directly during user creation. The password can optionally be included in a welcome email. This mode is available for backwards compatibility but is not recommended for security-sensitive environments.
When using the API, you can set sendWelcomeEmail: false to prevent Orbit from sending any email. The API response includes an activationUrl that you can use to send your own branded communication.
A ShipperUser works in one team at a time, the active team. When a user books for several teams of the same Shipper, you can give them access to further teams, and they switch the active team themselves in Orbit Hub.
Each ShipperUser can have a list of Accessible teams: all teams of the same Shipper that the user may switch between. List the user's active team too. A switch changes only the active team, never the list. A user without accessible teams stays in their team, and Orbit Hub shows them no switcher.
In Orbit MissionControl, open the ShipperUser.
Edit the row Accessible teams, directly below Shipper Team.
Choose the teams the user may switch to and confirm.
The row appears only when the Shipper has more than one team. It offers every active team of the Shipper, the user's active team included. Orbit refuses a team of another Shipper, in Orbit MissionControl, in Orbit Hub and through the API alike, and never moves a user into an inactive team.
A user sees the switcher when they have more than one active team to switch between and their role allows the switch.
In Orbit Hub, click Active team at the bottom left of the sidebar, above Logout.
Under Switch team, choose the team. With nine teams or more, type in Search teams to filter the list.
You can also switch in Settings: the Team card shows the select Active team. On a phone, the sidebar is hidden, so the switch is in Settings only.
After the switch, Orbit Hub confirms with "You're now working in team" and the name of the team. On Home, on the lists in Transport Overview and Address Book, and in Settings, Orbit Hub stays on the page and shows the new team. On a detail page or inside a booking, Orbit Hub opens Home, because that page belongs to the previous team.
The user can switch back to the previous team as long as it is in their accessible teams.
New bookings and new saved addresses belong to the active team. Everything the user's role limits to their own team follows the active team too, for example the Orders in Transport Overview. A role that does not limit by team shows the same data in every team.
If the user switched the team in another browser tab, Orbit Hub does not send a booking still open for the previous team. It shows "Your active team has changed. Please check the booking before you send it." and reloads the booking with the active team. Check the booking and send it again.
With a managed shipper role, the accessible teams alone decide where a user can switch. A custom role can limit the switch further (see Roles and permissions):
ShipperUserAction with the condition Shipper Team is any of the dynamic value Accessible teams. Only a team switch carries a team, so this permission allows nothing else. Orbit Hub lets users switch only their own team.For example, Orion Industries ships from Paris and from Lyon, with one team per site. Julia books transports for both sites. Her operator sets her accessible teams to the Paris team and the Lyon team. In the morning Julia books a collection for Paris; in the afternoon she switches to Lyon in the sidebar and books for Lyon. Each Order belongs to the team that was active when Julia booked it.
A shipper is the customer a transport is booked for, so in Orbit Hub a shipper sees only its own bookings: its own Orders and Shipments, and never another shipper's. A short list under a shipper account is therefore the portal working as intended, not missing data. For a fuller picture of who sees what across Orbit, see What can each role see in Orbit?
In Settings, the Team card lists the users and open invites of the whole Shipper, across all its teams. With a managed shipper role, this is intended: colleagues of every team see each other.
A custom role can limit the list to the user's own team. Give the permissions to read ShipperUser and ShipperUserInvite the condition Shipper Team equals the dynamic value Shipper Team. The list then follows the active team: after a switch, the user sees the colleagues of the new team. On an Order, the name of the person who booked it stays visible, also when that person now works in another team.
When you open an order or a stop, you may notice that fields such as the contact, the exact loading point, or the opening hours are empty. This is usually because those details are inherited from the shipper's Address Book rather than stored on the booking itself, so they are filled in by reference, and are not missing.
When a booking uses a saved location, Orbit draws its address, contacts, and opening hours from that saved record. If a field looks blank, the information typically lives on the saved location, and often on the specific loading point within it, which can keep its own opening hours. Checking the shipper's address book is the first place to look before treating anything as absent.
To manage these saved locations and the people attached to them, see Managing Locations & Contacts. To set when a location can receive or hand over goods, see Operating Hours for Locations.
Orbit implements a partial data inheritance concept between these entities. This means that certain data automatically flows from parent entities to their children, while allowing for customization at each level.
For example, while a Shipper might set company-wide pricing models, individual teams can have specific rate adjustments, and users within those teams might have personalized notification preferences.
All these entities can be managed through Orbit's REST API, which provides endpoints for:
The accessible teams of a ShipperUser are the field allowedShipperTeamIds, which you can set when you create the user and which the API returns when you read it. List every team the user may switch between, the current shipperTeamId included; for a user with one team, list only that team. A team switch in Orbit Hub never changes the list. The action set-allowed-shipper-teams replaces the whole list: every id must name a team of the same Shipper, duplicates are removed, and an empty list clears it.
Note
Orbit's extensive API reference is separated from Orbit Docs and can be found here: Orbit API Reference.
Those details are usually inherited from the shipper's Address Book rather than stored on the order. Open the saved location and its loading point to see them. A blank field here means "inherited", not "missing".
No. Each shipper sees only its own orders and shipments in Orbit Hub. Other shippers' bookings are never shown.
With a managed shipper role, the Team card lists every user and open invite of the shipper, across all its teams. To show only the user's own team, use a custom role that reads ShipperUser and ShipperUserInvite only with the condition Shipper Team equals the dynamic value Shipper Team.
No. Accessible teams are always teams of the user's own Shipper, and Orbit refuses a team of another Shipper or an inactive team.
The switcher appears only when the user has more than one active team to switch between and their role allows the switch. Check that the accessible teams are active and that the user's role does not deny Set Shipper Team. On a phone, the switch is in Settings, not in the sidebar.
Yes, when the previous team is in their accessible teams. A switch never changes that list, so list the user's active team too. The user switches back in the sidebar or in Settings.
Orbit Hub does not send it for the previous team. It asks the user to check the booking, reloads it with the active team, and the user sends it again.
In the shipper's Address Book. See Managing Locations & Contacts and Operating Hours for Locations.