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