Multiple Tenants Per Site and Location

[wirestar]

Today you can only assign one tenant (company) to a site or location. Can we enhance this feature to allow multiple tenants to be assigned to a site or location?

Multiple contacts can be assigned to a site or location, but a contact is an individual where a tenant is a company.

[candlerb]

What's your use case - by which I mean, what's the specific workflow you want to enable?

The current model is to label when a particular Site, Location or Rack is dedicated to one tenant. If it's shared, then you look at the tenancy of the objects contained within it.

So for example if a rack contains devices belonging to tenants X, Y and Z, you don't set the tenancy of the rack. But you can still search for devices with tenant X, Y or Z, and you'll be able to see what racks (and locations/sites) those are in.

[wirestar]

The use case if for apartment complexes. We define the complex as a site, buildings at the complex as locations, and units in the buildings as locations under the buildings. Multiple tenants live within one unit. We only have one access point (device) in the unit, and it too is shared among the multiple tenants. Hence, the need to be able to assign multiple tenants to a site, loction, or device.

[jeremystretch]

It sounds like you're trying to use tenancy to track individual customers, which is not its intended use. The tenant to which a device is assigned should be whoever owns the equipment, which in your case sounds like it would be your company, not the resident(s).

[jvalente-salemstate]

A similar use-case to the one presented by @wirestar would be in public sector IT departments.

e.g. a municipal government IT department may be managing all/components of K-12, parks & rec, the DPW, the Fire Department, mayor's office, etc. Here in Massachusetts, there is a central state agency for information technology responsible for nearly all of the other state agencies.

Departments/Agencies or items assigned to them may end up sharing any combination of sites & locations, racks, devices, IP ranges, VLANs, Clusters, and so forth. Tags may serve to meet several of those requirements, but they also do the same for many other things. It gets cluttered in the UI and filtering queries gets increasingly complicated.

A custom field can avoid a lot of it. But for tenants specifically, the helpful stuff in the existing, built in tenant views isn't available. For example the Related Objects section in the tenant view would really show what's related and not just a dedicated assignment. A custom view could replicate it, but allowing multi-tenancy within the Tenant property would do it much better imho. As a plus it would be much more clear when something is assigned to no tenant vs multiple tenants.

There's plenty of use cases where a single tenant assignment makes sense and those would still be met while allowing more than one selection.

[jeremystretch]

Departments/Agencies or items assigned to them may end up sharing any combination of sites & locations, racks, devices, IP ranges, VLANs, Clusters, and so forth.

Right, but which entity is responsible for the equipment? There can only be one; this is typically whoever purchased the equipment or is responsible for fixing it. If a single entity (e.g. the IT department) owns all network equipment, then there's no need to assign tenants at all.

There's plenty of use cases where a single tenant assignment makes sense and those would still be met while allowing more than one selection.

It is not possible to serve both use cases with the same attribute: Ownership and dependency are entirely different concepts.