| Info |
|---|
| 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! |
| Expand |
|---|
The list of contacts that should be accessible by the new role is organized in the following hierarchy: |
 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
|
| 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... 
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... 
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 |
|---|
| 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
|
|