Organization Hierarchies
Organizations are the foundation of every Insights instance. All users, as well as all tags and dispensers, must be assigned to an organization.
- We categorize an organization as “a top-level facility or entity,” and that usually results in organizations equating to buildings – for example a main campus and an east campus.
- Organizations can nest – creating parent/child relationships within the data.
- Departments can be labelled based on location
information like floors or wings, or they can encompass department titles, like
ED or PT. If you have departments
assigned to an organization, you’ll see them displayed in the hierarchy.
- New Organization or Department additions must be scoped out per your contract, though, so please reach out to Support should you need assistance with adding to or re-structuring your organizational hierarchy.
Organizations can be configured in many ways within the Insights application. You may only see one organization
listed, or you may see different facilities in a parent/child structure, depending
on the terms of your Mirador contract. If you have multiple organizations,
they have been assigned into the hierarchy dictated during implementation. Below is a simple example of an organizational
hierarchy:
Parent/child hierarchies will impact how data is displayed for all users, dependent upon where the user is placed within the hierarchy itself:
- Users created at the top-level parent organization will see all data for all organizations at or downstream of that facility
- Users created at a child-level organization will see all data for all organizations at or downstream of that facility, but will not see any data from upstream or parallel facilities
- If a User or Tag is assigned to one facility but completes events at a different facility, those events will appear as untagged (public) events if the user/tag is outside of the administrator's access level within the hierarchy.
This allows users to focus on data relevant at their own facility level, and protect access integrity, while still providing aggregate reporting for higher-level administrators who cross multiple organizations.
Below is an example hierarchy with multiple child organizations, wherein:
- A is the first-level (top) parent
- A1 and A2 are second level children
- A11, A12, and A13 are third-level children of A1​​
Within this hierarchy example we have provided the table below, detailing the expected visibility of users for each Administrative level, with U/T assigned at A1:
Location of User's events | Admin at A sees | Admin at A1 sees | Admin at A11 sees | Admin at A2 sees |
A | Tagged event | Nothing (Event invisible) | Nothing (Event invisible) | Nothing (Event invisible) |
A1 | Tagged event | Tagged event | Nothing (Event invisible) | Nothing (Event invisible) |
A11†| Tagged event | Tagged event | Untagged event‡ | Nothing (Event invisible) |
A2 | Tagged event | Nothing (Event invisible) | Nothing (Event invisible) | Untagged event‡ |
†A12 and A13 are not shown, for brevity
‡ Only sanitization counts are included here
If you are an administrator of a child organization and find that your placement within the hierarchy is omitting data that should be visible to you, please speak with your parent organization's administrator. Mirador Support cannot change a user's details, hierarchy or access level.
What about Groups?
Individual Guardian™ dispensers are tethered into what we call “logical groups” which are most often - but not always! - rooms. Groups help us identify location-based events as well as Entry and Exit criteria (when those modules are enabled).
It can be useful when developing your Mirador Insights instance to think of your rooms and other shared spaces as nested underneath each department, to help you visualize how our location-based reports are structured. For example:
You can learn more about creating and managing Groups within the Insights application here.