RX 24 - Ten Tips For Better Workflows - Steve Klein

Transcribed Content

Let's all just give a warm welcome to Steve Klein, he's gonna give us some tips on workflows. Need some hydration there? Hey, guys. Yeah, I wanted to start off with just a quick introduction, as we always have the introduction. So I have a small team that's responsible for kind of our digital products at Liquid Church. Liquid Church is a church of seven campuses. And just for context, we're in New Jersey. We have weekend attendance of about 4,000 or 5,000 people, so kind of like a normal rock church, I guess, or kind of in that area somewhere. We migrated to rock two years ago, so we're kind of new to rock, but at the same time, I've learned a few things along the way. And then personally, my wife and I have three boys who are all thankfully out of the house, and so we're enjoying our empty nest. I think I have a picture. Yeah. So that's my wife, that's my three boys, and that's the Christmas sheep. All right, so yeah, my disclaimer. So I'm not I don't want to disappoint anybody. I'm not the workflow expert. I'm not sure I'm not even a workflow expert. I'm sharing my pain and experience with you and some of my somewhat well founded opinions. But you may have your own opinions and you have your own context. So that's kind of the disclaimer. The other thing too is I noticed after I wrote the whole presentation that I used the word workflow when I really should use the word workflow type like in almost every slide. So I didn't change it. And when I say workflow, a lot of times I mean workflow type. So just mentioning that, so don't send me emails. And then lastly, these are in no priority order. So let's dive in. The first one I have is persist judiciously. And this one I said no priority order, but this is one I do feel kind of strongly about. So we've suffered because of this a little bit, and maybe you've run into some of these same issues. Workflow data can fill up your database rather quickly, especially if you turn logging on, if you leave your workflow persistent when it doesn't need to be, when you have a bunch of active workflows around, it can affect your database size, but it can also affect your performance. So my suggestion is once you have a workflow working, consider unpersisting it. So a lot of times a workflow creates some other entity, like a connection request, a group member, something like that. And that's your log of what happened. You don't need the workflow log anymore. So that's just a suggestion. Also, your workflow includes a form I'm sure a bunch of you have run into this where you don't actually need to persist the workflow globally. You can do it with a workflow persist action. But just to mention that in case you haven't seen that, the issue there is that every time somebody lands on that form, it's going to run the workflow. So if you persist the whole workflow, you're getting those kind of empty form captures, which are really not that helpful. And then in terms of workflow settings, when you initially create a workflow, Starting pretty basic here, you guys have hopefully seen this screen. But one thing to point out is that automatically persisted is checked by default. So if you just kind of like create a workflow and you go and do your thing and you leave it there and runs in production, it's persisting. So you're going to have to uncheck that if you don't want that. And then just further down, there's kind of a little panel with these advanced settings. And these are kind of roughly my recommendations for how to set up most workflows in terms of these last three guys. And actually, I guess logging level as well. I'm not a big logging fan. I feel like most things you can debug without logging. So you should maybe try that instead of turning logging on, which uses a lot of space in your database. Your maximum workflow age is how long your active workflows will hang around before they're completed. So it's good to have some number there. Your completed workflow retention period is how long your completed workflow is hanging around before they're archived. And then finally, the log retention ties to the logging, how long that's kept around. These are all blank when you create your workflow and stuff is saved forever. So just buyer beware. Okay, process workflow job. So yeah, I just want to touch on this. Actually, it was mentioned in one of the sessions, I think, already. The process workflow job runs every ten minutes, which should make you pause. It's like a lot of times a day that thing's running. And, we've run into situations where we had too many active workflows and this job was crunching through these active workflows workflows with errors. It'll kick an error every time that active workflow runs. So my suggestion is to kind of look at this. I check it, I would say, every three to six months. Your mileage could vary. But take a look at how this thing's running, how long it takes to run, and what errors it's kicking out. And then take the time to clean up those errors. Like find them in the workflow, clean those up. Neatness counts. Guys are like, oh my goodness, this guy just has opinions. I'm an old guy with opinions. That's I mean, hopefully some of these are going to be helpful, or at least one or two will be. And at the end, I'd love to hear your opinions as well and your thoughts about ways to do this differently. But one of my feelings is that you should have either an explicit or implicit style guide. So we don't have an explicit one, but I do kind of have this as my style guide so that at least within a workflow, you're thinking about how you're naming things and how you're structuring your code, how you're commenting your code, things like that. It would be amazing if you have a team of people working in workflows. If everyone's doing it the same way, that would be great. But at the very least, if the one, you know, that one workflow is written the same way, it just makes it so much easier when you go back to it, try to figure out what's going on. I mentioned adding a description. Who attended the AI presentation by Brian? Couple of people? Oh my goodness. I highly recommend that. Talk to Brian any chance you get. One thing he came across very recently is a way to auto create that description, which I would recommend you hound him for a recipe for that. I think that that's amazing. And he demonstrated it in the talk. And so even if you have to manually create the description, put something there so that later on you understand what was my thought pattern when I created this workflow, why did I create it, that kind of thing. And then my last one, yeah, once you get the workflow working, it's tempting to get to the next 10 things on your list. Just take a little extra time and clean up the workflow just for the next time you've to go in and look at it. So that means if you created attributes you're just trying, you have an extra activity in there that you're not really using anymore, actions, that sort of thing, this is the time to delete that and then retest and then walk away. So keeping things neat. All right, the Lava Tester. This should be an easy one. Who's used the Lava Tester? Yeah, that's great. It's a plug in, so you can find that in the rock shop and get that into your environment. I mean, my personal preference is we have it in our dev environment and not in production because it could maybe impact production, doing what it's doing. But I'd strongly recommend if you don't have the lava tester to install that. And the other thing I'd say is get in the habit of working out your lava in the lava tester. I think sometimes we get like I know I get I get like, I know this. And I just write like 20 lines of lava and then I button up the workflow, I try to test it and nothing works. And I have a little typo somewhere. So it's so easy to figure that out in the Lava tester. You dump that develop the code there. You test it over and over. You're going to test better in the Lava tester too because you can test so quickly. You'll try different cases, that kind of thing. And then once it's perfect, then put it in the workflow. You'll be happy to do that. You'll save a lot of time. And I think you'll test better because of that. The other thing I'd mention is, although this is not necessarily about SQL, same thing for SQL. We use Azure Data Studio. Anyone use ADS users? Okay. A little less. Okay. But yeah, if you have SQL in your workflow, same thing. Get a decent client that you're comfortable with and then write the SQL there, test it there, and then dump it in your workflow. Same idea. I'm so thirsty. One second. Yeah, so I mentioned Magnus as well, a Triumph plug in. This is a way to kind of protect access to your database if you're going to use something like Azure Data Studio. So think about using that plug in. And then just a side note, I do love the model map. It's the same kind of thing. So rather than guessing at what you thought the property's name was or the lava attribute, look it up in the model map and get that right. And yeah, I always have the model map open. Okay. The other thing so yes, so developing using the Lava Tester. You can also debug, of course, using the Lava Tester. And one thing I didn't realize initially is you can actually dump a production workflow that's run into the Lava tester and then pull the data out. So rather than kind of get under the covers of a production workflow and start messing around with something that's in production, you can look at the data that's coming out and then start to interrogate that data and understand what happened without changing the workflow, which could be super valuable. I have a really simple example. So we have this baptism interest workflow. I have a particular instance of it that I ran. And so I just dump this in the lava tester as a quick, simple thing. I'm grabbing in that top line, I'm just grabbing this attribute called candidate. I'm putting it in a person variable. It's an object. So I have a person object that was the candidate from that run of the workflow. And then as a of a simple example, I'm just dumping all the groups the person's in. So if I need that for debugging, I have it now. So let's see what it does. So I was the candidate, surprise, surprise. And that's actually a partial list of my groups, but you get the idea. So you can essentially take a completed workflow and pull the data out after the fact, which I think is kind of cool. Okay, keep workflows simple. More opinions from Steve. Okay, my feeling is workflows should be single purpose, that overly complex workflows are really hard to understand and maintain. Has anyone experienced overly complex workflows being really hard? Thank you. Good. I don't feel alone anymore. And also, they're hard to edit. You get into situations where it doesn't load that well even in the editor because of weird kind of things that we can talk about later. So yeah, consider refactoring. So if your workflow is longer or bigger than you're comfortable with or needs to be refactored, consider rewriting that and maybe breaking it out into two or three different workflows. You could even maybe break out common features into a helper workflow, which I think I'm going to talk about a little bit too. And yeah, I talk about saving workflows. Has anyone had the fun experience of writing workflows for about like an hour or two and then it crashes? You try to yeah, exactly. So yeah, don't let that happen. Just save, save, save. But yeah, if you have a simpler workflow, hopefully you're not going to spend a huge amount of time writing it so you don't run into this situation. Okay, so my 18 year old intern said I had to put this red flag thing here. It's a cool meme thing. Red flags? Anybody? Okay. But yeah, this is kind of like more guidance. So I would say if your workflow has more than 20 or 30 attributes, if it has more than 10 activities or any of those activities has more than 10 actions, just maybe a flag, if you will, to kind of think about refactoring. It doesn't mean that you have to. It just means maybe you're getting to the edge of something that should be a little bit smaller. And then my personal one, which is super controversial if your workflow includes delays. So I've been in a couple of talks and people are like, oh, I use delays for this and that and the other thing. And I'm not saying that you can never use a workflow delay. I'm just suggesting that there's a lot of times you can get away from the workflow delay. A friend of mine was talking about a quick case where there was processing being done on Sunday morning that's super critical, and they didn't want to have the rest of the workflow run during the critical time when check-in's happening, so they add a delay. And then later in the day, the rest of the workflow runs. So you could possibly do that by breaking that into two workflows, have the critical piece run, and then just schedule the other piece for later in the day just as a thought. So how to get away from delays. I mention that because I've seen situations where you have active workflow and you're like, why is it active exactly? And what is it doing? What did it do? That sort of thing. Try to get away from active workflows if you can. Okay, helper workflows. Yeah, I had mentioned this before. If you have kind of a common thing that you're doing over and over again, consider breaking that out into what I call a helper workflow. A lot of advantages here, but essentially you're writing that and testing it once. And then the calling workflow is less complex that way because it can call this helper workflow. And we'll just go into a quick example. So we have a volunteer onboarding system. And we have these we call them watertight training quiz. But each of the ministry areas has their own quiz, which we built as custom workflows. But at the end of those custom workflows, they all have to do the same thing. They have to send the quiz taker an email. They have to send all the ministry leaders an email, status updates, things like that. So we broke that into a separate workflow. And there's several ways to do this. What we did was we just used the kind of right in the middle here, the workflow activate LABA command. And you could see that that takes some fixed parameters, like you can pass the workflow name, the workflow type, and so forth. But you can also pass attributes. So we're passing the connection request to this helper workflow using this Lava command. So let's see what that looks like. And this is my little if you're alert, you notice I went to tip six. But yeah, this is using GUIs and not IDs. Here's an example of that. So we're passing the GUID for the connection request in this workflow activate because if you've read workflows in Lava, part of the workflow, I guess the Lava documentation, it says that to instantiate a connection request, you need the GUID for the connection request, right? So just like you use it in the Lava action, the Lava run action rather, Same thing for if it's a query string or if you're doing this sort of thing. It's all consistent in Rock, which is super cool. So you're passing this and instead of getting something in that then you need to manipulate and say, oh, I've got this ID. I've got to figure out what to do with it. You have the actual connection request. And the other advantage is by not passing, especially in a query string, an ID, you're not revealing stuff about your system or your workflow that you don't really want to reveal. So you may have heard this before, but if you're passing a person ID, there's going to be somebody who's going to be wondering what the next person ID does, right? But if you're passing a person alias good, it's hard to understand how to get to the next one or play around with it. So curious people, even bad actors can be you can prevent some of that stuff that way. Yeah, and this is just the example of this in a query string. I'm really like hammering home this good thing. But it's all consistent. So whether it's that lava run action or the example I gave before at this query string, it's all the same way. So yeah. All right, error checking and safeguarding. Yeah, there's a colleague on my team that kind of got me into this. So especially when you're letting people get anywhere near what happens when the workflow starts to run, it's helpful to kind of check your assumptions. So in this case, this is that same case that we've been talking about. You notice that we had a query string that had that connection request equals GUID there. And it's going to run perfectly every time because there's an email with a link. And when you click on the link, it brings up that beautiful URL. And then when they hit Enter, it just works fine. It comes up with a form and the connection request is already populated, right? Well, only if the user doesn't delete it or I don't know what they do. But I'm sure you've run into this where it's like, it should have worked but it didn't work. So just test your assumptions. In this case, the first action I have in the first activity is checking has a filter is the connection request blank. And then if the connection request is blank, I just give a helpful little message saying, please run the thing that we gave you to run. Or I think it said nicer, but go back to your ministry leader and get a fresh link, basically. And you could do this with any, I would say, entity that you're not sure about as you start your workflow, just a suggestion. The other thing that's kind of related to this and again, another I'm really seeing a lot of opinions here. So my opinion is that you should consider creating landing pages for your workflows rather than letting people just run the workflow itself. Do people do this mostly? Do you create landing pages for forms? Yeah. Okay. This is great because you can improve and control the look and feel of your stuff. It can be more consistent that way. Also, it can hide these underlying details that we keep talking about. So you're just getting this pretty landing page and you don't need to reveal these URLs with like who knows what's going on in there. Oh, yeah. Guys, you need to grow your lava love. How many people love lava? How many people? Okay. All right. Next year I'm hoping more of you love lava. Yeah, it's one of these things where I didn't love Lava initially, I don't think. I think I developed more love for Lava, maybe too much love for Lava by reading the documentation. Who enjoyed Alicia Marble's song about reading the documentation? Yeah. So yeah, I love that one. And guys, I'm in this document over and over again. I've read it cover to cover several times, like all of that documentation. But I would say if I'm working in a workflow, I'm back in there every day anyway. Because I don't want to, again, assume that I understand something that I may be just a little bit off on. And a little bit off is 100% off in Lava. So you need kind of make sure that you're doing it right. Yeah, I'd just suggest some things to kind of try to grow your skills, understanding the difference between entities, database properties, attributes, filters, where they fit in your Lava, where they fit in your workflows. We talked about this a bit earlier. There's that workflow in Lava page that shows you all of the entities and how they're populated. That's truth what's there. And if you don't do it that way, it won't work. If you do it that way, it will work. So that's good to know. And then finally, to try things in the Lava tester. I've mentioned the Lava tester before. The only thing I love more than Lava is the Lava tester. So when you see something that's new to you or even looking at the documentation, I'll grab something I'm trying to work on in the documentation, like an entity command, dump it in the Lava Tester, and then make sure it does what it says it does, and then play with it. You know, like add more conditions to it, add filters, build something bigger. And quite often I'm building stuff that way. I grab something from the manual, put in the lava tester, and just build it out from there. All right, number nine. I've wasted hours of my life because I didn't. Section. I have just a couple ones here. Maybe you've run into them. I don't know. We'll find out. Yeah, capture who's run into this one? Failing to capture entity in the first action of your workflow. If you don't understand this, that's Okay. You may trip across and say that strange guy on this stage talked about this thing. Yeah, so the issue here is that if you're passing an entity into a workflow, I think of that entity as being kind of like permanent, that first action, the first activity, and then it kind of wanders away over time. It could still be there in the second action, which is super frustrating. But it may not be, right? And people way smarter than me can explain why that is. But the tip for you would be to capture that entity in the first action. In this case, this is the first action of the first activity of a workflow that's being called from a registration. So registration is complete. It kicks off this registration workflow. And that's where I set the entity. Pretty simple one, but if you get it wrong, it can be super frustrating because, again, it could work sometimes and not work sometimes, which is the worst. The other one I have is setting processing interval. Do you guys remember me talking about delays? Anybody delays? Okay. Yeah, another reason to kind of hate delays. So when you build a workflow from scratch, you're getting a processing interval by default of four eighty minutes, which is kind of like eight hours, right? So usually your delays that you want to build into a workflow are shorter than that. Keep in mind that you need to change this processing interval. This is saying that every time process workflows runs every ten minutes, it's going to kind of look at is it time to run this active workflow. And it'll look at that delay. If it hasn't been that long since the last time it ran, it's not going to run. So those kind of go together that way. And I've seen in Rocket Chat a few people get stuck with that one and I definitely got hit with that one a couple times as well. So make sure that you're tuning that if you use delays, which I don't recommend. My thing stopped doing things. Hold on. There we go. All right, so master tricky data types. These are tricky data types for me. Maybe they're not for you. I put them up there and like, they're not that tricky. But I've gotten tripped up a little bit. So I don't know. This might be helpful. So who loves Booleans? Anybody? Oh, wow. People like Booleans. Okay. You know, I got to the point at some point, and maybe I'm still here, where I avoid Booleans. I'll be honest. I'll throw an integer out there, zero equals false, one equals true, this kind of thing. I know. And they let me on the stage. It's crazy. But yeah, I do still have to debug workflows that have Booleans in them. And when I do use them, it's helpful to remember these little tips. It's lowercase true, lowercase false works kind of everywhere. That's for both filtering and assigning workflow attributes as well as in the LOVA itself. That's what I mean by checking conditions. The other little tip is to think about using that as Boolean filter. That can really help you. You get a quantity in, you just filter with as Boolean, then for sure true and false will work. And then finally, multi selects and single selects. These can be a little tricky as well. Essentially, they're going to be lists of value and text, right? So it's these couplets, if you will. That's what all these boil down to. You're going to want to use the value everywhere. That's for filtering. That's for assigning. In fact, with a multi select, you can use a comma separated list of values. And that will populate your multi select, which is good to know, like in a Lava run action. And then, yeah, I don't know if you've tried this before, but it can be really powerful to initialize your single selects and multi selects in your workflow using Lava or SQL. So anyone tried that? Yeah, a couple people. So that's something to explore. You'll see like you can do some pretty cool things that way and essentially have custom things showing up in your forms and so forth because you've done this SQL or Lava that's driving it. Along those lines, one trick I use is to sometimes pull in like current person because it could be very tricky, like what do you put in there to kind of really customize it. If it matters who the current person is running the workflow, you can include current person right in your SQL or Lava as you initialize that attribute and you can get like a custom thing that way. Yeah. Okay, I finished my race through my slides. Yeah, any questions?