This Is How Connect Bridge Can Help: Emergency Response Solution Design with Dynamics and SharePoint

You must store any personal data entered in a SaaS application on storage that is physically located in the country (or an approved territory) to comply with data residency laws. You can achieve this in two steps:

1. When data is entered in the SaaS application, you check if it is personal data, meaning that information in that data is sufficient to identify a person. If it is, the data is transferred to a database located in the country.
2. Data is anonymized, and a reference key is returned to the application for storage in its own database.

We envisioned the Emergency Response solution around two systems, Dynamics 365 and SharePoint. For this reason, we also divided its data model between the two applications.

We designed data sync workflows based on Connect Bridge. At a glance, the Data Model for the solution is as in the following diagram.

An Emergency Response solution using multiple platforms and technologies, including Dynamics 365, SharePoint, Azure IoT (Internet of Things), Bing Maps, Cognitive Services, and Bot Framework, all glued together with Connect Bridge

Connect Bridge would handle the workflow for transferring the necessary information from entities in Dynamics 365 to lists in SharePoint. The Dynamics 365 to SharePoint connector takes care of data sync for:

• Schools: The School list contains a copy of all the schools where an emergency event has occurred at least once. Data is copied from Dynamics 365 to SharePoint when an emergency event occurs. This is the triggering event of the entire emergency response process, and it is a manual process typically initiated by the School Director.
• Students: The Students list contains a copy of students’ names and contact information for those currently in the school affected by the emergency. Contact information is stored as a copy (as opposite to being synchronized as a reference to the equivalent record in Dynamics 365) for e-discovery purposes: if a legal inquiry is conducted to the school to investigate how and when students were contacted during a response to an emergency, the full history of contact details is preserved, rather than having only the latest information available in the CRM system.
• Emergency Events: This is the list that contains descriptive information of an emergency event: name and description, start and end date, status and when the event itself was created, and by whom. On creation of a new item in this list, a workflow is triggered for initiating the generation of the dashboard, implying the copying of relevant data from Dynamics 365 into SharePoint.
• Roster: The Roster list represents the information displayed on the screen in the Emergency Response dashboard. There is an item for each emergency event that occurs in a school, and it contains a reference to a list of all the students currently in the school, for which the safety status must be assessed.
• Tracking: The current status and location of a Student is tracked in the Tracking list. An initial assessment is automated by implementing location tracking by means of GPS devices connected to the Azure IoT Hub. On onboarding of students at the beginning of the program, each student is assigned a keyring containing a GPS unit that sends location data to the Azure IoT Hub only when the School Director raises an event.
• Communication: The Communication list contains all the items of conversation that occurred between school operators (and the bot) and students over multiple channels: voice calls, SMS, emails, Skype, and Facebook Messenger.

The Emergency Response dashboard generated for that event is accessible by all school operators via the SharePoint intranet site of the organization. This dashboard is available immediately as soon as the integration workflow in Connect Bridge completes; this normally takes less than a minute. The dashboard contains information about the event just created and a list of all the students enrolled in a program delivered by the school at that time. For each student, their safety status is visualized (Unknown, Safe, Danger), along with their last detected location. The success of communication between the school and the student and assumption around their location contribute to determining the safety status of each student.

Some level of automation is introduced at the initial assessment due to the high number of students that may be affected. Nonetheless, a proper manual assessment of the safety of students is then scrupulously undertaken by school operators and reflected in the dashboard.

Once the status of all the students has been assessed and the emergency event is completed, one final step is taken. All data is frozen in SharePoint creating a record of the dashboard, all its contact details, status tracking changes and communication. This allows a potential e-discovery process in the future, for legal reasons, should the need arise.

In conclusion, SharePoint not only provides the portal engine for displaying the Emergency Response dashboard but also represents the record management system for archiving legal data about the success of the emergency response.

As mentioned, data about schools and students is copied from Dynamics 365 to SharePoint in the context of a response to a new emergency event. This process is handled by Connect Bridge.

The Connect Bridge engine provides a highly available and scalable solution for technology-agnostic integration among systems. Personal note here: I have enjoyed designing and building the Emergency Response solution, but I really hope I will never use it! However, if there is a situation that requires a prompt response, this tool must be immediately available and able to provide a sleek response. Hence the decision of adopting cloud-based applications, where availability and scalability is not – or should not – be an issue.

The logical workflow, consisting of integration and business tasks, can be summarised by the following steps:

1. When a new emergency event is created, contact information for the affected school and relevant students is copied from the corresponding entities in Dynamics 365 to lists in SharePoint. The relevancy of students is determined by whether they are in the school at that moment. This is inferred from whether they are enrolled in a program delivered by the school on that week.
2. A roster of the students in the affected school is generated in SharePoint and the safety status of each student is assessed initially by a second workflow.
3. Based on the last detected location of the student and their distance from the location of the emergency event, an assumption of each student's safety is made by checking if the student is more than 100 meters away from the point of accident.
4. Communication with the student is initiated by SMS asking if they are OK; the reply by the student is handled by a bot that interprets the message and determines their status.

Proposed Flowchart for Emergency Procedures

Software can help in emergency response if you plan ahead and keep in mind the need for availability and scalability.

Integrating multiple software and using middleware to glue it all together can make interesting features available within a reasonable timeframe.

Connect Bridge is a good example of a middleware solution that fits perfectly into this scenario. As it is a technology-agnostic system, you don't need to worry about future upgrades and scalability.