RX 24 - Equip the Saints for Ministry - Automating Volunteer Access to Rock - Jason Shuman

Transcribed Content

Let's give a nice warm welcome to Jason. Good afternoon. My name is Jason Schuman, and I serve as a digital application specialist with LCBC Church, which basically means that I work with our digital team to build and innovate digital resources for our ministry teams. I'm married to my beautiful wife, Jessica, and we recently were surprised with a blessing and added Belle to our family. So now that you know a little bit about me, you may be curious from the title whether automating Rock Access for volunteers is really such a great idea. Don't worry. You're not the only one asking that question. So what makes automating this process worth the additional risks? Well, I'm glad you asked. We've found several reasons that this is worth additional risk. If we make a quick list I'm sorry. I think I'm going a little fast there. If we make a quick list of these reasons, we want to keep technology out of the way of ministry, making it more of a resource than a barrier. We want to keep our data secure. And we want to create sustainable processes to maintain security roles for our volunteers. So what does that look like for everyday use of rock? First, have you ever noticed that people who are engaged in ministry are often really good at identifying skills and talents in the people around them and then mentoring them and then bringing them alongside them in ministry. When you have multiple locations who are building momentum and equipping people for ministry, it gets a little bit harder to keep after the security roles that go along with that. As they're continuing to build and equip their teams to do the work of ministry, as Paul encourages us to do in Ephesians four twelve, you quickly find that the one piece that are delaying these people from engaging in ministry is their access to data. So this project was birthed from our desire to remove obstacles from people who are on the front lines of ministry. A little selfish note here, it also freed up our team to focus more on building digital resources than on managing security roles in Rock. So as we continue to empower volunteers to do the work of ministry, we were finding it difficult to keep after the process of removing security roles from people who are no longer serving. Whether a location just failed to notify us that the person was stepping out of their role or the person was slowly fading out of their serve opportunity at a rate that they were just not noticed that they weren't serving anymore, we're finding that there were 400 people, 400 plus people, in our basic Rock Access volunteer security role. Now, we knew that there were not 400 people actively in Rock serving on our locations. So we did a little bit of a cleanup project, and we brought that count down by just about 150 people. And we're still working to identify whether the remaining people are all actively serving. And that kind of sparked some of the thought process behind this project. How can we automate rock access in a way that makes our data a little bit more secure? So one of the key ingredients that allows us to make this project possible is the ability to define consistent levels of access for a volunteer. When they need to run digital when they need to run ministry processes and have access to the digital resources. In order to automate a volunteer's access to rock, we first needed to establish a framework that we could work in. A task force was started that contained a member of our team and a representative from each of the ministry teams, and this team's purpose was to determine a level of involvement and access that is appropriate for a volunteer in each ministry team and to create that standard across all of our locations. That means that we needed to define specific data types and tiers of data sensitivity. To provide a brief summary of our data types, we have a total of seven. We have general information, which includes basic person profile information and some attendance data. This level of access would be available to any of the volunteers that are approved to have access to our Rock instance. We have care information, which is generally a useful piece of information when you're in the trenches of ministry. And this includes private prayer requests and connection requests created for pastoral care or for pastoral follow-up. Now, much of this type of data is limited only to our staff members. But we did open up some of this data to volunteers that have been trained to work with our care ministry team. We also have financial data. Now, by default, we're very careful with our people's giving information or with their financial information. So we ended up breaking this category down into two tiers. The first tier includes access to our check scanning software and any giving attributes or financial batch information that can be edited from within that software. The second tier is any remaining giving information. And this information is locked down. We don't even give this to all of our staff members, a few, more than a few, some select staff members. And none of our volunteers would have access to this level of information. We also have our reports and key metrics. We have identified the key metrics that describe whether we are actually being effective in our ministry. And this information is once again locked down to only select staff members and not open to our volunteers. You may be wondering why there's a label up there called confidential information because isn't all of our information in ROC kind of confidential? The question there is what is important for your staff members to know going into situations of ministry? And what is really sensitive information that really doesn't apply to most of your staff. So there's a few note types that we can take very sensitive information, enter that in so that we have a record of it. But it's not actually accessible by most of our staff, and we definitely don't open this up to any of our volunteers. Security information includes information that is security flags or reports that we've designed specifically for our security team. The document types that contain our background checks are also part of this category. So by classifying our data into these types, we were able to pare down the number of security roles we needed to provide volunteers with access to the ministry processes that they're participating in. As we continue to empower our volunteers in ministry, we had created a maze of security roles that honestly we couldn't keep up with, let alone even remember what all of them were. So as we started paring this down, we were able to bring this to six levels of access that a volunteer could have within our system. Starting, we had a base access security role. This would give access to general information, whether it's profile information or basic information that could be used for more of an Office support role. Any volunteer that has access to our Rock instance would start with this access. And then anything else would be in addition to having this security role. We have a volunteer onboarding process that we call VOP. So this level of access would give the volunteer an opportunity to look at the connection requests that are running our onboarding process. The process volunteers is a level, not necessarily a security role. For each of our ministry teams, we have a process security role for that ministry team. And that way we can limit what processes a volunteer can see or can facilitate just by what ministry team they're a part of. If you're part of our guest experience team, then you probably aren't going to need as much information on our care team. So that information just doesn't become visible to you in the system. Our financial volunteer is, again, access to the check scanning application and the basic financial batch information. We also opened up a group admin role, which is in addition to onboarding process. The onboarding process is looking at the connection request. This actually gives people the ability to edit group member rosters for our serve teams. And then we also have started asking some of our volunteers to be able to send out communications from Rock. And that's a little bit scary to open up, but we are very specific on what volunteers we're giving that access to. All right, so now that we have the framework of data types that we're working in and a consistent level of access within those data types, now this is showing a little bit more of the specific ministry opportunities and what connection requests are going with those opportunities and what level of access our volunteers have to those connection requests. So you can see at the top that we have view access. We've also determined when a volunteer can help facilitate the process and when a volunteer can be assigned to the process. So what that means is if you can see it, then you can help to facilitate the back end administration of the process. But we're still expecting a staff member to do any personal interaction with the attendee. If you have been approved to facilitate a process, that means that you can have some of those conversations with the attendee. Whether it's communications through the system or whether it's sitting down for a face to face conversation, we're opening that up for you to help facilitate that as a volunteer. Generally speaking, the ministry team staff are still responsible for making sure any follow-up processes are being taken care of, whether the connection request is assigned to the volunteer or whether it's assigned to the staff member. But you might ask them, why not just let the staff member be assigned to the connection request all the time so that they can make sure those follow-up processes are happening, they can get the automatic reminders? And the problem with that thought process is that some of our ministry teams asked for the connector on the connection request to be part of a workflow. So sometimes you have to assign a workflow to the connector. And if we're opening up the ability for a volunteer to facilitate the process, then they need to be the connector to be assigned in the workflow. And then it just gets easier to assign them to the connection request than try to engineer around that. We also have provided some level of access to our ministry team's volunteers that they can go into a rapid attendance entry tool and take attendance for some of their ministry team environments. So by formally structuring our data and our ministry processes, we're confident that our data is remaining secure. But is a formal data structure enough? Since you can never be too careful, we also have set some checks and balances in place that we have not included our financial volunteer level or our communications volunteer level or our managed group members level in any automation. So that can only be assigned by members of our digital team. And we help work with the ministry teams across our locations to make sure that we're identifying trustworthy volunteers to be given that kind of responsibility. So by now, you might be wondering, what happens when someone stops serving? If access is granted automatically, how are we making sure that the security roles are being removed when somebody steps off of their serve opportunity? Again, if you're asking that question, I'm so glad you asked. We ask our staff to let us know when a volunteer is leaving their serve role, but we all know that that's not always cut and dried moment in time when someone says, hey, I'm getting too busy. This isn't really working for my schedule. Can I just take a break? Can I step off the team for a little while? Sometimes life just gets busy for them and starts crowding out their opportunity to be on your team. And they slowly start fading more and more into the background, less and less involved in what you're doing. And pretty soon, you just forgot that they weren't there anymore. And then you're not letting us know that, hey, their ROC access is really just now open and nobody's using it. So we want to make sure that we're not hounding our ministry teams to say, hey, you need to let us know this. You need to keep after these people. Sometimes it's just not possible. So we've automatically built in a checks and balance that if they haven't logged into Rock or fun fact, the check scanning software does not actually log the login in the system. So we went ahead and found specific interactions that the check scanning software does in their name if they've logged in. So if they haven't logged in and hit the home page of the internal rock site or haven't done two key items that the check scanning software will generally do when you're logged in, then if you haven't done that for sixty days, we automatically remove your ROC access. Now we realize this could catch a few people who are just giving a lot, taking a break, and they want to jump back in in sixty to ninety days. Well, we don't necessarily want you to have access for sixty to ninety days when you're not using it. So we're still going to pull that out. But we've built in a step in the process to identify what changes we're making to your profile. So if we need to, we can go back and add it all back in pretty quickly. So now that we know why it's helpful to automate this process and the framework of information that kind of allows us to make this automation a reality, let's take a closer look at the how of how we built the automation. We used a few core features piecing together data views, groups, security roles, system jobs, workflows, electronic signature documents, and attributes on quite a few entity types to build out the full track of automation. The first step, a staff member identifies a volunteer who will need access to Rock by onboarding them into their serve group and then selecting I forgot about that one. We use our Help Hub ticketing service to field any questions or requests about the manual security roles. So if they're not being added by automation, just submit a ticket to us and we'll take care of it as soon as we can. All right. So identifying the volunteer who needs access, once they're in the serve group, then the staff member can check one of these boxes or multiple of these boxes, depending on what processes the volunteer is going to be helping with. This causes the person to be added into a data view that looks for any person in one of our serve roles that has any of these checkboxes. The other criteria they need to meet is that they don't have a signed confidentiality agreement on their person profile. We also don't want to keep hounding our volunteers because we have a job set up to run pretty aggressively on this so that they get the confidentiality agreement quickly. So we don't want every fifteen minutes a new request to be sent out. So not only do they not have to have the confidentiality agreement, but we also look for any people who have an active workflow requesting a confidentiality agreement. And we filter them out. A system job then triggers the workflow, which is designed to make sure a confidentiality agreement is on their profile before we give them any access to our rock system. The steps to that workflow include getting the entity type from which the workflow was triggered. Now, I should back up just a step here. This was originally designed specifically for the system job. But once we started building it out, we realized that in a picture perfect world, a volunteer is going to get you a confidentiality agreement back as soon as you send it to them, right? Yeah, that's not always going to happen. So we needed to build out a way to resend the confidentiality agreement request and remind them that, hey, if you want to join this team, if you want to be a part of what we're doing, this document really is a key part of that. And we need to have that before we can get you rolling in this opportunity. So the first step is going to be getting the entity type, whether it's triggered from the person profile, a group member grid, or a connection request. We have all three of those built in just in case we want to expand the feature as we go. Or it could also just be from the person from the DataView entity. If it was manually triggered, we redirect the staff member that triggered it back to the entity from which they triggered it. So if it was from a group member grid, we take them back to the group. If it was from a person profile, we take them back to the profile just as a quick way to say, we see you. Your time is valuable. You don't have to click back to the home page and go back to where you came from. We then check for an existing confidentiality agreement on the person sorry, this is where we check for the active request workflow. If they already have an active request, we kind of take a shortcut here. And since we've identified the active request, we pull in the attribute values from that workflow. And then we just send an email reminder that links them back to the original request. And then we close this request so we only ever have one active request for a confidentiality agreement at any given time. If they don't already have an active request, we come back to the original activity and we keep going. We find out which campus is making the request or which campus, if this is based off of automation, which campus the person will be serving at. And then we actually get a staff member from that campus that's affiliated with the ministry team they'll be serving on. We create a connection request with that staff member as a connector. And we assign the campus on the connection request just to help us filter out if we need to go back and review some of these a little bit later. We then send an email to the volunteer linking them to basically this workflow to get the confidentiality agreement signed. The next step is the actual signature document. By default, a workflow is going to stop processing until that signature is submitted. So it's basically in a holding pattern until the confidentiality agreement is returned to us. Once we receive it, we have a person attribute on their profile to let us know whether they've been approved for Rock Access. And that attribute is really a key part of both our onboarding and offboarding process. So at this point, we set that to yes. And then we connect the connection request that was created earlier and then set it to inactive so it's not just hanging out in our process. And then we complete the workflow. One of these days, I'm going to learn to keep up with the clicker. If you see me falling behind my slides, feel free to raise your hand. Let me know. All right, so at this point, the volunteer is eligible for at least one security role within our system. That means that they're getting picked up by a data view for a group sync. And they're going to be group synced into any security roles that they qualify for based on the attributes that were selected on their group member. So at the very minimum, they'll be eligible for our base level access. Once they sync into this group, they'll receive a welcome email. They'll also if they haven't had a Rock login before, a new credential will be created for them. So the welcome email will tell them what that credential is. We'll also tell them that a staff member will be following up with additional training and resourcing so that they know what they're doing with that login information. If they already had an existing login, then we didn't really want to put their password into the email because we're not setting it to require them to change it again. So at that point, we're just putting in their username. And then we're giving them instructions that if they don't remember what their password was from serving in a previous time, there's instructions for resetting your password online. So that's basically the onboarding part. But in order to keep the data secure, we also want to make sure that we're offboarding well. So when we automate our offboarding, a staff member again identifies the person who stepped away from their serve role. And what this looked like in the past was they submitted a ticket to us. And they said, hey, this person's stepping away from the team. Go ahead and take their ROC access away. And then we would have to manually go in, take off all the security roles, and make any adjustments that were needed. Now they can identify the person by going back to the serve group and either removing them from the group. Or if they're going to be serving in a different capacity, they can just uncheck all the boxes in the rock access. And that's going to trigger the automation for off boarding their rock access. So once they uncheck all the boxes or the person hasn't signed in for sixty days, then they're added into a data view. A system job will pick that up again. And they'll trigger a new workflow that's designed to remove all of their access permissions. Might be jumping a little bit ahead again. All right. So the first step, again, is getting the entity or the volunteer from the data view. This one, we're not necessarily needing to come back and figure out what entity type it was triggered from. We're just running this one off of the job. So the DataView entity is all that we need. We're pulling details from any serve groups that they're a part of, whether that's a serve group that has the automation attribute on it or whether that's a manually added security role. We're getting all the details from that group. And if it included the attribute, we're pulling in all the values that were selected. We're then getting a list of the group members that it's looking at. We're pulling that into a JSON element so that for the rest of the workflow, we're looking at just that JSON instead of making database calls back to the person every time we want to look at what changes need to be made. At this point, we're about ready to make all of our changes to their roles. So we want to make sure we're building in a step that if this is either triggered in error or somebody is just taking a short break, we can go back and add on those roles to their profile again fairly quickly. So we're capturing a person note at this point, making an outline of all the changes that we're making. So right now, this is an example note using one of our test people. My boss is a big Transformers fan. So we have a prime family in our system. And Data Prime just happens to be one of the members of that family. So you can see here that they had the manual access security role of a communications volunteer. They were also part of our worship and arts team. They also were part of sorry, they were part of two campuses, Worship and Arts. The first one, they had all three checkboxes in the system. And the second one, they only had two of the checkboxes. We're going to clear out all five of those. So we wanted to make sure that we recorded that all five were checked just in case we have to come back and reactivate all of their previous access. You'll notice that by being in two groups, if one ministry team says, hey, they're not serving with us anymore, and they take off their checkboxes, another ministry team, if they're serving with another ministry team, should still have their checkboxes checked so they won't automatically trigger taking them off of everybody's security team just by removing them from their own group. All right. So once we have set the person note on their profile, then we're looking at that person attribute of whether they're approved for rock access. And we're setting that to no. And basically what that is doing is making sure they're not reentered into any onboarding or offboarding automation automatically. They would have to be intentionally re added for onboarding at a later time. After that point, we start looping through all the group member records that we pulled in earlier. And we're just looking to see, first of all, is that group member record part of a manual security role? Or is that part of a serve group that has a rock access attribute? If it's part of a manual role, we're just removing them from the role. And then if they are in a serve group with attributes selected, then we're just blanking out all of the attributes. Once that loop is complete, then we're just completing the workflow. So now you've seen how we are leveraging core features in Rock to help our ministry teams equip people for the work of ministry without having to wait on our team to make that ministry possible. We're grateful that Rock allows us to remove barriers and allow our ministry teams to equip more people for the work of ministry. You've also seen how we've developed a framework of data classification in order to provide consistent access to our volunteers across all of our locations. And finally, you've seen how this automation helps us to protect our data by automatically removing the permissions from accounts when someone's no longer using them. If you have any questions throughout