RX 24 - Volunteer Onboarding - Dotting Is and Crossing Ts - Derek Mangrum
Transcribed Content
So let's give a warm welcome to Derek Mangram, and we're going be talking about volunteer onboarding, dotting the i's, and crossing the t's. All right. Thank you, everyone. I appreciate you guys being here, and I hope this session provides some value for you. My presentation today, I'm just gonna be highlighting how we at Central Christian Church use connection requests with connection request activities and then simple triggered workflows to move a volunteer through our clearing process.
I'll also be showing some custom UI that we built on the connection request page to just be able to quickly and easily see where a person is in that process. But before we get going, I do wanna introduce myself. My name is Derek Mangram. I'm the systems administrator at Central Christian Church here in Arizona. I'm a husband, twenty seven years.
That's my wife and two boys there. And there's my email address. If you are interested in needing to contact me, please please feel free to do so. What else? That's it.
Okay. Yeah. My two sons. I was gonna give you a little info about them. The older one's 20.
He's in Nashville right now doing an internship for audio engineering. And my younger son is 16, just started junior year, so pretty proud of them. Anyway, that's not what we're here for. So like all of us, Central, we have a lot of requirements that people have to meet before they're able to volunteer on our ministries, and different ministries have different requirements. We have a core list of items that every person has to go through, and then depending on the ministry, there may be additional requirements that are needed.
Each of these items also are usually handled and processed by different people or different groups within the church. The ministry interview, for example, background checks, different trainings, or processing references, these are all handled by different people throughout the clearing process. So what I'm hoping to show today is how we're able to keep up on those things and know where we are in each step of that process for a connection request for a new prospective volunteer. As mentioned, we do have some core requirements. So you can see here our common requirements.
We have an application everyone fills out, a background check they do, a ministry interview for the ministry they're interested in volunteering with, And then we wanna obviously make sure we get a good rock profile picture for their volunteer badge that we print out. And then for specific ministries, there may be things like minors training or mandated reporting training if they're gonna be dealing with our youth. And then also some will require references, and others ministries may not. And, again, you know, each of these volunteers, they're guided through these steps by potentially different people on staff or people leading the ministry, again, that they're interested in. And then once they've cleared all of these items, then they are obviously cleared to volunteer, placed on a volunteer team, and then we're ready to go.
So, generally, it says when a person wants to volunteer at Central, the process obviously starts with a connection request. And this is just kind of a a picture of, you know, part of that that page on our website that shows the opportunities that are available. So they'll just they'll pick an area of interest, and they'll apply to volunteer for that ministry. And then that will create a connection request, and it kicks off our process. When a new connection request is created, it will trigger a first an initial workflow.
And that workflow will have a look at the person's record in Rock to see where they're at and what steps of ours may have already been completed. So if this if this person, for example, if they're already volunteering and they're just interested in a new ministry area, then they may already have most, if not all, of our steps and requirements already taken care of. And then once that initial check is done, the process for clearing the person to volunteer then begins. Each step is worked as needed until the person's cleared, they're ready to go. So we're going to take a quick look at that first workflow that's initiated with a new connection request.
This is going to be a very high level look. I'm not going to be looking at the actual workflow detail itself, but I will have more of those details in my takeaways for this session. And then always, again, you can contact me, my email address. I'm in Rocket Chat, things of that nature. Please feel free to come up to me after, whatever, and contact me.
I love to talk about this and would be happy to discuss it more with you. So this is just kind of the first little snapshot of the first activity in that initial workflow. And it looks like it's doing a lot, but it's not really. Again, as I mentioned, some people may submit a connection request for a new area of ministry after they've already been volunteering. So they they may have these requirements already completed.
And this is kind of where we check for that. If you're not too familiar with workflows, again, this looks like a lot, but it's not a lot, really. It just goes into the person's profile and just checks where we register their completion of all these steps to see do they already have that step completed or not. So we're just going and getting their data right here. And it just checks, for example, to see do they already have an application on file?
Do they already have a valid background check on file? Things of that nature. It then will notify some people via email that the new check connection request is in the system so then they can go get and start processing their pieces that they are in charge of. These are the next few activities in that workflow. And again, you'll see that first one goes and gets the data.
And then each of these activities is just named evaluate. So it's just looking at each of those items. And if they already had it have it, then it will let the connection request know via a connection request activity that, hey, this step's already completed. Otherwise, it'll fire off a workflow to begin that step of the process. And so, again, it just kinda steps through them and then completes the ones that are completed, starts the ones that need to be started.
So this is what a connection request might look like in our system. Here's an example. So here at the bottom, you can see these are the activities that we use to kind and drive this. These have been added. And then here is what I just I call the bubbles.
It's just a user interface that gives us an easy to read legend as to where this person is in the process. So each bubble has three possible colors. Gray just means that that step has not yet been started. Blue means that this step is in process but not yet complete, obviously. And then green means that the step has been completed.
So by pulling up a connection request, you can just instantly see what's going on or not going on with this person in our process. The bubbles just read the activities, basically activity titles, to determine their color. So excuse me. So we use again, we use connection request activities to manage initiating, documenting, and completing each step within this process. Most of these activities will trim will trigger a simple workflow.
For example, the application requested activity will trigger a workflow that sends the person a link to our volunteer application. It'll let them fill that application out and then deliver that application to who needs to see it for review and then eventual attachment to their person profile. There are other, you know, dot dot dot requested activities, and they each, again, just trigger their own simple workflow that largely does the same thing. It just each one begins that process for that particular piece of the puzzle. We also have some not required oh, sorry.
We also have some not required activities, and, we use those if, for example, the ministry that they are looking to volunteer for just doesn't require that piece of the puzzle. Then we can just put that activity in, and that'll let the connection request know that, hey. That piece is already taken care of because it's not needed. Okay. Here are just gonna look at a couple examples of these workflows that are triggered by these connection request activities.
And, again, most of them are really simple. This is the ministry interview requested workflow. And, basically, this workflow just says, hey. Can you get a ministry interview for this person? I mean, it literally doesn't do much more than that.
It gets the requester and the connector, if there is one, from the connection request, and then it sends an email to the connector or our involvement team if there is no connector. And the email just, again, asks them to get the ministry interview done. And that's all it does. And then it's just up to them to process to, you know, execute that process, connect with them, actually do the ministry interview, and then report back into the connection request that that's completed via the ministry interview complete connection request activity. So this is an example just to look at another one of the miners training requested workflow.
So that miners training requested activity would trigger this workflow. This will this will go and check the person's attribute again even though we also did that in that initial workflow. And the idea is that they may have done it between when the connection request was started and this step was triggered. So we just go and double check that so that they don't, get asked to do something they may have already done in the interim there. So, again, if it's on file, then it just instantly will, you know, do a ministry a minor training complete activity back into the connection request.
Otherwise, it'll just trigger off that process so that they can go and get that training done. As the various steps are started, worked, and completed, the bubbles will change color on their connection rest request page just reflecting, you know, what's done. And then hopefully, eventually, as you can see here, all the bubbles are green, and at that point, we know they've completed all the required steps, and then the connector is ready to connect them and get them plugged into a serving team, and they are off and running. And this took super, super no time at all. I'm done with kind of the presentation.
Again, this is supposed to be kind of a high level thing. If you are interested in seeing anything in more detail, obviously, we can try and look at that. If you have any questions, I'm happy to answer those.