Role Scope
Overview
If Roles define "what" I can do in BluSKY, Role Scope determines "where" the permissions are applicable. Combined together Roles and Role Scope can be used to give specific permission for almost any possible situation.
Types of Role Scope
There are currently seven different kinds of Role Scope. It is important to resist the urge to think of the different scopes as hierarchical. In some cases this is true but in general it makes understanding Role Scope more difficult.
- Global Company: A Global Company can be thought of as a “legal entity”. It isn’t a physical location where an office exists, but rather the Corporation or legal company itself. If a person is given a Role that is scoped to the Global Company level, they will have the permissions granted through their Role across any Facility where that company has an instance, regardless of the Access Control Systems (ACS) in which the “office” is located and regardless of whether the instance is an occupancy or not. A Global Company could be a Bank, that has many locations across the globe. Giving Global Company Scope to a user would allow them to manage all of their subsequent locations.
- Integrator: This is a Security Integrator who sells and installs Access Control Systems. Because Integrators sell and install systems, they must exist before an ACS is created. Integrators typically also have a physical address that is different from any of their installed ACS. Permissions will be effective for only one single Integrator instance. This does not automatically include access to all of the Integrator’s customers, installed systems, etc.
- Note: This Scope should only be given to an Integrator and serves no purpose to end-users.
- Customer: This is an instance of a company that is purchasing one or more Access Control Systems. Since, Customers can purchase multiple ACS, a Customer never belongs to a single System. Customers may also have a physical address that is different from the ACS that they own, this is very common for large national or regional companies. Permissions will be granted to a single Customer instance, essentially the people who work in the workplace. This does not automatically include the ability to perform activities on any of the Systems owned by the Customer, nor does it give the ability to perform activities on any Occupants, since the Customer employee is not granted any permissions to the Systems in which an Occupant resides.
- Occupant: This is an instance of a company that resides within a Facility (building) that is controlled by an Access Control System. An Occupant always belongs to an ACS because they are physically located within the facility and never have a physical address that is different from the System's physical address. Permissions will be granted ONLY for one single Occupancy within a single Facility - its people, Roles, Access Levels, etc. Occupancy Scope is the most common Role Scope as it helps maintain a level of privacy in multi-tenant Facilities.
- Vendor: This is an instance of a company that acts as a vendor to the Occupants within an Access Control System. Although their physical location may be different from the ACS, the location at which they perform or deliver their services is almost always the same physical location as the ACS itself. For example, a Role that is scoped to a Vendor could be used to allow a person to manage the access rights of Vendor's employees.
- System: This is a single Access Control System. This Role Scope is most commonly used to grant the permissions to run a System or Facility as a whole. A security officer, for instance, would need to the ability to view personnel records of all of the Occupancies within the System they are responsible for protecting.
- System Group: This is a collection of ACS which are logically grouped together. It could be all the systems in a particular region, all the systems in a given city, or all the systems managed by a particular person. Any logical grouping that makes sense to the end-user. Some of our Integrators choose to segment the Systems they manage to different personnel. We wrote a great article on how to Create a Technician Role that may be useful.
Example
Suppose we create a Role that has the permissions to run reports. If we take the Role and scope it to a single Occupancy we will see only results for that Occupancy. Now if we were to take the exact same Role and scope it the System, we should see results from all of the Occupancies of the System. Keep in mind, even if you have System scope you can still limit the Report through the Report interface.