Multi-Level Enterprise Groups Overview
Multi-Level Enterprise Groups is a way to view multiple locations within a group or multiple groups within a parent group. Parent groups allow another level of organization and location management. Groups and locations can be viewed using the Alarm.com customer website and Alarm.com app.
For information about creating a parent groups, see Create a parent group.
Requirements
- A Commercial Service Package
- The Enterprise Security Console add-on selected in the Commercial Service Package
Frequently asked questions
What is a parent group?
A parent group is a blanket term referring to enhancements surrounding parent group visibility and functionality on the Alarm.com customer website. Parent groups can be viewed as an extension to the existing Enterprise Security Console feature that all Alarm.com accounts already have.
Why should I use Enterprise groups?
By combining multiple locations within one group, the customer is able to view high-level system statuses for all locations from one dashboard. The end-user can also create group-level users, notifications, settings, rules, etc. that can apply to all (or some) locations in the group; this saves the end-user from having to create multiple users, notifications, etc. for each location individually.
Why should I use parent groups?
By combining multiple Enterprise groups under one parent group, those standalone groups now become subgroups. Any users, notifications, settings, rules, etc. created at the parent group level can apply to all (or some) subgroups. This applies to all (or some) locations that exist in each of those subgroups.
Parent groups allow another level of organization and location management.
What is a use case for parent groups?
Kelly’s restaurants have been doing well lately and she decides to open three more locations in Chicago. Her Chicago employees work at each Chicago location as business needs demand, and her existing Minneapolis employees continue to work at each Minneapolis location as business needs demand. The Minneapolis employees do not work at any Chicago locations, and vice versa.
To keep the business organized, Kelly puts her three Chicago locations in their own Chicago standalone group. However, as the owner, she only wants one user profile for herself that will work at all six locations between both Standalone Groups.
To accomplish this, Kelly merges the standalone groups and creates a parent group. The Minneapolis and Chicago groups are now individual subgroups of this parent group. All Minneapolis locations remain in the Minneapolis group and all Chicago locations remain in the Chicago group.
This allows Kelly to create herself one user at the parent group level which will apply to both subgroups and all locations within each child group while simultaneously ensuring the Minneapolis employee access remains within the Minneapolis group and the Chicago employee access remains within the Chicago group.
Note: The above use-case is surrounding Users, specifically, but the same logic can be applied to other features.
Example: Kelly wants to be notified of system events for the whole Enterprise but does not want Minneapolis employees receiving notifications for Chicago locations & vice versa. Therefore, Kelly creates one parent group notification for system events and enrolls only herself as the recipient; she then goes to the Minneapolis child group and creates another system event notification and only enrolls her Minneapolis employees as recipients, then navigates to the Chicago child group and repeats the process.
This keeps Kelly informed of all locations while ensuring her employees are only receiving notifications relevant to their working locations.