--- title: "Shippers, Shipper Teams, and Shipper Users" description: "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." url: "https://support.pr-10.orbit.do/en/getting-started/shippers-shipper-teams-and-shipper-users" locale: "en" apps: ["mission", "hub"] lastReviewed: "2026-10-19" --- # Shippers, Shipper Teams, and Shipper Users 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. > **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. ## Overview 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. ## Shippers 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: * Company name and legal information (tax ID, VAT ID) * Primary business address * Company-wide settings and configurations * Pricing models and tariff assignments ## ShipperTeams 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: * Departmental organization (e.g., logistics, procurement) * Regional divisions * Functional groups ## ShipperUsers ShipperUsers are individual users who belong to a Shipper organization and can be assigned to specific ShipperTeams. Each user has: * Personal information (name, contact details) * Individual access rights and permissions * Specific roles defining their capabilities within the system * Personal notification preferences ## Orbit Hub Access 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: ### Activation Link (Default) 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. 1. The operator creates the `ShipperUser` in Orbit MissionControl (or via the API with `inviteToSetPassword: true`) 2. The user receives a branded activation email with a **Set Password** link 3. The user clicks the link, receives a verification code by email, and sets their own password 4. 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). ### Manual Password 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. ### Suppressing the Welcome Email 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. ## Switching Teams in Orbit Hub 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. ### Accessible Teams 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. 1. In Orbit MissionControl, open the `ShipperUser`. 2. Edit the row **Accessible teams**, directly below **Shipper Team**. 3. 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. ### Switching the Active Team A user sees the switcher when they have more than one active team to switch between and their role allows the switch. 1. In Orbit Hub, click **Active team** at the bottom left of the sidebar, above **Logout**. 2. 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. ### What Follows the Active Team 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. ### Limiting the Switch With a Role 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](https://support.pr-10.orbit.do/en/advanced-features/roles-and-permissions)): * A role that denies the **Action Type** **Set Shipper Team** hides the switcher. * To allow the switch again, but only into the user's accessible teams, add a permission after that denial: create `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. ## What a Shipper Can See 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?](https://support.pr-10.orbit.do/en/faq/what-can-each-role-see-in-orbit) ### Who Appears in the Team Card 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. ## Why Some Order and Stop Fields Look Blank 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](https://support.pr-10.orbit.do/en/getting-started/managing-locations-and-contacts). To set when a location can receive or hand over goods, see [Operating Hours for Locations](https://support.pr-10.orbit.do/en/core-features/operating-hours-for-locations). ## Partial Data Inheritance 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. ### How Inheritance Works * ShipperTeams inherit base company information from their parent Shipper, such as company address and general settings * Teams can override certain inherited settings with team-specific configurations * ShipperUsers inherit settings from both their Shipper and assigned ShipperTeam * Properties and configurations can be set at any level, allowing for flexible customization ### Benefits of Partial Inheritance * Reduces redundant data entry * Maintains consistency across the organization * Enables local customisation when needed * Simplifies management of shared settings 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. ## API Access All these entities can be managed through Orbit's REST API, which provides endpoints for: * Creating and updating Shippers, Teams, and Users * Managing relationships between entities * Configuring settings and properties at each level * Retrieving entity information and hierarchical relationships 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](https://orbit-api.readme.io/). ## FAQ **Q: Why is the contact or opening-hours field on an order blank?** 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". **Q: Can a shipper see other customers' orders?** No. Each shipper sees only its own orders and shipments in Orbit Hub. Other shippers' bookings are never shown. **Q: Why does the Team card list users of other teams?** 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**. **Q: Can a ShipperUser switch to a team of another shipper?** No. Accessible teams are always teams of the user's own `Shipper`, and Orbit refuses a team of another `Shipper` or an inactive team. **Q: What happens if a user with accessible teams does not see the switcher?** 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. **Q: Can the user switch back to the previous team?** 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**. **Q: What happens to a booking that is open in another tab during a team switch?** 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. **Q: Where do I manage a shipper's saved addresses?** In the shipper's Address Book. See [Managing Locations & Contacts](https://support.pr-10.orbit.do/en/getting-started/managing-locations-and-contacts) and [Operating Hours for Locations](https://support.pr-10.orbit.do/en/core-features/operating-hours-for-locations).