RX 24 - All Present and Accounted For - NewSpring Church Kids Ministry Digital Evacuation Toolbox

Transcribed Content

Okay. Welcome. I'm trying to wake you up a little. I don't know if it's gonna work. We're almost there. Just hang in there. You're doing so good. I'm proud of you for being here sitting in these chairs, not laying down somewhere. Just keep it going. You'll be glad later. You won't feel that guilt of having copped out right before the end. Alright. Please welcome Brian Calwat, and we're gonna talk about all present and accounted for, how to know you've got all those kids when you do an evacuation. Alright. Let's see. It looks like my computer went to sleep, so that's great. Great way to start. Maybe? Oh, maybe? Let's see. Hey. We got it. 03:10 on a Thursday afternoon. I know what everyone wants to talk about is evacuating a building full of kids. Man, I hope you guys had a great conference. I'm really excited really been excited to be here. This is always one of the highlights of the year for me, just being able to see everybody and reconnect and just learn a lot of new things, but also more than anything, kind of come away inspired and refilled up. I know that that's been true for me for this year. So hopefully, that's been the case for you as well. So as I was kind of thinking about what over the past year would be something that could be valuable for people for us to share as far as things we've been working on at NewSpring sorry, I should have started with that. My name is Brian Kalwat. I'm from NewSpring Church. I've been on staff since 2013 there as a designer and developer. And today, I'm gonna share about a project that we have had the opportunity to work with our Kidspring and safety teams over the past, or I I guess probably like six or seven months ago is when we finished it up. But basically, our Kidspring and safety teams have had, an existing, a preexisting, like, logistical plan as far as what we do in in in the event of needing to evacuate. And so what we were doing is partnering with them to figure out how could we create a digital tool around rock to be able to supplement those preexisting logistical plans. So that's what this toolbox is. So let's talk about why this is important. In brief, safety and trust, I feel like, kind of summarize it. I believe the safety of our kids and the trust of those who love them is at stake when it comes to being prepared for a situation like this. Our kids are some of the most vulnerable of our church family, and so I I believe that we must do everything we can to equip and protect them both physically and spiritually. So this project specifically was unique in that it's something that I hope we never have to use. So it was a lot of conversation around how it works and what it should look like and just a good amount of time was spent putting into it. But hopefully, no one will ever have to see it and will never have to use it, and that'll be great. And also, think from a week to week standpoint, I would say that being familiar with and practicing our evacuation process gives us a confidence that is felt by parents and caretakers who trust us with the safety of their kids every week. I feel like this is a product that comes from being prepared in general. You just walk with a different walk and have a different tone and can speak confidently when you're prepared and know what the plan would be if a circumstance like something that needed an evacuation were to come up. So yeah, that's kind of the why. So you might be asking, why digital? So couldn't we just print off rosters for the kids that are checked into each room and then distribute those? And then if we needed to leave the building, everyone could just grab their piece of paper and take it with them and cross their names off. And that's definitely something that could work and we actually have done that in the past. It's been a while since we've done that, but it was definitely our first step to having something. But that also assumes that the situation where you would potentially need to evacuate the building would happen after you've printed all of those and distributed them, which may not always be the case. And so in emergency situation, we don't want this to be us, like trying to like, quick hurry, we've got to get all the things printed. And then also, this kind of goes outside of this. But in general, the minute you put data on paper, it's baked in time. And so we all I think we all know that kids sometimes check-in late or they have to leave a room for some reason or they get halfway to their room and they decide, nope, not today. I'm going with you to big service or whatever. And so keeping the data in the digital realm gives us the ability to retain accuracy and make changes to things as situations like that flux. And so it gives us the ability to see real time and make changes as situations change. So let's talk about the actual problem that we were trying to solve. So in the event of an emergency that requires an evacuation, how can we know that, a, every child within our care is safe and b, has been reunited with their family? So how do we know they're safe, and how do we know they've been reunited with their family? For the last part, how do they been reunited with their family? As you guys probably know, the check-in tool within ROCK has the ability to check out as well. So when a parent comes to the room to pick up their kid, we check their code with their kid's code to make sure that we're sending them with the right person home and check them out. And then we know because they're checked out that responsibility. They've been reunited with their family and their responsibility going forward. So from a data standpoint, we have a way to track that data and know for sure that that has happened. What we don't have a way to, at least initially, have a way to record and keep track of the data is how do we know that every kid within our care is safe? So the way that we kind of thought about and handled this is we added a new attribute on the attendance entity within Rock called isMarkedSafe. And so we added it to the attendance entity specifically because the attendance entity represents a single instance of attendance for a unique person to a unique location during a unique schedule. So do we know that this kid who was checked into this location during this service is safe? If you aren't familiar with the term entity, basically that's just referring to any object within Rock. So schedules, groups, content items, transactions, those are all entities. And if you want to learn more about all of the entities that exist within Rock, under power tools in your system, there's a thing called the model map, which has a full exhaustive list of all of the entities that are available and their various properties. And you can learn a ton by looking at that. So yeah, we added this attribute to the attendance entity. You can add a custom attribute to any entity type within ROC. So to do this, you would go to admin tools, system settings, and entity attributes. This is what that'll look like when you go there. And so then you would select the entity type at the top there. So we selected the attendance entity and then click the plus button to add the entity. You guys are probably familiar with this. So we just added the attribute called isMarkSafe and made it a field type of Boolean because isMarkSafe is a true false value that we're trying to keep track of. So yeah, now that we've got a place to store all of the data that we're trying to keep track of, let's talk about the timeline of how this would all happen in the event of needing to evacuate a building. So first off, the evacuation process is initiated. That would happen by someone from the local safety team at one of our campuses. Once that happens, an SMS message is sent to all of our checked in volunteers at that campus that day. The reason why we decided to rely on SMS text and volunteers' phone numbers is because we while we have tablets in each room that have Check-in Manager on them, our Wi Fi network doesn't reach like beyond the the at least far beyond the walls of our building. And so to in order to be able to like control things and mark kids safe and check kids out at the place where they all rally together outside the building, we needed to be able to have connection. So once the text goes out, the rooms were already evacuated to our rally points. So outside of each of our campuses in our parking lot, we've got a couple of signs that have magnets on them. And then these placards that also have magnets on them so we can just take them out with us and stick them to the poles. And so basically each area within our Kids' Spring Hallway has its own kind of parking space to be able to corral and group the kids together so that they can we can know everyone's in one place. And then also the parents would know to come to these signs to be able to pick up their kid once everyone's outside. So once everyone's rallied together at the rally points, at that point volunteers begin to mark their kids as safe so that we can quickly know if there's anyone that potentially may have gotten lost or disconnected from the group in the process of leaving the building. And so that's the main value of being able to have this intermediate step is to be able to identify if there's anyone that we need to go looking for or locate. And then once everyone's marked safe, they can begin checking kids out and returning them to their families and caretakers. So next, I'll just do a high level overview of the various components that are a part of this process. There's four main components. There are some more technical aspects of this that I'm not gonna go like super deep in the weeds on just because I think they are things that are specific to like our our Rock instance specifically, things like group types, group structure. So it's not gonna be like plug and play to anyone's instance. So I'm not gonna go into like the actual like SQL queries and things like that that are behind it. This is more this whole presentation is more from what I'm hoping that you'll take from it is just like a conceptual overview of like, this something like this could exist. And if nothing else, like to just like give you guys a talking point to have a conversation with your church back home with your safety team or your kids ministry team of like, in the event of emergency, what is our plan? And what could it look like? And how could we use Rock to supplement that? So these are the four pieces of it. There's two workflows and two pages, which are kind of dashboards for us. So the first workflow, which I alluded to at the beginning of the process, is the evacuation initiation workflow, which a member of our local safety team would be responsible for running that workflow. There's like three options that they would choose and then they hit submit. And then that workflow triggers the SMS send workflow for each checked in volunteer for that day. So the only thing that that workflow does is it sends a text message to the person with a link to the third thing, which is the campus evacuation dashboard. So the campus evacuation dashboard is really simple. Literally, all it does is it's it's built into Check-in Manager, and it takes the campus that's selected, the schedule that's selected, and it shows a list of every room. And then it shows a visual representation of every kid who's checked into that room and their current status. So from a high level view, our campus staff is able to see every single room within our kids ministry and every the status of every single kid within that within those rooms. So from that page, the volunteers themselves have the ability to click into their individual room, which is the evacuation room roster where they're able to see every kid within that room. And it gives them controls to be able to mark the kids as safe and also to be able to check them out. So we'll walk through each of these individually real quick. Just from like a visual standpoint, this is how this is kind of laid out. So there's one evacuation initiation workflow that gets ran, as I previously said, by our safety staff or volunteer. And then that is gonna launch out an individual SMS send workflow for each volunteer that's checked in that day. From there, the text message that gets sent out in those workflows is a link, a personalized link to the yellow Evacuation Campus dashboard. And once they get there, they're able to find their room, click on their room, and that'll take them to the evacuation room roster. So let's talk about the first part. This is the evacuation initiation workflow that our safety team would use to initiate this process. And there's basically three steps. So the first one is basically gives you two options. So they choose the campus that they're going to be evacuating and then mode. So mode where we created as an option at the end of the development of this process. Basically, it gives us the ability to change whether this is an actual emergency or for just testing the system. And so the only thing that that really does is it changes the messaging that gets sent out in the text to make sure that it's super clear to our volunteers that this is just a test. And the reason why is because when we're running tests, there's potentials that, a lot of times when we run tests, we'll do them like Sunday afternoon after services. And so, there's the potential that someone's not at that test but was checked in earlier that day, and they might get a text message. And so having this mode gives us the ability to be super clear that we're just testing it. So yeah, they would choose those two options and hit continue. When they hit continue, there's a a sequel action that calculates the volunteers in our kids groups that were checked in that day. And it makes a list of their their person alias GUIDs which gets passed to the SMS send workflow. So that that SQL runs. And then on the second step, could see it says 87 Kidspring volunteers at the Anderson campus are about to be sent a text. So this is kinda like the intermediate, like, are you sure you wanna do this? Like, because this is about to send a lot of communications out. From there, they can either cancel or hit initiate. And once they hit initiate, there is a action in the background that is the work flow activate Lava command. I don't know if anyone's familiar with that or has used that. But that basically is within a loop for the volunteers that the SQL calculated to fire off an individual workflow for each person. We chose to break out the SMS send function into a separate workflow because in the event that there would be a problem with a specific individual person, like for some reason the communication could get sent or whatever, we didn't want that to, like, stop the rest of the process and prevent any volunteer in the like, beyond that point from getting a message. So that's what it's kind of a, like, a level of redundancy to protect ourselves in the event that maybe there is an issue with data or a phone number or something like that. So by by splitting it into a separate workflow, it gave us the ability to have some extra stability. So yeah. Once they hit initiate evacuation, all of those workflows are activated and the text messages start being sent. So next, we will look at the SMS send workflow. So as I said, one of these gets sent to each volunteer who's checked in that day. And basically with this workflow, there's five attributes. So the ones that are highlighted in blue have their values passed in from the activating workflow, the initiation workflow. So the recipient, which is passed in from the loop, the campus, which the safety volunteer selected in the first step, and then the mode, whether they whether they selected this was an actual emergency or a test. So those get passed in. And then from those values, we are setting the message based on what the mode was, right, which you'll see the difference between those in a minute. And then the short link, which includes an impersonation token for the recipient so that they don't have to log in. They just click the link in their text message, and it takes them right to Check-in Manager. And this, you can see the example of the difference between the text that gets sent out in testing mode versus emergency mode. It's really pretty much the same. It's just we wanted to be abundantly clear in the event of a test that it was just that. Great. So from here, those are the two workflows that are part of this. The next thing I'm going go into is the two pages that we built to go along with this. The two pages are dashboards that we basically use to help staff and volunteers move kids through a list of four statuses, three of which already exist as a part of Rock Core. So these are the four statuses. So we've got en route, not marked safe, marked safe, and checked out. So en route is basically any attendance entity or any kid who has a value for start date time, meaning they were checked in, but doesn't have a value for present date time, meaning they were never actually marked present at a room. Not marked safe has a value of present date time, meaning they actually did make it to the room they were checking into, but either no value or a false value for is marked safe, which is that attribute that we added at the beginning. Mark safe, which would be anyone who has a true value for is marked safe but no end date time, meaning they haven't been yet checked out. And then checked out would be anyone who has a value for end date time. So these two dashboards that I'm about to go through are basically the mechanism that we use to help kids go through these various statuses that we can hopefully get them all to checked out. So to move through these four statuses, there's two single action workflows that we use. And I know that there's a lot of pieces to this, but these are very simple. They're single action. So though there's we basically have a mark as safe workflow and a checkout workflow. So the mark as safe workflow basically takes an attendance identifier and sets the is marked safe attribute value to true if it's false or it sets it to false if it's true. So that's literally all that workflow does. And then the checkout workflow basically does the same thing just for the end date time. So on the dashboards, you'll see some buttons here in a second for marking kids as safe and checking them out. All those buttons are doing are activating these two workflows behind the scenes. And then there is a return URL attribute that takes them back to the dashboard. So they don't actually see this workflow. They just click the button, it runs the workflow, and then sends them right back to the page. All right. So first, we'll go over the campus evacuation dashboard. So it's really simple. This is literally all it is. At the top, can see it's the normal thing you would see for Check-in Manager where you've got your campus. And then we've added a dropdown for schedule. And then below that, we've got a key for our volunteers to be able to tell which status for each kid. So en route, not marked safe, marked safe, and checked out. And then underneath that, we we've got you can see we've got the list of locations. And then under each room or each location, can see a a square which is a visual representation for each kid that is checked into that room, and then it's color coded which status they are. So you can see we've got on on Wonderway 1 and Wonderway 4, we've got all of our kids have been at least marked safe, and a couple of them have already been checked out. Pop's Garage, we've got three that haven't been marked safe yet. And, you know, so very quickly, a campus pastor or campus staff or Kidspring director is able to look down this list and identify if there's any rooms that have red and then can they know who they need to go talk with to help them find whoever might be missing. So from here, there's just the View Roster button which takes you to the fourth part of it which is the evacuation room roster. So this is the main page that our volunteers would use to either mark kids safe or check them out. So there's basically three main parts of this. There is the header. So this is fixed to the top of the page. So as you scroll down the list of kids, this is always visible. So this is helpful because it includes the schedule that you're looking at, the room that you're looking at, and what status you're currently looking at. So even if you scroll down the page a little bit, you don't ever lose context of what the list of kids that you're looking at is being represented by. So that's the header. And then navigation, so volunteers have these two dropdowns where they can quickly transition from one room to another or one status to another between the not marked safe, marked safe, or checked out. And then there's the list of kids. So each kid has a it's kind of washed out. But each kid has their own panel, which just has their name, their check-in code, and then the actions that can be done on them from there. You also have the ability to or they have the ability to click their name, which takes them to the profile that's built into Check-in Manager if they need to see the parent's phone number if we need to contact them for any reason. Maybe, like, the parent doesn't know, like, where to go to pick up their kids or something. They can just tap the name, and that'll take them to the profile that already exists within Check-in Manager to be able to see that. Yeah. And then the actions. So this would be the view for viewing kids that have not yet been marked safe. So you could see up at the top says not marked safe because that's what we're currently looking at. The drop down for status says not marked safe and it shows how many people are currently in this status. And then the list. So each of these buttons here for each kid that says mark safe, all that's gonna do is run that mark safe workflow and then redirect them back to this page immediately. So they don't actually see that workflow. They're just clicking the button and then this page reloads and then they can just go click through each kid as they're marking them safe. So it really works pretty quickly. And then this would be the marked safe status. So now you can see we've got two options. We've got unmark as safe. So that exists in case someone were to accidentally like mark the wrong kid as safe. They have the ability to undo what they just did. And then checkout, which runs the other single action workflow that I talked about previously. So those are the two options there. And then the last page is check out. So this would be a list of kids that have already been checked out. So again, if someone were to accidentally check out the wrong kid for whatever reason, they could go back and click that button. And what it'll do is it's gonna know the value for the end date time on that attendance and the checked out by person alias ID, I think that's right, to basically undo the checkout. So yeah. So those are the the three statuses and all of the different components of it. And that's really all I have. I would love to answer any questions. If anybody has any specific questions.