Expand

title	Want to get up-to-speed? Expand this section...

Request

(What the customer is looking to accomplish/do?)

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 21 Jul 2020 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.

Initial Thoughts

Everbridge sounds like the most logical solution for two main reasons, among others—
1. We already provide certain areas of the University to execute a non-emergency notification to limited population
2. 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

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 approval/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. one Work Org number is associated with one Department)

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	P recise 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	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)
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

Versions Compared

Old Version 4

New Version Current

Key

Request

Initial Thoughts

1 Contacts Hierarchy

2 Lack of Unique Unit:Department Relationship

3 Subset of Unit:Department

4 Contacts with Missing Unit Values

5 Everbridge/System Limitations for Setting up Rule

1 Fit the Requirement to the Product

Conclusion: Meh.... Do-able. NOT Recommended...

2 Compromise, with a (Grave) Cost

Conclusion: Better. However,...

3 No Compromise

Conclusion: Best and I Recommend we take this approach.

Page Comparison

Versions Compared

Old Version 4

New Version Current

Key

Request

Initial Thoughts

1 Contacts Hierarchy

2 Lack of Unique Unit:Department Relationship

3 Subset of Unit:Department

4 Contacts with Missing Unit Values

5 Everbridge/System Limitations for Setting up Rule

1 Fit the Requirement to the Product

Conclusion: Meh.... Do-able. NOT Recommended...

2 Compromise, with a (Grave) Cost

Conclusion: Better. However,...

3 No Compromise

Conclusion: Best and I Recommend we take this approach.