RX 24 - The What, Why, and How of Choosing Rock - Mark Burleson

Transcribed Content

He's got a guitar. We don't have a guitar. Okay. Welcome to the second session, the first day of Rx. Today, we have Mark Burleson and John from Crossroads Church in Cincinnati, Ohio that are gonna talk about to us about the what, why, and how of choosing rock. Awesome. Welcome, everybody. How's everybody doing? Good. Good. Yeah. Well, welcome to the what, why, and how of choosing rock. We'll start with the important stuff, family pictures, because families are important, right? So my name is Mark Burleson. Work at Crossroads Church in Cincinnati with John Baker. This is my lovely family, Alicia and my kids, Ben and Katie. Decided for a cold picture because it's hot outside, so you guys can look forward to cooler weather in the future. Yeah. So John, why don't introduce yourself? Yeah. And I'm John, and I decided to go with the same theme. So this is even snow in June at Crater Lake National Park. I know. That's my wife Jamie and my girls Jocelyn and Jorey. So as I said, we're at Crossroads Church. I am the enterprise architect, and John is the director of Technology and digital products. Yeah. So if you don't know who Crossroads is, just super, super quick. We're a multisite church in Cincinnati, and we invest a lot in technology. So there's a lot of tech around our space. And so hopefully, this will be helpful for you to hear some of the ways that we've leveraged technology with Rock at Crossroads. So choosing rock. And so the first question is like, do you choose Dwayne Johnson? Is it the Plymouth rock? What is rock, right? Fraggle rock for you guys who are maybe millennials? That's my yeah. Probably do you all know him, Fraggle rock? Alright. My kids are like, what's Fraggle Rock? No. So what is Rock? So this is stolen from the website. Rock is an open church management system that focuses on the heart of ministry people. Fully featured, mobile friendly, Rock is building vibrant community and innovative new solutions to meet your ministry goals. It is owned and shepherded by a nonprofit ministry itself. Rock will always focus on meeting the needs of organizations it serves. And you're like, I don't what does that mean to me? What does that mean? If you guys like I like memes. This is the end of the memes, I promise. So here's some highlights for us of like here's some reasons why we chose Rock for us, and this might be helpful to you, is Rock is highly configurable. There is a lot of ways, and if you guys are in the whiteboard session that just happened, there's lots of ways to build out things just for you, and it's highly configurable. That also means its greatest strength might be your greatest weakness because there's so many different ways to do it. But that does mean as things change and evolve in in your ministry that you can change and evolve with it. One of those other things that that means is when you get to implementation, we were partnered closely with Triumph when we went through our implementation. And we were asking often, like, well, what's the best way to do this? And it the common answer, and rightfully so, was it depends. Because there's so many different ways that you can do things in Rock. That's what creates sort of the the greatest strength can be the greatest weakness. It just there isn't a simple answer always to how you might use it because you can do so many things with it. And then coming up, we'll answer a little bit of how you solve some of that. Another is scalable. So there's different ways you can do cloud hosted. So you can run that yourself in Azure or Amazon Web. You could work with Rock Cloud or some of the other providers that host it for you. And for those when you get larger maybe, sometimes you can do different cloud setups with multiple servers and but most people don't actually need that much. The one thing I'll say right now, there is no official Azure app support, though I know there are churches like Northpoint who have gone back and forth with using it. So hopefully soon as they continue to work on things that that scalability is there. So as you guys grow, you have maybe you have a great Easter weekend or great Christmas that with cloud services, you don't have to worry about some of the server aspects to it. But that's one of the highlights I think that Rock brings too. Anything you want to add to that? No? Data management and integration. There's all sorts of different ways that you can access and report on data in Rock. There's the internal reports themselves. Because Rock is open source, you can access the database directly. We leverage that a lot of ways. We pull data out and put it into a data warehouse and leverage those types of features. But Rock does have robust Power BI reporting in it. Yep. And as you've probably heard in the keynote, a lot of information about different ways that you can leverage that data. And that's one of the beauties of Rock as a system is you're not you can access your data and you can leverage the reports that many churches have invested in and Triumph has invested in or Spark as well as create your own. Yep. So again, you can start as simple with built in Rock reports, or you can, using the highly configurable, expand that. And then obviously it continues to grow as more churches invest like we saw earlier with generosity reports. My last Rock highlight is community. And if you were in my last session, heard this a lot. But Rock is built with input from churches and partners. And that includes things that are funded. Those are ideas. That stuff that comes up in Rocket Chat. And that also means for us. That means us working together can help solve I know Frank has been he's in the back. Rock legend over here. But yeah. He does not like the attention right now. But the point of that is Frank was one of many who helped even us as Life Church when we got started is he was there and answered questions and, hey. Here's some learnings that we had. And so my encouragement is, as you guys, if you've already chosen Rock, you're on Rock, is just stay invested in the community. And sometimes I know for me, I felt bad that I couldn't answer stuff in the beginning, but over time, I was able to then start investing back there. And so just know that you can be there for other people and other churches when they get started. Because we're all about the capital c church. Right? It's his church, not our church. That's part for me. And when we did our implementation, we leveraged developers on our own team as well as other folks on our team, and we heavily leveraged Rocket Chat. And folks were really surprised how quickly they would post a question and get an answer. So it really is super valuable tool to be able to leverage the community and use Rocket Chat in that way because we would be in the middle of something and be like, gosh, I wonder how you do this or how do you fix that? And we could just post a question and and get a quick response, it was super helpful. So it's a huge benefit of Rock. Yep. And I didn't add in the beginning. If you guys have questions along the way, feel free to interrupt and ask things, especially about what we're talking about. So don't don't you have to, like, have to wait at the end if you have questions along the way. I forgot to add that to it. Yeah. So Azure has a service that is a serverless function that you can actually build stuff or deploy stuff that is like containerization. Rock doesn't have native support for that yet. You still have to primarily use VMs for supported. You can run it, but if they're if you reach out to some of your partners, sometimes they can't always solve it because it's not fully supported. So Yeah. Does that help answer your question, do want any more detail? I probably don't even need to know the answer. Yeah. I mean, the question would be, does that block us from doing anything? I'm not No. Probably yeah. Most people, it doesn't. It's just one of those if you want to get to where you're not managing VM sizes or your server size, that's the next step that people are looking at in future technologies. So I just wanna make sure because that's a question I get asked a lot of how do we use Azure App Services so that we're not worrying about the underlying OS and CPU storage space and RAM and all that. So the next thing is like if you're choosing Rock is, and even if you're on Rock, is understand your why. ChatGPT said that this is a Simon Sinek quote. I could not find it anywhere, I've asked. But clarity in mission leads to clarity in action. So understanding why you're doing something, whether it's why am I choosing rock, why am I doing something rock. So understanding why you're gonna do it is gonna help to what you do. So that's something that's like a key part, and we'll go through those here. Yeah. For us in particular, as we were looking at rock, I mean, every church has probably their own specific reasons why they might be considering it. And so I'll just give you some examples of why we looked at it and what was benefit to us. One of those was that we were on a different CHMS at the time, and we had done a lot of configuration of that system ourselves, which meant that upgrades and that kind of feature set was really challenging for us. It also meant that maintaining all that custom code was costly and an investment for us. So that was another reason that, you know, we kind of painted ourselves into a corner where we had to continue to spend a lot of money on development and maintaining it. And also, we felt at the time when we had switched to that church management system, the feature sets that we wanted weren't yet in it. So we kind of felt like we were a year or two ahead of the system, so we kept like building something and then a year or two later they would release that feature that we wanted or that we'd hoped for. And that also meant that we, because we're doing all this customization and updates were challenging, our UI, because we'd been on it for a while, the user interface was not great. And so it sort of was, you know, didn't have a good reputation among our staff. It wasn't that the tool wasn't powerful, didn't have great data, that we couldn't do things with it. It just felt challenging to staff to engage with it. And so, you know, one of the reasons that we went to it is we really wanted to kinda hit the reset button on a church management system is a really valuable and powerful tool, and we wanted our staff to feel that way about it. And in our case, another, like, leadership buying question was we had a lot of peers that were moving or had already moved to Rock. And so, honestly, our executive pastor would probably every six months or so ask, why are we not on Rock? It seems like everybody's on Rock. So we actually had a leadership mind in that sense, which was great, which is helpful because you want to have that alignment with your leadership. So those were some of the reasons that the why behind why we were looking at Rock. Now all the things that we mentioned in the beginning, like highly configurable and a lot of plug ins and access to the data, all those things were other technical reasons that we cared about, but organizationally, those were some of the reasons that we pointed in that direction. Yeah. I'll answer a little bit for the leadership buy in. So at Life Church, and I was on the team that rolled out Rock at Life Church years ago, we were answering questions like how do we get access to our data so that we can do better reporting to help persons on their next steps. And with our previous one, we only had access to a small portion. So Rock being open source solved that. And if you guys know Life. Church, they're big in generosity and in helping the capital c church. So Rock Community and being able to partner with that was was big leadership buy in for us. And so the reason we talk about organizational goals because if you try and push something that isn't aligned with the mission and where things are going and how it solves that, you might not get the buy in or the resources with that from the leadership side. And so that's a pretty good way to say, make sure that if you're gonna if you're like me, I was IT director who led the church management side, is making sure that it fit the vision of the church where it's going and not just my specific one. So next one is technical goals. So how does how does Rock solve technical challenges? So a specific example I just said for Life Church was access to data. We also wanted something that scaled and was able to change process. So as we grew and scale, how do we then continue to grow with that and not have a tool that actually restricted how we did it? We didn't wanna do custom code, but we wanted something that could be configurable. And I will say this my thing is technology should not be your primary driver why you choose something because I'm always a big thing of, you know, Simon's Linux start with why. Why are we what are we solving? What problem is there? And then using a tool to solve that and not use it conversely. Yeah. And I would say similarly, like, while there were technical solutions that Rock solved for us, you know, some of those things were really particular to us. Now organizationally, it allowed us to spend less on church management technology and investment in those things, but that isn't while that is sort of an organizational benefit, it still wasn't necessarily the the key driver too. So I just reinforcing what Mark said, sometimes the technology can be really helpful and great for your team, but it might not be the flag you fly as far as the why goes because it may not convince a lot of other parts of the organization that that's why we should make this thing and invest in all this new training and etcetera. And the last one I have is process goals. It's how does rock support or inhibit your process? And I also had this. Sometimes you have a process problem, you don't have a software problem. And you might have a culture problem too. I've had met with the church a number of years ago who is now on rock at the time. They were like, here's why we think about going to rock. And as we ask questions, they realized we actually have culture problems. The software isn't our problem at the moment. Until we solve that problem and solve those processes in our organization, moving to rock is the problem's just gonna go with it. So understanding what you're trying to do. I'll give a a great example of process stuff for us is when we first launched Rock at Life Church, to give an example. And in part of this, I wasn't on Crossroads for most of it. So a lot of my personal examples are with Life Church. But we wanted a way to track Life Group interest. Interest. So how many people are signing up? And so that's a process problem that we wanted to solve, but we didn't know how to solve it. And so we actually launched Rock first with only life groups. And through that, we could see, hey, like our Albany, New York location, we were having fifty and sixty requests searches for female women life groups on Saturday morning, and they had one. And so the campus at that time knew, hey, we need to recruit women to lead small groups on Saturday morning because we have a need there. And so for us, that was a process problem that we're like, hey, we need to figure this out and let's figure out so Rock was actually a tool that actually enabled us to do that. Yeah. And for us, one of the things was we we had done a lot of customization. So our ministries got really used to kind of like asking specifically what they would want, and then we would code that solution. In some ways, that's great. Like it allows for them to be really specific, but one of the things we were trying to solve too was to say, you know, our way isn't the only way and it might not even be the best way. And so by leveraging a system that had some out of the box configuration, we had leadership really push for, hey, we're doing this because we we don't necessarily do groups that much differently. And the the certain ways that we might do it, we can probably configure that in Rock and not have to develop something specific. So we actually leveraged rock as a part of that process to sort of change the culture around you're not gonna necessarily get exactly what you want or even consider your process. Is it the best way to do it? There's other churches that are doing it just as well or better, and let's look at Ross Rock to see is it time to change the way that we do things. It's it's usually a lot cheaper to change your process than to code custom software. So that's the other thing. And so that's one thing at Crossroads when I when I came on the team was actually helping check-in changes of what's what works in Rock and then how do we make sure we still solve as much as we can child check-in process. Any questions about different process or organizational alignments or goals before we move on? No? Okay. Oh, yeah. Alright. If you have a question, just wait for me to get to you with the mic. So we've rolled out our Power BI platforms, dashboards to our staff and our team. You mentioned the Power BI that's already built inside of Rock. Are you able to bring those existing dashboards into those accounts and integrate those together? Just saying yes back here so you can bring it in. Okay. We're using it in the Power BI app side, so we haven't done it inside of Rock yet. So and that was based on our existing process already. So we could just we changed the database data views on the back side. So you've chosen Iraq. What next? So I call it design your path. So what are going to do next? First thing is adoption. So I call it bringing others along because you don't want to do it alone because you won't have success, right? Because it takes everybody, your entire staff to do that. Some of the ways you could do that is is meeting with your leaders to connect on the day to day. Because guess what? Most people don't care about the big why. They wanna know how does it impact them. Right? So it's meeting with the different ministry leaders, and sometimes even they might bring in a specific staff member to answer like, hey. This is how how it can do. And but you always wanna connect it always back to the why. Right? Because there is a part of like, this is why we're doing that, but you wanna make sure that connecting on how it actually is gonna impact them. And we have every two weeks, our whole staff gets together for a staff meeting. And so my boss would get up and regularly give very short quick updates so that people didn't when we announced we were moving to rock, you know, there's some when it feels like it's kind of under the covers and you don't know what's happening. And so we would regularly remind people like, hey, what's going on? It happened enough to the point where after we had implemented Rock, he would get up to say something and be like, hey, I've got a Rock update, just because people were sort of expecting it as a joke because he'd been repeating like, hey, here's what we're doing, here's what we're going on. We also leveraged an internal sort of intranet, if you will, where we would post updates and we encouraged people, hey, there's this Rock channel, you can subscribe to it, and you can get emails when things get posted, and we're still doing that today. Alison, who's actually in the room with us, regularly posts updates on feature sets or new training documentation that we have or updates that we've made so that people can keep hearing and being reminded about what we're doing and how it's helpful. Yep. Consistent communication is going be key through the entire process. Making sure it's timely, that it's what they need, any action items, those are always and so like staff training. Because even after we launched, was still a thing, like, here's a rock update. And and that's Allison does a great job of continuing to post updates and training opportunities for the staff on the staff hub. What's a realistic migration timeline? Yeah. I sort of hate to answer it this way, but it sort of it does sort of depend. A lot of people a lot of churches from what I've heard like to do it sort of piecemeal where it's like, we're gonna start with checking, we're gonna implement that, and then we're gonna replace maybe our groups piece, you know, that sort of thing. We decided to go whole hog, and we literally replaced 38 custom applications with RockLaunch at one time, which sounds crazy and sort of was, but it surprisingly went incredibly smoothly. So from the point at which we had decided we were gonna do that and, like, started implementation to the point where we could go live, we were originally targeting twelve months. As we got close to the end of that, our finance team was like, Slow your roll, we've got a lot of stuff we gotta figure out. And so we waited a little bit longer, so it ended up being fifteen months to when we did it. But it really does depend on kind of how you want to implement it and what are the most important features you want to do it. I think some have probably transitioned over two years, you know, because they wanted to do it piece by piece. Or, you know, depending on what system you're on now and what you're trying to move, like you could do it in a shorter time frame. Yeah. Think it's depending on what outcome that you guys want as an organization. As we had in our last session, somebody said they should just start it fresh. And so they didn't do any data migration. And so they just made sure it was configured and created a process where people can go and re sign up and create their rock profile, and they start it fresh. It can be done really quickly. I'll it depends. I do not recommend this, but we started, as I said, at Life Church with with the LifeGroups tool, and we launched that by itself. And then we took about six months to understand rock and all that. And then we built out rock completely as a replacement in six months, and then we launched that in six weeks for 35 sites across 10 states and trained at that point 900 staff members. So you can do it really quick. I don't recommend it. That was challenging, but the fact is if you bring the right energy and the right focus and you have the right resources, you can move really quickly with that. So it really depends on what outcomes and what your organization is comfortable with on speed on what rollout might look like for you. We got a question back here, Dean. Can you talk about if you bring it over piece by piece, aren't you gonna get duplicate people are gonna start existing in two. Can you talk about what it looks like when people start existing in two systems and concurrent systems, old ones and new ones? Yeah. For us, that's part of why we didn't do it that way, and we went whole hog because of that very reason. We were concerned about the amount of data synchronization and trying to do that if we were leveraging both because we had a lot of systems, or if you will, applications that were dependent on that that data. So if we made a change over here, is it gonna be reflected in this system over there? And the level of effort it would have taken for us to be able to build that synchronization felt like, you know, it would have almost doubled the implementation effort to try and do, which is why we decided, like, nope, we wanna dump and go. It did mean we levered I mean, I think, if I remember correctly, our data import involved, like, just 7,000,000 I mean, alone 7,000,000 transactions of giving. Because it was like we used our church management system as our system of record for giving transactions, and we had at least 3,000,000 more lines of transactions that we loaded beyond financial. So in and of itself, like, we took it took two and a half to three days of just data load. Like, we we agreed with our staff one Sunday afternoon, like, your CHMS is going away, and we will turn it back on. Hopefully you know, we were aiming for Wednesday, and then I think we had to delay it by a few hours. But that was and we practiced that data load multiple times ahead of time to say, like, is it really feasible to do it this way? So that's why we avoided exactly what you're talking about. Yeah. And I think it depends on the scale of data loads. So some people might be like, it's enough small enough they can do it. We did at Life Church a one way sync from our old system. So the people who were on the new system, all that data just stayed in the new system. And as we move the next set of campuses, then we did a sync from the old system to new system. It problems because it's challenging, but that's what we did. Again, not really recommended by me, but Can you talk for a minute about how much historical data you bring in? You said 7,000,000? Yeah. We we brought all of the financial giving data that we had in our previous system over, and we moved all of our all the years going all the way back. Wow. Because that was like our system of record for transactions, we've we do have a general ledger separate from that. But if we wanted to know this person gave these gifts, it was in like, our system of record was our CHMS, and we didn't wanna lose that. So we brought all of that over. We spent I mean, there was a team that met weekly for months just on data. Like, are we gonna move this and, you know, how would we move it and where would it go? And is this data attribute still valuable and, you know, like, bringing over or not. We did leave some data behind, you know, because some people are like, you really wanna get it all clean before you move it over. That is a know, definitely a strategy, and there's a ton of value in that. And we did some of that, but a lot of it was like, you know, there's so much we could filter through. We're just gonna bring it over and try to marry it up as best we can. So, again, a lot of it is asking those questions along the way, like what would it take, and is it really worth it? Is the value there to to make that migration? Yeah. And it goes back to organizational outcomes. Right? What is your organization comfortable with? Some people I know just moved the previous year because they just went year over Life Church, we moved 98% of everything, a very large database. And we didn't move some things like connection requests. Like we kept the last two years, but we didn't bring a bunch like, we kept the database export of it so it was actually in a SQL table that we could report on if we needed to. But it really, again, goes back to what is your organization comfortable with? What outcomes do you want? You know, if it's your system of record giving, obviously, there's financial aspect to that and then legal aspects that you have to be aware of. And so if you don't have it in your system, where do you have it? So it it is a it is a depends question, unfortunately. Yeah. Another element I'll give you that we chose to do, we told our staff, like, our previous system is going away on this day. Like, you will not be able to access it. Unbeknownst to them, we still had access to it for probably up to, like, two years where we were like, if there's data we forgot or if there's a question we can't answer, you know, in the new system so that we kept it up for us to be able to access so that we could still get at it. And that's another sort of strategy. Like, what if I forgot something or what if I missed something? Well, we we only fairly recently turned it off completely. We, of course, have backups of it. Yeah. But we really left for us to be able to do things in it for a period of time, but tried to, like, I guess, force staff to make the move. Yeah. We had it on for a year and a month from the time we switched over. We removed everybody's access except for a handful of people, And then I kept tabs on how often it because I was like, can we shut it off now? Yeah. Next up, training. So so design your path training. Some things that that Crossroads did as internal rock stars. So you talked a little bit about it, but why don't you go? Yeah. This was I think this is really key. Like, as we went through the process, one of the things that was super important to me was adoption. Right? Like, can bring in a great tool, but if no one knows how to use it or they, you know, have a bad taste in their mouth about it or whatever, like, doesn't matter. Right? It could be a really great tool, but if no one's using it, it's useless. And so one of the things that we did is we went to every one of our sites and then every one of our central ministry teams and got a representative from those places to be what we, I mean, obviously stole the term rock star from them. We walked them through tons of training. We had a leader of that team who made sure they were cared for, that they knew each other, that it was a fun group to be a part of. And then we even got them, like, special pins and other things as we went through implementation. And so they were the first line of defense, if you will. If someone in their ministry or at their site didn't know how to do something, we were like, go to your rock star. And it's a I mean, we had so few questions in the end when we implemented that came directly to us because we had these experts, and we've kept that going. We still have a rock star team. Their frequency of meeting has dropped to, I think, once a month now. But if someone if that rock star leaves staff, we make sure we go back to that site or that ministry team and say, okay, who's gonna replace you know, who's gonna be the rock star representative for you? And that also allows us to get really good feedback. Right? Because we sometimes we don't hear that that system isn't working well for them or they wish this process were different. Well now, they have a because there's a representative from our team on the Rockstars, we get that direct feedback and we can make adjustments, maybe configuration changes to help that work. So that was so adoption being super important to us, you know, we really elevated that as, hey. Remember, this is the rock star for your ministry, or this is the person to go to your site. And then they, of course, could reach out to us if they had additional questions. Yep. And I'd say from on the training, so I said plan for group and individual training. So you have high level, that's a vision training, that's culture, you're top down, and then it's groups. And we had Eaglebrook was actually the one, and they brought this up too, of, hey, sometimes they wanna know the specifics. So you have to plan all levels of training all the way down to how do I do specific role training. And so you have to plan for that. Sometimes that's also through CubPost, so like your your staff staff portal. And the thing I would say is show the staff that they are the hero in the story because you wanna empower them. Right? So if you guys have read StoryBrand by by Miller, have you guys read that at all? If you haven't, it's a great, great book anyways. But the idea is you tell you you help them. You're their guide. You're not supposed to be the hero in their story. You want them to be the hero of the story. So in all you're training is you're helping them empower how they do their job and how they carry out the mission of their church. And so in anything you're training, if you gear that, you're gonna have a lot better success in providing them the tools that they need if they feel the engagement of that. Any questions about training? Was it a 100 Yeah, we Was every staff member accounted for in that training, or were there staff members that were not participatory? So, like, for example, we have a video editor from time to time looking for specific people in a video or looking for a specific group of people that they could use leverage the tool. So you bring in some of your auxiliary groups and go top down. Are there specific teams that you prioritize one over the other? We we currently continue to use a learning management system. And so we did have some basic training that we wanted everyone to go through. And we worked with, you know, even to the point where they're managers so we could pull a report out of LMS. Has everyone actually gone through sort of the basics of how do you look someone up? And, you know, some of the information that would be valuable really for any any staff member to be able to access. And then we did do specialized training. So we had specific, like, for our kids club or our children's ministry, it was like, you're really gonna need to know how check-in works, you know, or there's other features that you're gonna really know. So then we had specific training added on to that that each individual group or a separate one for finance, you know, or for our groups team. So we did do some level of training that everyone was required, if you will, to do. And then we had specialized ones. And those we would often do not necessarily through an LMS. Would do like, we would have the ability to go back and review training and have access to that, but we would pull those people into a room too so that there could be a lot of interaction. And sometimes we even leveraged the rock star from that ministry to do the training Because then again, you're getting that reinforcement of like that, this is your go to person who knows how to do it. And we knew the training was good because that person has to use that tool that way. It's not just us trying to configure it the right way. It's like that ministry lead or that person in that ministry using the tool. Would you be able to speak specifically to HR team training and the pros and cons of using Rock for HR onboarding applicant pools, what software best integrates with Rock, and just where those lines potentially could be? Yeah. For us, we we use a separate HR system, so we don't do a whole lot of integration that way. The the only exception that I can really think of in fact, even the because we want that HR data to be sort of separate, well, we do background checks for a lot of volunteers, you could see those, like whether or not they've been through a background check, not necessarily the details of it, of volunteers. Even though we use the same provider for those background checks for HR, they actually store that data in their own area so that obviously staff can't look at other staff's information. So we haven't done a lot of integration. I'm sure there's opportunity to do that with some or or some churches have probably done that. We've kept those systems separate. We use Paycor. Yeah. And at Life Church, we didn't integrate. So HR had its own system as well as application tracking system. We difference, we did staff background checks in Rock, but we restricted who could even see the background check. So you can see we're approved, not approved. Usually, if they're not approved, they're not gonna be on staff. But I don't know any excuses, but there could be edge cases, I guess. But we did everything from even staff perspective in Rock for background checks because we also use that for even if you're staff, you had to have approved background check-in Rock to serve. So for us because at LifeShares, we require background checks for every volunteer. You could not serve without a background check. But we didn't have any of the other HR. We we have a and we Crossroads as well, an attribute that has staff attribute stuff so we could identify you in the system, but the actual HR process is not in there. I'll repeat your question so Josh doesn't have to get up. Yes. Yeah. Why am in here since we've been on Rock for probably four or five years now? But I won't go into that one. But from a standpoint of HR stuff, what we did, we do use the plug in with CIA. And so the our background checks are integrated into Rock, and most of that is happening. And then, like you said, with secure security around blocks and around HR and stuff, only certain people can see. Mostly Rock admin and the HR team can see that. Then we have it's automatically setting those flags of, yes, you're approved or not approved and all that kind of stuff. So there is a piece of that with background checks that is very integratable in there. And then we also have just recently decided to hold a Paycom ID on our system as well just so that it can interface with Power BI and be used to say, okay. From our Blackbaud Financial, they needed that Paycom ID. So we kinda did some attributes across to help some of that reporting even though most of the HR processing is I mean, it's in CIA. And so the results bring back and store as a PDF for those that can see that have access. So there is some integration, but it it was minimal in that aspect. So Yep. Alright. Last, we have technical migration. So I'm gonna have John talk about product principles. And the thing I'd add is to set guardrails for your application because scope creep is real, especially in a CMS where everybody has what they want. So, John, we can talk about product principles. Yeah. So one of the things that we did is we went through it with our technical team. We set when we said product principles, it's sort of a term out there, but we were trying to set, like, what are the guidelines as you there's a thousand decisions we had to make as we were implementing Rock. So what are some high level guidelines that can help you potentially answer those questions before having to go into too much detail? So the first one was configure over customize. So our the primary choice, if you have the option to do rock out of the box first and configure it, like, do that first always. The next one was solve for the 80 and document the 20. We were not going to try and find solve for every edge case in the implementation. There will be some that will go back, and you've probably experienced this if you've implemented software before where people think they need this feature, and then after two weeks after you implement it, you go back and say, do you still need that thing? And they're like, no. I'm actually fine without it. So we would document the concerns that people had if we felt like it was the edge case, but we wouldn't implement for it in the initial implementation and then go revisit those. And then our other one was to maximize Rock's architecture to do it. So as we were moving from our previous system, could we change the process? Would process change work for us and be able to leverage the architecture that Rock offered? So that we were really trying to push for we're doing this as an organization not because we don't think customization can be great, but we're willing to question that customization that we've done in the past and say, is that really is the value really there? So those were some of the things as either our developers were meeting with or our product folks were meeting with teams and ministry teams, you know, they would think to themselves, wait, is this a 20% edge case? You know, do I really need to solve for that? Or like, great. We'll write that down. We'll make sure we keep track of that. We'll revisit that with you after implementation, but you're not gonna have that, like, out of the gate. Yep. And we still use those product principles for Crossroads now and even those we go through. So I think that's also good even after you're implemented and you start doing new things is having those guardrails for yourself. Just a quick recap as we're running down here is what is rock? So rock, obviously we talked about that. Understand your why is clarity and vision equates clarity in action. And design your path. Know your how you're gonna implement it. This is our contact information. So if you have any questions, you can email us. Probably email me, not him. He's the boss. I gotta protect him. No. But we're here to Feel free. We'll leave that slide up for you. Yeah. We'll leave that slide up. But, no, we're here to serve, obviously, connect with others. And, yeah, if have questions