Facilities would like to notify (initially via email only) a subset (as identified by FO) of the University population regarding COVID-19 positive location(s) as they are identified. Initial meeting was held on to discuss what ITS has as options — the focal point of discussion being, if Everbridge—which is the University's primary system that is used for all (emergency) notifications.
Everbridge sounds like the most logical solution for two main reasons, among others—
We already provide certain areas of the University to execute a non-emergency notification to limited population
We can build rules, within Everbridge Administration UI, to limit the population that will be exposed to given role
This COMPLETELY ensures that a notification executed by a specific/setup role will ONLY reach the population that they have access to and not the entire user-base within Everbridge
In other words, say we have total user-base of 50K within Everbridge; the requirement (derived from the rule(s), provided by the customer) calls for access to 150 of those users. The role can be setup as such, that when the notification is triggered by this new role, the most people that the notification would reach is no more than 150
Of course, provided Note: All such requests of using the Everbridge system, regardless of which department is requesting, has been & is subject to Office of Emergency Management's approvalfor the usage of the Everbridge system.
...
/authorization.
Road-blocks
Potential Solutions
Info
title
NOTE
Most, if not all, of the following, by themselves is NOT a road-block...
...
However, taking (or treating) them as a whole, makes it a road-block!
1 Contacts Hierarchy
Expand
The list of contacts that should be accessible by the new role is organized in the following hierarchy:
Department
Unit
2 Lack of Unique Unit:Department Relationship
Expand
There are contacts that are from different Units, belonging to the same department (logically (but unfortunately, for this task) this of course makes sense!)
by department and by unit (in terms of grouping)... which is not really a problem, however.... even within the department,
(However, at first glance at least, it seems that another grouping that is part of this contact list is by "Work Org" — which seems to be 1:1 (i.e. oneWork Org number is associated with oneDepartment)
Unfortunately, though, we do not feed that information for a given user into Everbridge.
3 Subset of Unit:Department
Expand
Even if Unit : Department were to be 1:1, only identified individuals are to be part of the contacts. In other words, consider the following:
UNIT = “ATHLETICS” and DEPARTMENT = “Athletics Facilities Ops”
In this example, this yields: 9 people in Everbridge…. Versus 4 people that are identified as being included in the population
4 Contacts with Missing Unit Values
Expand
There are contacts that do not have a value for "Unit" in Everbridge
5 Everbridge/System Limitations for Setting up Rule
Expand
Saved the best for last:
When setting up rule(s), Everbridge does not allow
the usage of "AND" search logic, along with (a combination of) "OR"s search logic
having a field filter for blanks/nulls
All rules implicitly build upon "AND" search logic... Consider the following rule setup, to get a better idea—
Setting up a rule where the criteria are:
UConn Department = Utility Plant Operations
UConn Unit = EXVP ADMIN & CFO
produces exactly 2 contacts...
Image Modified
Which is PERFECT! That's how many should be part of the notification team, per the contact list.
However, if we are to add another Unit as in UConn Unit = FACILITIES OPERATION, it will produce a grand total of ZERO contacts...
Image Modified
This is because Everbridge is aggregating records by:
UConn Department = Utility Plant Operations AND
UConn Unit = EXVP ADMIN & CFO AND
UConn Unit = FACILITIES OPERATION
Which, obviously, makes sense as to why we don't see any contacts being pulled...
...
Info
title
NOTE
The solutions are to be discussed with other technical colleagues first.
As such, they should not be shared until an appropriate solution has been selected.
1 Fit the Requirement to the Product
Expand
Setup each and every Department:Unit combination within Everbridge
Pros
Cons
Setup will be within Everbridge
Limited as to how optimally this can be done, due to system limitations (See 3, 4, and 5, above)
We will still be able to limit the overall number of users exposed
No precise control over the number of users exposed
No way to capture individuals who do not have a value for UConn Unit
VERY time consuming to setup (by IT)
Conclusion: Meh.... Do-able. NOT Recommended...
This will expose way more records than 466 identified by the customers
Setting up rules will be messy at best
Just NOT efficient way of going about this, at all!
2 Compromise, with a (Grave) Cost
Expand
Setup the new role in Everbridge, such that it has access to ALL users. The individuals assigned to the new role within Everbridge can build/hand-craft a group membership within Everbridge, as desired
Pros
Cons
Setup will be within Everbridge
Limited as to how optimally this can be done, due to system limitations (See 3, 4, and 5, above)
Still be able to limit the overall number of users exposed
Precise control over the number of users, so long as
the Group is built correctly AND
when the notification is triggered by the new role, the target population is set correctly
Still be able to limit the overall number of users exposed
Has a potential of sending a notification to the entire user-base
No IT involvement, outside of creating the role and assigning an empty group which can be populated by the new role
Has a potential of sending a notification to the entire user-base
Each of the 466 contacts will need to be manually added by the designated role admins
Contacts without UConn Unit can now be added (compared to 1 above)
Each of the 466 contacts will need to be manually added by the designated role admins
Can maintain group membership at whim
Conclusion: Better. However,...
This will expose ALL records. There is a potential of every user receiving a notification — I would tread lightly!
3
...
No Compromise
Expand
Modify our Everbridge feed-file processor.
Everbridge allows for up-to 4 custom fields (with their associated values) — i.e. Custom Field 1 Custom Value 1, Custom Field 2 Custom Value 2, etc.
We are using 3 of these for the following purposes:
Custom Field 1
Custom Value 1
Custom Field 2
Custom Value 2
Custom Field 3
Custom Value 3
Usage
Primary Campus Location
example: Storrs
UConn Unit
example: Nursing
UConn Department
example: Nursing Instruct and Research
Since there is an "open" custom mapping we can take advantage of, I recommend we do... as such, the above table would look as follows—
Custom Field 1
Custom Value 1
Custom Field 2
Custom Value 2
Custom Field 3
Custom Value 3
Custom Field 4
Custom Value 4
Usage
Primary Campus Location
example: Storrs
UConn Unit
example: Nursing
UConn Department
example: Nursing Instruct and Research
FONTeam
<arbitrary, yet unique val/str here>
Here are high-level steps that need to happen, if this approach is taken:
Decide on what the value will be for "Custom Value 4"
Modify the code to include "Custom Field 4" and "Custom Value 4" in the header.
Extract the NetIDs (out of the Excel file that has been sent), store it in e.g. FONTeam.txt
Within the feed file processor, while iterating over the LDAP results:
if the NetID of the record being processed is part of the FONTeam.txt ===> assign the Custom Value 4; else ===> assign ""
Prior to manually running load for Everbridge:
Backup (on Q Drive) the entire user-base of Everbridge
Execute the load; check Everbridge
Spot-check records and ensure the record integrity is still intact
The load log will also tell you a lot, if things went side-ways
If all is as expected, create a "Dynamic Rule" and assign it to the new role
Overall, this entire effort should take approx. 1 hour.
Pros
Cons
Full control of inclusion / exclusion of records
Setup will be outside of Everbridge
Full IT involvement: initially and on-going group membership maintenance
Full IT involvement: initially and on-going group membership maintenance
No record filtering limitations or limitations due to contacts without UConn Unit etc.
Customer cannot maintain group membership at whim
No potential of All UConn Alert!
Conclusion: Best and I Recommend we take this approach.
This will expose no more than the number of contacts as requested by the customer
Sure, the IT involvement will be there, but the up-side outweighs that, in my humble opinion
Road-blocks
Potential Solutions
