Podcast Episode 195: Episode 168: Rocking Security: Navigating New Features and Email Safeguards

Description

In this episode of RockCast, the core team discusses the latest upcoming Rock features, community updates and email protection strategies for optimal delivery. They address challenges like bot attacks and the intricacies of Mailgun integration, emphasizing the importance of meticulous logging and trend analysis for effective threat combat.Show NotesDetails about Rockʼs newest version releases here: https://www.rockrms.com/releasenotesLearn about Googleʼs new bulk sender requirementsRock Blog: https://community.rockrms.com/connect/gmail-spam-requirementsPartner Blog: https://www.triumph.tech/resources/demystifying-email-spam-with-google-postmaster-toolsRock Partners with CDN Options https://www.triumph.tech/cdnRX Conference InformationSign up for our annual conference: https://rx.rockrms.com/RX hotel information: https://www.marriott.com/event-reservations/reservation-link.mi?id=1694551025506&key=GRP&app=resvlinkSpecialized Rock ClassesCheck-In for Rock Class: https://www.rockrms.com/check-inRock Finance Class: https://www.rockrms.com/rock-financeFollow Jonʼs Twitter/X account for best practice information: https://x.com/jonedmiston?s=20Rock SponsorsWe are thankful for our Rock Sponsors and their support of the Rock Community. Visit their websites through the link above to learn how they can help your ministry and confirm that those you work with are as invested in the success of Rock as you are!

Transcribed Content

This episode of Rockcast is brought to you by Rock partner Triumph Tech, a full service specialist partner. Rock partners provide crucial support for Spark Development Network and important services for the Rock community. Connect with Triumph Tech today at rockrms.com/partners. Welcome to Rockcast, the podcast dedicated to the Rock community. Join us as we delve into behind the scenes happenings, offer insights into our community, and explore leadership dynamics. I'm Emily Forman, and I have with me today Jon Edmiston and Nick Airdo. Welcome to Rockcast. Nick, we love to start out with where we are and where we're going when it comes to Rock versions. What can you tell us? I can tell you a few things. So we have just released version 16.3 to alpha, but if you missed a few weeks earlier, we had released 16.2. 16 point two ended up being just a very tiny patch. There was some weird edge case that a couple people found in 16.1 with check-in, unique situation, but it was important to patch it. So everything that was going to be in 16.2 got pushed to 16.3 and that one fix was put into 16.2. So while all that was happening, we were working on version 15.4, and that was going through its own alpha and beta testing, which ended up not being We didn't have a lot of alpha and beta testers for 15x because a lot of them have moved on to version 16. So if you're listening to this and for some reason you are still on version 15 and you want to be part of our alpha or beta testers, please go to the community site, community.rockrms.com/getinvolved and go down to the alpha beta testers and let me know. Just fill out that email and let me know that you want to be on the fifteen team, v15 team. So having said that, 16.3 should be out, we're targeting end of this month if we can get through the alpha beta testing successfully. Great. And one of the big features we've been talking a lot about recently has been the check-in on NextGen. John, do you have an update for us on where that's at? Yeah, so that's probably something maybe even people haven't really heard about, but at the end of last year coming out of the conference, we approached some churches to say, Hey, could you guys help us fund the next generation of check-in? Now when we say next generation, we need to be very clear. This is moving the current check-in features and functionality to the next gen platform. What we'll get out of that is everything does need to move to the next gen platform eventually, so that gets us one more big thing done, one more big notch in the belt done. But we also wanted to address some performance within check-in. So check-in, the way it's architected through workflows is not necessarily the fastest way to process that data. And since many people are not even using some of the benefits of that workflow, it makes sense to probably pull it out. So we can actually do things much quicker. So this check-in is not necessarily to add a bunch of new features. In fact, that's not what we want to do. What we wanna do is just get it over to the next gen platform, at the same time thinking about how we could do new things in the future. So part of the first phase of this is not new features, but eventually we have some really great ideas about how we could change check-in in some drastic ways for people who want to, but they can also keep what they have. So here's what you need to know. When we're done, you'll still be able to use the old check-in system. Our goal is to make sure that still runs the way it does. And then you can gradually move to the new check-in and all your settings kind of come with you. But we want to have plenty of time and space for shaking that out because there's a lot of weird edge cases within check ins. One of the fun things that we were able to do as a part of this is the 12 or so churches who helped fund it. We were able to get them to come out and all meet with us out here in Phoenix. Perfect weather this time of year. And we had two days where we literally talked about check-in, all of the weird edge cases, use cases, trying to figure out where we're going in the future. But I think what was really fun is just having all the churches in one space and having them hear each other talk about all the different edge cases. I think it was an eye opener for many of them that it's often that we see our own edge cases, but when we see the amount of all the edge cases stacked up with each other, and some of them are in conflict. So it's kind of fun to hear churches, No, we can't make it work that. Has to work this. And this is kind of cool to actually sit back for a second and just let that happen. Because that happens to us all day. Right, yeah. So their eyes are open to that sound world that we live in. Yeah. So that's a big thing that's going on. The goal is to have that done by the end of the year. You may have seen a survey we put out recently about check-in, and that was our way of, obviously the 12 churches are help funding this gigantic project. Of course they have, their input matters. The entire community's input matters too, and that survey was another way of letting everybody have a chance to just let us know how they're using check-in so that we know, and if they have any ideas, can put them in there. But again, the phase one is not about adding new things to check-in, it's just getting us across the line into the next gen platform and increasing speed, but also doing it in a way that it's going to be a little bit more flexible in the future. When we do want to innovate, there's that capability there. There'll be a couple of little micro features that we're adding based on some of the stuff we heard in our two day, but that's a big thing. Also too, we've been switching gears a little bit, working a lot on Maui for Rock Mobile, and we've made great progress there. The team has done an exceptional job getting Maui ready. But we're also taking this opportunity to do a little bit of UI polish in Rock Mobile. Right now, it's very customizable. You can make it kind of look anything you want. But out of the box, it's a little bit our Stark theme on web. It's pretty plain and it requires you to style it and get it to what you want. And so we're trying to make it come out of the box in a really nice pleasant state. And so we're going back and refactoring a lot of blocks and a lot of the UI design system. And so we feel this is a great opportunity because Maui is a huge shift. As you go take your app from where it is today and Xamarin Forms to Maui, there will be a little bit of adjusting you have to do to your app. And we have a guide that kind of helps you with that. Some apps may not need any adjusting. If you have a complex app and you've done some really complex styling, there might be a couple little nuances that you need to do. We've already done a couple apps ourselves just to practice and make sure that we understand it all and polish out any places that we can. But since you're gonna have to do that to go to Maui, we feel this is the time to actually maybe even change a few of the styling points so that you just have to do that once. If we were to get you through Maui and then in inversion six or seven, all of a sudden you had to do it again, that might be a little frustrating. So we're kinda taking this time to to do that. We're we're really excited about whether it's gonna allow for the Rockmobile folks. So another topic that's been going on in the blog posts and just in general community is this whole new Google bulk sender requirements initiative that they've pushed out. I think it's important to understand that Google is the giant in the email space and they're a little bit a gorilla. They're very powerful. You don't wanna mess with them because all your email goes through it. And they're trying to do something, which I think at the end of the day is a really good thing, but they're having to twist some arms and they're being very gorilla with it. And which is if they're gonna put out these new bulk requirements, where if you send more than 5,000 emails in a day, and the definition of that is intentionally nebulous on their part, for good reasons, I guess, then you have to follow some special rules. And if you take these rules and you put them into two categories, they're basically about email protection. So there's some configuration you need to do on your configuration of your email. Basically, mostly in inside of your DNS. And there's some good write ups by some partners in the Rock community who have really addressed what does that really mean. So reach out, find those. And so that that revolves around things DKIM and some other things. But it's pretty easy. , just go and make some changes to your settings and you you you'll be good. The big one though is the other bucket, which is what they call the one click unsubscribe. Now this is a good idea. It makes unsubscribing from email super easy and, , really improve that that user experience. Unfortunately, they're being very guerrilla it, and it's , you have to have it done. They announced it, I think in sometime in October and in February, right now, they're going to start to require it. Now, they're moving at a brisk pace, I think unreasonable by many people's standards, but at the same time, if you don't, nothing happens. That's true. So I think it's very unreasonable, but at the same time, I get it. There's things that we have to do in our community that some people would think would be unreasonable, but if you don't do it, and if you don't put it in a certain way, it gets this, it's never going get done. I think though, that the gorilla, a real gorilla, sometimes the bark is worse than the bite. Now what they're saying publicly, which we have to kind of go by that, and I think they're going be kinder behind the scenes, but they can't say that. Is it in February they're going start warning people if they don't have this? How do about the warnings? They don't really tell you a lot about that either. What we would recommend is that you make sure that you're using the Google Postmaster tools. That's probably where those warnings are going to be showing up. A lot of this has not been insanely documented. It's not clear, but that is the place that you probably want to go to look for those warnings. Now you might be going, what is Google Postmaster Tools? Great question. It's a great set of tools that they provide you where you can start to peer in and see what your spam ratios are, percentages are. So if you're kind of in this problem, 3%, if you have more than 3% spam. And you have some visibility into that. It's just a good thing to have no matter what. Again, there's a partner who has a whole blog post on how to set that up and get it configured. It's pretty easy. It's a little intimidating as you go through it, but if you follow the guide, the steps are pretty easy. So immediately go do that. Now there's other things that, will we have access to that through Into Rock? We don't know. Will we have access to that through Mailgun or SendGrid? We don't know. Those are things we're still researching. So keep your eyes on the blog, keep your eyes on the podcast. As we know more, we'll be sharing that. But a lot of this is people moving really fast, not sharing a lot of information, and we're trying to keep up. But the big thing is really those features that you need, the one click unsubscribe. Yes. So to enable that feature within the Mailgun user experience, we have to provide some more details in all the emails that we send. Email's a little bit web traffic in that as the email travels through the internet, there's little headers on top that no one sees that gives it a little bit of metadata about the email. And there's some new metadata items that we need to plug in some very specific values into those. And when we do, when Google gets the email, puts it into the user experience for the person, they can enable a little button, that's their button, not our button, outside of the email that basically says unsubscribe. And when you click that, it'll automatically and auto magically unsubscribe you from that email. So they didn't give us a lot of time to do this, and they didn't give us a lot of details, but we've done a ton of research and a ton of development and we think we have that all right. I mean, there's no validator for this. That would have been nice if they had a validator thinking about that. That would have been really, really nice. But that is in sixteen point three. So it's important that you get to 16.3 if you fall into that category of sending more than 5,000 emails in a day. To Gmail, right? To Gmail. Because they only see Gmail. Yeah, true. So if you're a church of 5,000, you probably don't have all 5,000 of your church members on Gmail. Right, but do consider if your attendance is 5,000, Yeah. You might be sending 15,000 emails. So Right. Right. Just go go through your communication history, look for emails. If you if you're sending over probably seven to 8,000, you might want to be interested. If you're under 70,000, don't worry about it. Although eventually this will probably be rolled out more widely, you do need to. Couple questions on that 16.3. Okay, are you back porting this to 15 to 14? And the answer is no. We cannot back port all these major features to every version. This is why we have versions. This is why, I mean, whole version system exists is that new stuff comes out on new versions. We've been very kind in back porting bug fixes, security patches. That's typical, we can do that. A really teeny tiny micro feature, if a church is funding it and they need it on old version, sometimes we do that too. But for a feature this, so we simply cannot backport these two other major releases, which is another really important reason why you need to stay up on these versions. Now you might be saying, Tell me more about this timeline that Google's put out. So from what we can gather, this kicks in in February, so that's welcome to February. Here we are. At this point, you should only be getting warnings though. Nothing bad should be happening. You should only be getting warnings. And again, we don't know where those warnings are going to show up. We imagine that's going to be in the PostMaster tool. I can't imagine they would not not be in the PostMaster tool. We're gonna go get more guidance on how we can get that through Mailgun and get that possibly into Rock, or at least be able to point you to the Mailgun logs that will tell you that. So for information coming on that. In April, what they're saying is they're gonna start to lightly block this. So if you go over those limits, what they're saying is 25% of those emails will be considered to start lightly blocking. And what they call lightly blocking, which doesn't make sense to me, they're gonna take a percentage of the 25%. But what they're saying, a small percentage of the 25% will start to get blocked, which I don't know why they say a percentage of a percent. once you just, I don't know. But in June, supposedly full block. Yes. Now my opinion, this is straight up opinion is they'll probably be kinder than this. You always communicate stronger than you plan. But majority of email platforms cannot keep up with this pace. Google can't be a good email platform if they're consistently throwing everything into spam or blocking it. The people were revolt and they don't want that either. So I think it's good that we follow these guidelines and use that as the worst case, but also I don't think we should overreact. Simply put, there's a million other products Rock in this situation, and there's absolutely no way they're going to be able to respond even in 2024 to these requirements. It's going to take 2025, '20 '20 '6. So we're not being that. We're taking this very seriously. We've been moving at a very brisk pace. The amount of code and engineering and thought that's gone into this is mind boggling. So when you think at the end of the year, Oh, what did all you get done? Most of the stuff we got done is stuff that no one even knows and we hadn't even planned. Right. That's so true. Isn't that fun? Which is another good reason why when someone says , Hey, where's the roadmap for Rock? It's , right. It will be out. If only it would be easy. Because if we were strict by a roadmap, this would have gone on the roadmap to be considered in October. We'd probably get to it sometime in end of this year. Yes. Because we have to finish the roadmap. We gotta be, follow the roadmap, the predictable roadmap. So again, that's why we don't do those things because they end up to be more lies than they are well intentioned lies. But I think any product that's trying to be innovative and responsive, a firm roadmap is basically a lie, unintended lies. So that's what we know about Google Bulk Sender. But we had more fun in January, didn't we? Oh, yes. January was lots of fun. It seems every month has its own challenges. That's true. So again, another thing that kinda takes time that no one ever thinks about is bot attacks. The Russians. Which I think is very interesting if you considered what our world could be if we didn't have to worry about viruses, bots, spam. Wow. I mean, could get so much more done. Worldwide productivity would skyrocket, but that's not the world we live in. So if you hadn't heard, several churches were hit by a bot attack in January. And what these bots were doing was basically putting new records into the database through mainly through the new registration block, the new account registration block. Some really interesting details about that, which we won't get into, which makes it just interesting that that all happened on the same day and on two different technology platforms within our platform. But anyways, so what happened is these churches had thousands of people added to their database. All obviously not real people. It's pretty clear and predictable and pretty easy to report on, a little harder to delete. And so a lot of people had to go through and clean that up. So on our side, what we've been doing is trying to figure out, okay, how do we get the CAPTCHAs to block that? Now some of the older web form blocks simply didn't have CAPTCHA. Ironically, the CAPTCHA for Obsidian, the next gen platform, was put in and was gonna be a part of sixteen point three. So the work was already done, but it wasn't available. But in analyzing those attacks, created the script for it, obviously, it was humanly done. They were looking , how do we actually go around the UI? So I think what we had in sixteen point three probably would not have prevented it, but actually seeing it, we actually added an additional guard to it. So it will take that in account. And the interesting thing is we actually added that in a way in the future, we'll be able to add that to all the blocks, a certain level of what we're calling bot guardian to them. Now this is something that's not completely done yet. So just to level expectations, but it's something we're actively working on. I think it also led to some other interesting insights around what we might be able to do in the future in terms of rate limiting in a more intelligent way based on country codes. So did a lot of research onto that. And it might actually make some changes into our geolocation features, where we take IP addresses and turn them into addresses. Right now that requires a service. We might be able to get rid of that service and do it in real time. So the request, on the request in Lava, you could actually say, If this person is in Sweden, then do this, do something. So some cool new features might come out of it in the long term. But not exactly expected when we were planning our January for this year. For sure not. But I think as it relates to that, I think it's good to know that if you weren't hit by it, say a small prayer of Thanksgiving, but know that we're taking extra steps to prevent that. I think a few things we can learn from this though. And let's talk about best practices that went over really well last time. Yes. So let's take another swing at that. The best practice here, and this was one that was on our roadmap of best practices to talk about. And I think we actually talked about two today. One is CDNs, content delivery networks. You need one. It used to be , Oh, it'd be nice. And then it was, Well, if you're big, you might need one. These types of bot attacks, it really shows that this is another reason why you need a CDN. Now we might be able to add some features into the application to help with this, But that technically is the wrong place for that level of that of logic. So if you've if you have maybe a formal education in in technology, one of things that you learn about is the OSI seven layer model. That talks about how where does logic belong in any type of technical application? The levels start at the very bottom, which is the physical layer, which is the copper wire or or fiber optic wire that the Internet uses or networks use. And it goes all the way to the top to the application layer, which is our our code, our c sharp code. And there's all these levels in between. This type of traffic shifting and filtering and belongs at a lower level. It doesn't belong in the application level. We do caching there. We do lots of things to make Rock faster, but this type of thing really belongs in your network infrastructure within the CDN level. So Rock shouldn't have to be worrying about, I got all this stuff to do. I got to figure out your data. I got to get your data. I got to know what that means. I got to trigger this workflow. And now I got to watch all this traffic too. What else do you want me to do? That's the network infrastructure's job to go, Oh, wait, I'm seeing some traffic here. It doesn't look right. Let me just do some stuff for you. And Rock's , Thank you, I got my hands busy over So the CDN is one technology that can help with that. And the CDN that I'm most familiar with and that we use to help with churches actually has a little one click feature, what country do you want to block today? Oh yeah, okay, Norway. Yeah, we don't them today. Block them. Now that's a kind of a primitive way of blocking. There's a more advanced way, they're called web application firewalls, which are much more using heuristics and looking at the traffic and saying, Oh, well, it's from Russia, so strike one, but I'm not going to block it. Oh, now it's spamming the server. Oh, strike two and three, you're out. And so you might think, well, this is a lot of technology and technical speak. Well, welcome to digital ministry. It's as if you're in the band and you're , well, the audio engineers, if you're worship teams, they know a lot of stuff that I don't want to hear about. But if they didn't do it and they didn't do it right, I wouldn't have the same experience. In fact, I'd have a very different experience. And so that's just the nature of the beast. Now, you don't necessarily have to know it yourself, but you need to get and engage with someone who does. And so I think CDN's highly important. Another thing though, I said two best practices. The other best practice, and I'm very passionate about this one, is read your IIS logs. There's just a gold mine of insight into those logs. I read IIS logs, usually not my own. I read other people's IIS logs because usually there's a problem, and my go to is to read the IIS logs. I thought it was interesting in this bot attack that lot of people were doing reports in SQL, lot of people were looking at lot of things, but there weren't a lot of people looking at IIS logs. And that was my first thing, was , give me the IIS logs. I need to see the IIS logs. And by looking at the IIS logs, a lot of insight was gleaned that I don't think people knew about until we got to the IIS logs. For instance, that they were actually jumping over the UI and making requests directly back to the backend. So you might say, well, how do you determine that? Well, every web request has a different method. As you go to a webpage, it's a GET, that's the method, get me something. But as you go to actually make a data update, it's usually a post. So that's , Hey, go put this in a database, post this to the journal in the database. Well, you look in the IAS logs, there is zero gets and they're all posts. So for a bot, you're , how did to post that? You didn't even go get to the UI to get it. So that immediately told us that this was a different type of attack than I think most people were thinking. And that's why reading the IIS logs is so important. And I wouldn't wait till there's a bot attack. In my opinion, every organization should look through their IIS logs at least every other month, maybe every month. Now you might think, well, okay, well, files are huge. What am I looking for? Well, that's a good question. Personally, I think there's a perusal of the log, a scanning of the log that's super important. So early in my career, I was more mainly Unix based. And so in Unix, there's a tool called cat and then a tail. There's two command lines. And when you tail a file, it's zipping by. If you're ever watching one of those hacker movies and all this stuff's going by, that's basically recreating a tail with a log file system, you're seeing it in real time as it's going. And you could be , Well, you can't read that. And it's , Well, you can't, but your brain starts to find patterns. You're , Oh, what's that? You establish a baseline of what's normal too. Right, you start to get a feel for your logs. for instance, if you send me your logs today, can within a few seconds tell you whether you turn off your check ins or not. It's a good practice to turn off your check ins during the week. Why? Well, saves power, but it also puts a lot of load on your Rock server. And it's easy to see that traffic because they're just nailing your Rock server. There's a lot of things in the log and you can see the pattern just with your eyeball. You can't read it, but you can see the pattern , oh, you got your check ins on. But in looking through this, I actually found another problem with a specific church where maybe their mail gun was doing some unsuspected traffic from mail gun. And so maybe there's a configuration issue there or maybe they just sent out a humongous email. I don't know. But definitely you could see something's not quite right with mail gun configuration. Now that could have gone on, that could be going on for days, weeks, months, or it could maybe be the first time, but that's an insight you need to track down. And you only get that in the logs. So if you have a partner, ask them, Are you looking through my IIS logs? They should be. And if you have an internal team, you should put that on your, every two months, you take your car to get an oil change, you should just check through your IIS logs. Now you might say, well, how do I do that? The easy part is just open them up and just scan through it in Notepad, and just run it real quick up and down, scroll and just look for patterns and then stop and then start going through and looking for different things and different insights. That's helpful. There's not a lot of great tools for helping you parse those files and understand them, so much so that it frustrates me every time I have to go do it. There is one tool I use that's mainly It's made just for that, but I swear it was made in the '90s and it's very slow and very tedious and hard to use. So every time I have to use it, I'm a little bit frustrated. So this time I started, And over the last couple of times I've looked at it, I've tried to start creating some tools. So on my own time, I create a little IIS parser that will turn them into comma delimited valued files, CSV files, because the IIS log format is a little strange. It's not very easy to parse. So I created a sole utility. I'll probably post it out there for somebody if they want it. That's unsupported. But it'll take a whole bunch of log files, convert them into a single CSV file, and it'll actually append a whole bunch of information onto it. So it'll append in what country it came from, what state it came from. It'll add some date fields that makes it a little easier to do some analytics on. And it'll also clean up the user agent, so it tells you what platform it was on. And then I'll also share a very, very basic template that you can use Power BI to bring in that CSV file and start to do some reporting with it. You might say, well, I can't afford Power BI. Well, you can just use the free one. Just download the desktop version and you can use it and it's a starting point. So I'll post that at some point on Twitter. So just follow me there and I'll tell you where it's at. If it helps you, great. But it helps me, I'm looking forward to parsing my next IIS log. Well, kind of not, but when I do, it'll be - More than you would have looked forward to it. Right. Best practices, CDN, reach out if you need more information on that. IAS logs, look at them. I find them actually really fascinating. I always leave with some interesting insight. Another good thing you can see in there, four zero four errors. How many four zero four errors are you getting? And you need to go clean those up, little things that. Alright. Well, those are some very good best practices and helpful for people that may not have their feet in that world or in those waters every day. Consider if who on your team might be the person for that. Do you have a partner that helps with that? But don't ignore it just because it isn't necessarily in your lane. So great tips. Thanks, John, for that. Yeah. So Rx coming up. Rx is coming up. Yes. So it's always coming. It's either coming or here. And it's not quite here, so it's coming. We're really excited about it this year. Definitely pay attention to that hotel. We're gonna be at the same hotel we were the last couple of years. Now they are just finishing up some renovations. It's gonna be an incredible space. And the hotel is selling out, so it's already more than half full for our events. So if you don't have your room booked and you don't wanna walk across the parking lot from another hotel, you wanna experience that all day into the evening community experience. Make sure to book those rooms there. What's the average temperature in August to walk across the the parking lot? Oh, it's gonna be boiling. At the asphalt level? Yeah. Probably one twelve. Probably on asphalt. Or higher. Well, if you're on asphalt, but Yeah. Hard to measure that. Yes. They do fry eggs on asphalt sometimes out here as a little gig. Wear heat resistant shoes if you are at the other hotel. Don't do that. Just get your hotel room. But they are going quickly. You might not already have that on your agenda at this point in the year, but it should be. Additionally, we have some great discounts that are available. If you're coming in a group of five, seven, or 10, there are group discounts available. You can find a link in the show notes. And if this is your first RX event ever, we do have a discount for you as well, so reach out and let us know. We're excited to bring the community together for this again. And it is in August, and we're halfway there through the year. So let's make sure and rally. And don't forget about that hotel. Don't forget about your tickets. And make sure that the right number of your team are coming because this year we're having some special experiences for people in the areas of finance and generosity. If you're new to Rock, you're exploring or recently there, discipleship and engagement, and a lot of many other incredible experiences. We also have classes coming up. And, again, these are ones you might wanna share with other members of your team. Finance and check-in. So these are special virtual classes dedicated just to those subjects and the people that use those tools and rocks. They're excellent. May not be for you as you're listening to this podcast, but could be really helpful for some other members of your staff. So don't forget to invite them and pass that along so they can have the tools and training they need to have an excellent Rock experience. Thank you so much for joining us for this Rockcast today. We appreciate your listening and tuning in. Make sure you follow us wherever you get your podcasts and don't forget those best practices. Write them down and make them happen. Thanks for joining us. Do a church that loves the idea of using Rock but hasn't taken that leap yet? With managed hosting, churches of any size can get access to Rock's amazing technology, hassle free. With just one click, Rock's managed hosting removes the roadblocks that might stop a church from switching to Rock by making the process simple. Churches get the ease of a SaaS church management system without losing any of Rock's powerful features. Are you ready to take the next step or share with another local church? Visit Rock r m s dot com slash hosting today.