Emergency response system setup on luminis
Hello Guys,
Thank you very much for your help. The response to my previous question about the webserver tuneup was tremendous. I didn't expect almost 200 reads and 6 suggestions. Thank you again.
I have another question for you guys - let me know what you think and how you would implement this. Our CIO wants to develop a system on the luminis portal wherefrom he can collect all the information (such as their current email address, residential address, phone number/s, cell phone, IM etc.,) from students, faculty and staff and use them as an emergency contact information. He also wants to have an emergency response team formed who can then have an efficient way of utilizing this information and contact everyone on campus - if need arises.
I would believe that some of you guys are also going through the same process. Would you guys be kind enough to throw some light on this and let me know what procedure/s you guys are adopting to get this entire process done?
As soon as we get our procedure defined, i will post it on here. Remember the important steps involved are:
1) Collect all the emergency information via Luminis portal.
2) Save them to a database (in our case, its oracle)
3) Have a method to contact all the users in this database in case of emergency (i am considering more than sending an email to their current email address - Lets face it not many students check their campus email anyway or incase of emergency an email is the last thing a student would think to check - this is debatable and its my personal opinion, correct me if i am wrong)
4)I was more counting on sending an SMS/text message to their cell phone (since calling all these number in an emergency is out of question - due to the time it takes to call all the students on campus etc.,)
Let me know what your thoughts are guys..
[NOTE: We donot have banner yet on our campus but we are going towards that goal. I hope that we have it by next year]
- ask0500's blog
- Login or register to post comments
Hack Your Knowledge
Recent blog posts
- Luminis IV GCF Single Sign On with OSX=Failure PC=Working
- Cisco 4710 - Load Balancer
- First CPIP - ERROR
- Luminis Developer Job Available w/ Stable Organization
- Luminus Developer Job
- SSO to SSB mixed content error in IE
- Avoid email sending when add or delete user from group
- Luminis components
- Luminis 4 & Groupwise 7
- Luminis Developer Needed for Position w/ Stable Organization
Developer Links
Poll
- Login or register to post comments
- Older polls
Syndicate
Comments
Banner general person stores
Banner general person stores your contact information, multiple addresses and your emergency contact information. This is accessed through SSB that can be integrated (somewhat) into the portal.
Cheers
Dave Wolowicz
We use pushed fragments for this collection
Last year, and probably this coming year, we pushed out a high precedence fragment to all of the students. This fragment contained a tab with a single "update/verify your contact information" channel. The original reason for doing this was that we were pulling the phones out of dorm rooms and going back to community phones per floor/apartment.
The main functionality behind it was a managed role. All the students were given a role for address verification. Then, when the users logged in, they were presented with this as the initial tab (unless they had a different default tab already set). After completing the application, the role was removed which fired a person event. The next time the student logged in, they would be back to the normal layout. We also added a channel to the student tab so that they could update the data whenever they wanted.
It worked fairly well with somewhere around 80-85% completion within the first few days. We pulled the role out after 2 weeks figuring that the people that didn't complete it by then probably never would.
All of the data is stored in the Oracle database and is accessible from the regular person forms in banner. We did take some care in ensuring that this data was not spread around since it contained cell phone numbers and such.
So, that covers 1 and 2. As for 3 and 4, we are still looking. I think email will be one primary mechanism since it is "easy" and "free". We are also looking into SMS by way of an aggregator. Thought of doing it ourselves or sending it to the email-to-SMS gateways, but there is the strong chance that the messages would be severely delayed.
Hope that gives you some idea.
Dallas