iMonnit Locations vs. Networks

Introduction

To effectively manage your Monnit sensor system, you must understand its two foundational structures: Locations and Networks.

These concepts separate administrative duties from hardware management. Locations are used to organize people, user permissions, and notification policies. In contrast, Networks are used to organize physical devices like sensors and gateways and their communication paths.

A clear grasp of this distinction is critical for building a secure, scalable, and easily manageable sensor monitoring system. Please see Understanding the iMonnit Account Hierarchy.

Section 1: Strategic Implementation: Choosing Your Architecture with Practical Examples

Synthesizing these concepts, the choice between a single-Location and multi-Location architecture depends entirely on the specific needs for administrative and data segregation versus cost-effectiveness.

Scenario A: When to Use a Single Location with Multiple Networks

• Architecture: This model consists of one Location containing one to five Networks. All Users, Rules, Reports, and Maps exist in a single administrative pool, and a single iMonnit Premiere subscription covers all devices.

  Ideal Use Case: This structure is ideal for a single, contiguous physical site managed by a cohesive team, where the primary requirement is to segregate device communication paths rather than administrative functions. Examples include:

  • A multi-story office building where each floor is configured as a separate Network to ensure sensors on one floor only communicate with the gateway on that same floor.
  • A manufacturing plant with different Networks for the production line, the warehouse, and the administrative offices.
  • A cold storage facility with separate Networks for distinct temperature zones (e.g., freezers, coolers, ambient storage).
• Why it Works: This model is perfect when the main goal is to control sensor-to-gateway communication. While an administrator can limit which users can view which networks , it is assumed to be acceptable for all users to share a common list of other users and a master list of notification rules. This is the most cost-effective architecture, as it requires only one subscription.

Scenario B: When to Use Multiple Locations and Sub-Locations

• Architecture: This model consists of a Parent Location with one or more sub-Locations. Each Location acts as a distinct administrative boundary with its own separate set of Users, Rules, Reports, and Maps. Critically, each Location requires its own subscription.

  Ideal Use Cases: This structure is necessary when absolute administrative isolation is required.

  1. The Reseller/Managed Service Provider (MSP): An MSP managing Monnit deployments for multiple, independent clients would create each client as a separate Location. This ensures complete data, user, and billing privacy between clients, while the MSP can use a Parent Location to oversee all client accounts.
  2. The Multi-Site or Siloed Enterprise: A corporation with geographically distinct branches (e.g., offices in New York, London, and Tokyo) or functionally independent divisions (e.g., Research & Development, Manufacturing, and Sales) that do not share personnel or operational policies.
• Why it Works: This architecture provides true multi-tenancy. The users in the London Location will have no knowledge of the users in the Tokyo Location. The rules for the Manufacturing division will be completely separate from the rules for the R&D division. This enhances security by preventing any possibility of cross-departmental data access and allows billing to be aligned with distinct cost centers. The primary trade-off for this level of segregation is the higher cost associated with the per-Location subscription requirement.

The Hybrid Decision: Configuring a Single Physical Site

The choice of architecture is not always dictated by physical separation. A single large building could be modeled in either way, depending on the administrative requirements of the occupants.

• As a Single Location: If the different departments within the building are part of a single, cohesive operational team and can share a common set of rules and administrative oversight, it should be configured as one Location with multiple Networks. This approach prioritizes operational unity and cost-effectiveness.
• As Multiple Sub-Locations: If the departments are highly siloed (e.g., a shared building that houses both a general corporate office and a separate, high-security data center with different staff, access policies, and compliance requirements), it should be modeled as a Parent Location with each department as a sub-Location. This approach prioritizes security and administrative segregation over cost.

Ultimately, the decision rests on the answer to a single question: "Do my different user groups require their own separate sets of Rules and administrative boundaries, or is simply controlling which devices they can see sufficient?" The answer to this question will dictate the correct iMonnit architecture for your deployment.

Section 2: Foundational Concepts: The Building Blocks of Your iMonnit Account

Understanding the primary definitions and the fundamental relationship between Locations and Networks is the bedrock for all subsequent, more complex configurations within the iMonnit platform.

What is a Location? The Primary Administrative Container

A Location is the highest-level organizational structure in an iMonnit environment. It serves as the primary container for all of your users, rules, reports, and device networks.

Within the iMonnit system and its documentation, the terms Location and Account are used interchangeably; creating a "New Location" is functionally equivalent to creating a new "Account".

Locations can be organized into a hierarchy, featuring a top-level "Parent Location" with one or more "sub-Locations" (also referred to as sub-accounts) nested underneath. This hierarchical capability allows for the creation of tiered management structures that can mirror a company's organizational chart. For more details on how to create and manage these structures, see Monnit's guide on How to Use the iMonnit Locations Feature

What is a Network? The Device Communication Layer

A Network is a logical grouping of gateways and sensors that exists within a Location. Its most critical function is to authorize communication between specific devices. For a sensor to successfully transmit data to a gateway, both devices must be assigned to the same Network. This mechanism is the primary method for designating which sensors report to which gateways, effectively preventing cross-talk between logically separated groups of devices.

A crucial constraint of the system architecture is the 5-Network Limit. Each Location, including every sub-Location, is strictly limited to a maximum of five Networks. This limitation is not merely a technical specification but a primary factor that drives architectural design, compelling administrators to plan for scale from the outset. To learn how to create a new network within a Location, you can follow the steps in Create a Sensor Network in iMonnit

The Core Hierarchy: A Network Belongs to a Location

The iMonnit hierarchy is unchangeable and foundational: a Location is the parent container, and a Network is a child object that resides inside a single Location. A Network cannot exist independently of a Location, nor can it be shared between multiple Locations. All subsequent rules governing user access, alert configurations, and data segregation are built upon this fundamental model.

The following table provides a quick-reference summary of the key distinctions between Locations and Networks.

Section 3: Object Ownership and Management: Who Controls What?

The iMonnit platform enforces a clear division of ownership, reinforcing the principle that Locations manage administrative entities while Networks manage physical hardware. This separation has profound implications for how an account must be structured.

Location-Specific Objects: The Administrative Layer

The following objects are created within, and belong exclusively to, a specific Location:

• Users: A user account is intrinsically tied to the Location in which it was created and cannot be moved or shared with another Location. To grant a user access to a different Location, an administrator must either create a new, separate user account in that target Location or utilize the "Linking" feature, which has distinct security implications.
• Rules: Rules, which consist of a Condition (e.g., a temperature threshold being exceeded) and a Task (e.g., sending an email alert), are also objects of a Location. The list of available rules, their configurations, and their trigger histories are all managed at the Location level. For a detailed walkthrough of the rule creation process, please refer to the article Create a Rule in iMonnit
• Reports and Maps: Similarly, features like scheduled Reports and visual sensor Maps are tied to a specific Location and cannot be shared, moved, or accessed across different Location boundaries.

The immutability of this object ownership means that the initial architectural choice of how to structure Locations is semi-permanent and carries long-term consequences. For example, if an administrator initially sets up a single Location for an entire company and later decides to split it into two distinct administrative departments, they face a significant challenge. Because Users and Rules cannot be moved from the original Location to a new sub-Location, the administrator would be forced to manually recreate every user account, permission set, and notification rule from scratch in the new Location. This creates a substantial administrative burden, highlighting the importance of anticipating future organizational needs during the initial setup to avoid extensive rework.

Network-Specific Objects: The Physical Layer

The assignment and management of physical hardware are handled at the Network level:

• Gateways and Sensors: When a device is added to an account, it is assigned to a specific Network within a Location.
• Designating Gateway/Sensor Communication: The only way to control which specific gateway a sensor communicates with is by placing that sensor and the desired gateway in one Network, while placing other gateways in different Networks. If multiple gateways exist on the same Network, the sensor will automatically choose which one to connect to based on signal strength, and the user has no direct control over this selection. For detailed instructions on this process, refer to the Monnit knowledge base article:
  • Designating Sensors to Gateways Using Separate Sensor Networks in iMonnit

While sensors cannot be moved between Locations, they can be moved between different Networks within the same Location. This process, however, requires an administrator to reform the gateways on both the source and destination networks to ensure their internal lists of authorized devices are updated. The specific steps for this process can be found in the guide on Moving Sensors Between Networks in iMonnit

Section 4: User Permissions and Access Control: Managing Who Sees What

iMonnit offers two distinct models for managing user access: a standard hierarchical model for users within a single Location structure and a special-case "Linked User" function for providing access across entirely separate Locations.

Standard User Permissions in the Location Hierarchy

The standard permission model is strictly hierarchical and operates with top-down visibility:

• Top-Down Visibility: A user in a Parent Location can be granted permissions to view and manage its sub-Locations, allowing for centralized oversight and administration.
• Hierarchical Blinders: A user's visibility is strictly confined by their position in the hierarchy. A user in a sub-Location cannot be granted permission to view Parent Locations above them or "sibling" Locations that exist at the same level in a different branch of the organizational tree.

• Network-Level Access Control: Within a single Location, an Administrator has granular control over which Networks a specific user can see. By default, a newly created Standard User is not permitted to view any networks. An Administrator must explicitly grant permission for each network the user should be able to access. This is a powerful feature for preventing a user in one department from seeing the sensors and gateways of another department, even when they all exist within the same Location. You can learn how to configure these settings in the article,(https://support.monnit.com/article/210-restrict-or-enable-viewable-networks-for-a-user-in-imonnit). For a comprehensive overview of all user permissions, refer to Edit Permissions in iMonnit

  
  

Cross-Hierarchy Access: The "Linked User" Function

The "Linking" feature is designed for specific scenarios where a single individual needs to access multiple, entirely separate Locations (or Accounts) using a single set of login credentials. A common example is a regional manager who oversees two independent franchise locations, each with its own iMonnit account.

• Administrator Requirement: A user must have Administrator privileges on their own primary account to either initiate or accept a link request from another account.
• The Critical Implication: All-or-Nothing Access: This feature must be used with extreme caution. When a user from Location A is linked to Location B, they gain full, unrestricted access to Location B. The Monnit documentation is explicit on this point: "linked users do not have permissions on the linked account. Therefore there is no manner by which you can limit the networks a linked user can view on the linked account". In effect, the linked user becomes a temporary, full-privilege Administrator of the linked account.

This design indicates that the "Linked User" function is not a simple convenience tool but a high-privilege federation mechanism intended for trusted administrators. The combination of requiring the user to be an administrator on their own account and the subsequent granting of full access on the linked account implies this feature is for peer-to-peer linking between administrators of separate but collaborating entities. An administrator should only accept a link from a user whom they would otherwise be comfortable making a full administrator on their account.

• Official Recommendation: If you need to provide a user with access to another Location but require granular control (e.g., limiting their visibility to specific networks), the Linking feature is not the appropriate tool. In this case, you must create a new, standard user account for them within that target Location. For detailed steps on the linking process, refer to the Monnit knowledge base article: Linking Users to Other Accounts in iMonnit

Section 5: Rules, Alerts, and Subscriptions: The Operational and Financial Framework

The choice of a Location and Network architecture has direct consequences on day-to-day operations, such as alert management, and on long-term financial planning related to software subscriptions.

Alert Propagation in a Multi-Location Hierarchy

As established, Rules are objects that belong to a Location. When a Rule's condition is met, it triggers a configured Task, such as sending an alert notification. The iMonnit system is designed for hierarchical alert monitoring. The main dashboard of a Parent Location provides a top-level, aggregated summary of all alerting, warning, and offline devices within that Location and all of its sub-Locations.

This hierarchical roll-up is a powerful feature for centralized monitoring. A user who exists in a Parent Location can be configured as a notification recipient for a Rule that was created in a sub-Location. This allows a regional manager (user in the Parent Location) to receive critical alerts from a specific site (the sub-Location) without needing to log into or manage that site's day-to-day rule onfigurations.

The Subscription Model: A Strict Per-Location Mandate

The iMonnit subscription model is a critical factor that heavily influences architectural decisions. Each Location and every sub-Location requires its own, separate iMonnit Premiere subscription to access premium features.

• Subscriptions Cannot Be Shared or Pooled: This is a firm financial and operational constraint. A subscription's sensor limit applies only to the specific Location for which it was purchased. It cannot be shared downwards with sub-Locations, upwards with a Parent Location, or laterally with other Locations.
• Illustrative Example: The knowledge base provides a clear scenario to demonstrate this rule. If an organization has 100 sensors distributed across four separate Locations (one Parent Location and three sub-Locations, each with 25 sensors), a single "Premiere 100" subscription applied to the Parent Location is not sufficient to cover all devices. The organization would be required to purchase four separate "Premiere 25" subscriptions—one for the Parent Location and one for each of the three sub-Locations.

This subscription model can become the single most significant factor driving an architectural decision, sometimes overriding purely technical or administrative preferences. When an administrator needs to separate two departments, the cleanest method from an administrative perspective is to create two sub-Locations. However, this choice immediately doubles the recurring subscription cost compared to housing both departments in a single Location. This forces a direct cost-benefit analysis: is the security and administrative benefit of total isolation worth the ongoing cost of an additional subscription? For more information on creating sub-locations and their subscription requirements, you can consult the() knowledge base article. This financial pressure may lead an organization to choose the "good enough" solution of a single Location with network-level permissions, even if a multi-Location structure is technically superior for their organizational needs.