Sites
Sites let a workspace organize its devices and gateways by physical location: a hierarchy of up to three levels (campus, building, floor) that equipment attaches to.
Sites are created and managed by your customers inside their own workspace, so the full how-to, creating and nesting sites, the site tree, attaching equipment, restricting a member to a site, and reading-level site attribution, lives in the end-user guide: Sites. Everything there works the same for you when you act as a sub-account. This page covers the parts that are yours: turning the feature on, and working across sub-accounts.
Multi-site is off by default. It is a sub-account feature, so a customer cannot see or use Sites until you switch on Multi-site on that sub-account's tier. Nothing appears in their workspace until you do. See Turning multi-site on below.
Where to find it: Sidebar -> Operations -> Sites, while acting as one of your sub-accounts. Sites are sub-account-scoped.
Turning multi-site on
Sites are off by default. Enable them per sub-account tier with the Multi-site feature, under Settings -> Sub-account Tiers (see Sub-accounts -> Setting up sub-account tiers). A sub-account only sees the Sites module once its tier has multi-site switched on, and a partner-tier ceiling caps what a sub-account tier can enable.
Working across sub-accounts
As a Partner Admin you can see and manage sites for any sub-account on your partner; when you create a site you choose which sub-account it belongs to. Each sub-account's sites, and everything attached to them, stay within that sub-account. A network can belong to a site, and the equipment in that network inherits the site automatically.
In the API and webhooks
Sites are a first-class part of the public API and webhooks: a read-only sites resource, a siteId on devices, gateways, and networks, the ability to filter those lists and a device's history by site, and a sites webhook filter mode plus a site block on every event payload. See API endpoints -> Sites and Webhooks.