Description
Flows are an incredibly powerful type of metadata but they can also be a pain to deploy, causing bottlenecks, headaches on release day, and end-user frustration.
Join Ben McCarthy (Founder, Salesforce Ben) and Tom Smith (Product Manager, Gearset) to hear about common Flow deployment pains, best practices to avoid them, as well as a sneak peak at Gearset’s Flow Navigator.
Learn more:
Transcript
Hello, everyone, and welcome to another Salesforce Ben webinar, this time in collaboration with Gearset, who are some very good partners of ours.
And we can see there's loads of people joining at the moment, and we'll just, wait until the top of the hour just until most people have dialed in.
It's been a really popular webinar. You'll be no surprise to hear it's about flow, so, of course, it is.
Let us know in the chat where you're dialing in from today.
I'm based in London in the UK. Tom, how about you?
Down in Cambridge, so just north of London.
Ah, very nice. Was it pouring down with rain today? Because it was down in London.
Like Oh, yeah.
We've had all kinds of weather in the past few days.
Yeah. Classic English summer.
Yeah. I think it's my fault. I think I bought a couple of pairs of shorts a few weeks ago, so my fault that the sun's gone.
We'll blame on you.
Alright. Let the top the hour.
I can see people are still joining, but, the numbers are starting to flatten out. But so maybe we can get started and and, yeah, so more people can join. So thank you very much for spending some time with us today. Today, we're gonna be speaking about how to deploy flows like a pro with Gearset, who are definitely the pros at deployments and DevOps in the Salesforce ecosystem.
And I think we all know by now how important and powerful flows are in in the Salesforce ecosystem. You know, they've Salesforce put so much effort into them over the past few years, and they really have become the the default automation tool, which kind of allows you to do as much the developer could using Apex. You know? Not exactly the same, but but but getting there.
And something that we've discovered recently, we've got our Salesforce developer survey coming out this week, which has got loads of great insights about, how Salesforce developers and and architects are are working in Salesforce, what what their what they're struggling with, what their issues are, things like that. And we asked some questions around declarative versus programmatic and which kind of tools developers were using. And, actually, what we found is thirty four percent of Salesforce developers are using an equal mix of programmatic and declarative tools. And when we dug a bit deeper into the types of tools they were using more over the past twelve months, I think Flow was about, like, eighty five percent of people said they've been using Flow more in the last twelve months.
So it's really interesting to see that actually developers are really getting on board with using Flows, of course, as well as Apex. You know? They're using equal mix. So, yeah, some really interesting changes in in the Salesforce ecosystem at the moment.
So let's get started.
So just to introduce myself, my name is Ben McCarthy, founder of Salesforce Ben, and I'm gonna be your host for today. We're gonna be having a q and a at the end of the session. So if you've got any questions, feel free to drop them in the, q and a box, or or the chat box, and we'll get around to as many as possible at the end. So, Tom, I'll hand over to you and see you at the end.
Thanks, Ben. So hi, everyone. My name is Tom. I'm a product manager at Gearset. I've been working in the Salesforce DevOps space for about six years now and in the wider dev DevOps space for about ten years.
So today, we're gonna talk about flows and best practices for deploying them.
I just wanna recap to start off with what flows are and why they're important. I'm sure most of you know this, but just to make sure we're on the same page, let's do a quick recap.
So flows are a way of building our business automation through clicks, not code. You're probably familiar with flow builder where we can drag on the elements, connect them up, and we don't have to write any codes to what we need.
So we might have a flow, for example, that says when we change the primary contact on an account, let's look at all of the open opportunities for that account and set the stage to needs analysis so that the owner can go through and make sure they're still valid opportunities.
We might have a flow that runs every Tuesday at ten AM, looks for any opportunities that hasn't haven't been updated in the past thirty days, and raises a task to make sure, you know, we're progressing these opportunities and they're all still up to date.
Or we might build a a screen flow, and that will be a guided interaction for our customer service reps so that when they're diagnosing a customer issue, they can collect all of the information they need, which will then help us debug and fix the issue.
The great thing about flows is, obviously, that we can build them without knowing any Apex. They're a much more accessible way to build our automation.
Now we know that Apex has a pretty steep learning curve. We might know bits and pieces, but we just really don't have time to learn everything that we need about Apex when we've constantly got the business asking us to deliver more and more tickets.
So Flow's let everybody in the team build this automation. No matter what our experience with Salesforce, we can start to take on more complex tasks for the the business. And not only take on those tasks, we can maintain them longer term. As Ben mentioned there, we've got thirty four percent of developers who are using a mix of flows in Apex.
What's really powerful there is when a developer builds a flow, the rest of the team can come in and may maintain it and fix issues in the future and expand that behavior. We're not relying on the developer to maintain it over time.
So with Flows, we can meet that ever increasing demands of our business and deliver more work faster.
Now one concept we need to get ahead around really early on is flow versions.
Obviously, we we all agree that developing and production is gonna be high risk. Let's say we're making some changes to a permission set. If we do that in production and get it wrong, all of a sudden, our salespeople can't sell, our customer success people can't support our customers. Those mistakes are really gonna cost our business and cause downtime, and that's exactly why we normally work in sandboxes and to test our changes in sandboxes before deploying them to production.
Flows aren't quite the same here. So with a permission set, you have your permission set, and that's it. When you change the permission set, your change takes effect immediately.
With the flow, we can have multiple versions. So we have one version of our flow. That version will be active, and that's the version that's gonna run whenever we save the account or on the trigger Tuesday at ten AM.
On top of that, we can have several different versions of the flow, and these are all draft versions. So we can build changes in these draft versions, and those changes don't take effect until we activate the flow.
Now what that means is we technically do have a way to build changes in production with not quite as high risk as some as something like a permission set. We can create a draft version of our flow in production. We can make our changes there and then test them in that draft version, and then we activate it once we're happy that our changes work correctly.
And it's only at that point we activate that our changes take effect. So that does mean we can build our flows in production.
It's still not great best practice, though. Really, we still want to avoid it, and that's because we have other metadata. We're not only dealing with flows. We've got things like landing pages, custom fields, permissions.
And, really, we want a single release process for all of that metadata.
Now the benefits of having that single release process is when we're onboarding a team member, it's only one process for them to learn. You don't need to know flows, do this, everything else, do that. They just learn a single process.
That really helps with our audit trail and making sure we're meeting all of our kind of compliance regulations because we now can prove that this is how we do our deployments for everything.
So the way we may actually make changes with our flows is we'll start off with a draft version in our dev sandbox, make our change in that dev sandbox, and test it in that dev sandbox.
Once we're happy with it, we'll deploy the change from the dev sandbox to production as we would with any other metadata and then go and activate that version in production, and that'll be when our changes take effect.
So that brings us on to our first best practice, which is don't work on the same flow at the same time.
Now why is this a problem?
Let's suppose we've got two different change requests that are affecting the same flow, and we now have Jane working on one of those requests and Joe working on the second.
Now they're working in the same sandbox, and to start off with, we have version one of our flow. Jane goes from version one and creates version two of our flow, and this is a draft version.
Joe also starts from version one at the same time and creates version three, another draft version.
So they both make their changes independently.
Jane's finished the work, so activates version two. Joe isn't finished yet, so we've still got version three as a draft version of the flow.
Now the first question is, when we come to deploy from the dev sandbox to production, what's gonna be deployed here? Is it version two that's active, or is it version three that's still got this work in progress that isn't finished?
And, actually, the answer depends on how you deploy the flow. If you're deploying with ChainChecks, it will be version two that's deployed. If you're deploying with something like Workbench or any other tool that uses the metadata API, you'll actually see version three deployed. So we get this inconsistent behavior based on the way we're deploying.
But perhaps the bigger problem is version two has one of these change requests, and version three has the other one. We don't have a single version of the flow that actually has both changes in there. So how are we gonna combine them? Typically, that ends up with somebody redoing their work on top of the other version. And, obviously, you know, people are having to redo their work in the team. That's just time wasted.
So how do we solve this problem?
Well, generally, the easiest way is just to make sure it doesn't happen. Let's avoid working on that same flow at the same time. Now we can either stagger our stories so that we do one request in sprint one, the second request in sprint two. That way we can build upon previous sprint so that we don't have multiple versions where people are doing work at the same time. We go version one, version two, version three, and then version three would contain both changes.
Alternatively, we can assign both of those stories to a single person in the sprint. That person can make both changes in one version of the flow. So, So, again, we don't have to combine the work. There's no ambiguity around what we're gonna deploy.
This is great if we can do it, but there's gonna be times when we can't always start work out this way, and we have to have multiple people working on the same flow. Now this can be especially true if you're working in a very big team. You might not even know that somebody else in the business is changing the same flow. Or if we've got very large flows, you know, all of the logic is in that single flow, we're gonna have to change it. We don't have a better solution than that.
So how do we help that?
Well, the key here really is communication.
Now if you're using something like Slack, we can set up a channel, and we can use that to let our team know when we're making changes to flows.
So before I start my work, I can say, I'm about to change this flow, and I'm gonna work in version two. If anyone else is changing the same flow, let me know.
Now this doesn't really help with combining the work, but it at least means we can make sure that we're not changing the same piece of the flow, which which is gonna make it slightly easier to bring those changes back in later.
The worst case scenario would be if we're both changing exactly the same piece of the flow because then we have to figure out how to how to actually merge those changes together rather than just redoing one piece of work in the flow.
So this can help. You know, having that visibility helps us catch those problems earlier on. But if we've got this channel, it can be as we kinda have lots of messages going through, we start to wish that maybe we had a template.
Now if you're using a paid version of Slack, we can make this a lot better using a workflow in Slack. So we can set up a workflow that's gonna collect some information for us about which flows we're changing and then give us a nicely formatted message in the Slack channel.
So we've set up this workflow.
Now when I'm about to change a flow, I hit this button in Slack which says start my workflow, where I'm gonna make changes.
And I'll get a form which asks me all of those questions we've defined.
So we can say which flow are we working on, Which version are we gonna change? Let's get a description of what changes we're making so that we can identify when multiple people are changing the same part of the flow. Maybe we want to link it up to a Jira ticket as well. These are just some example questions.
You know, if your team needs different questions, you can set them up and collect information as well.
It's really up to you what you want to collect here.
So once I filled the form out and submitted it, we get this nicely formatted message in Slack, which tells us I'm changing this flow in version two. I get a brief description, and I get my Jira ticket.
So, ideally, we would avoid working on the same flow at the same time altogether. But when we can't do that, let's really focus on that communication aspect to make sure we at least know it's happening before deployment time. And that brings us on to our next best practice.
When it does get to deployment time, let's check what we're actually deploying and make sure we're only deploying the differences that we expect to deploy.
Now what's the problem here?
Suppose that Jane finished the work in version two and deployed out to production.
Since then, Joe has finished the work in version three and is ready to go and deploy that piece of work in version three.
Now you remember that we didn't have a single version of the flow that has both changes in there. Version two has one ticket, and that's been deployed to production. Version three has the other ticket.
Joe doesn't know that he's missing the work that Jane's already done. So, actually, when we deploy version three, we're gonna overwrite that work from version two.
If we overwrite that work, then, obviously, we're gonna see users start to report issues saying, hey. This feature is broken, or I'm seeing this bug in this fry in this flow.
Really, we want to make sure that we know we're gonna overwrite something before it happens so that we can go and fix that mistake and combine those two versions of the flow.
So we want to make sure we're not overwriting the work done in version two. But another problem here is if we don't know what we're deploying, how do we make sure we're not deploying some work in progress that maybe isn't ready for deployment?
Maybe Joe has started on version four, which is work from another sprint. We don't want to deploy that because we haven't finished yet. We still need to review, but we do want to deploy the work we did in version three.
So how can we check what we're deploying?
Well, we can go and grab the XML for the flow. If we're using a chain check, we can drive we can drill into that chain check and find the XML for the flow, and and that tells us exactly what the flow looks like that we're deploying, so exactly how it's gonna look in the target after deployment.
It doesn't have to be through a chain set. We can get this through, again, through Workbench or through the Salesforce command line.
Now at this point, you're probably thinking, well, this is great, but the whole point of flows is that it was clicks, not code, and now we're suddenly looking at XML. It's getting dangerously close to code again. And you're absolutely right.
The XML can be really difficult for a few reasons.
First of all, our flows can be really, really big to the point where these files, for the XML, you know, they're thousands and even tens of thousands of lines long. So that's a lot of XML to review.
Not not ideal.
This XML is quite noisy as well. So when we build our flow and we have a flow builder on the canvas, every single element in there gets some location coordinates, which basically say where that element is on our canvas.
That all gets written into the XML, which is just a lot of noise that we don't really care about. It's not gonna impact the behavior, so it doesn't matter too much if it's not perfect.
And finally, the XML is actually reordered.
So if we were to open our flow side by side with our XML file and go from the start element, The start element is obviously at the start of our flow, but it's towards the end of the file.
Then we look at our get records element, which is the first one we hit. That's just somewhere in the middle of the file. And then our assignment element is right at the top of the file. So we can't even go through side by side with Flow Builder here trying to match up elements in our flow with the element in the XML because it's in completely the wrong order.
So reviewing our Flow XML actually isn't that easy.
So how can we make it better?
Well, if you're using Versus Code, there's an extension called Salesforce Flow Visualizer.
This was written by a guy called Todd Halfpenny, and you'll install it into Versus Code. And what it does is takes the XML for your flow and gives you this little rendering of your flow directly in Versus Code.
So we've got an XML. We can either paste it into Versus Code from our change set. We can use the Salesforce command line to pull it down, and then it's really easy to visualize it. We can see all of our elements.
We can see the conditions on those elements. So now we can understand whether we're deploying any work in progress that wasn't ready. You know? We've got over here the first one that pops up is a decision element.
Maybe we didn't want that decision element yet, so we know something's wrong.
So that's great for capturing any work in progress. What it doesn't tell us is whether we're gonna overwrite anything. If you remember, we had version three. Version three of the flow, the one we were about to deploy, was missing the work from version two, and we don't even know that that work has happened.
So we need a way to spot if there's anything missing.
So what I typically suggest here is we have to open up our flow in our dev sandbox, open up our flow in production, and look at the two side by side.
So here, I've got my flow in production on the right and my flow in my dev sandbox on the left. And now we can go through the flow, look for all of the changes, and see if we're about to overwrite anything.
So you might spot going down here in production.
I've made a bit of a rookie error, and I'm updating records inside my loop. So I'm gonna hit my flow transaction limits very quickly.
So we've done a fix in our dev sandbox to move the update outside of the loop.
Now that's the only change here, so I know I'm not gonna overwrite anything, and I'm safe to deploy.
But, obviously, this is a very small flow, you know, fewer than ten elements, so it's quite easy for me to go through and make sure I haven't missed anything. If we're dealing with a much bigger flow, going through element by element to make sure we haven't got any work in progress, to make sure we're not overwriting anything. It can be really difficult, and it can be a bit error prone. There's always a risk that we're gonna miss a change and end up overwriting something anyway.
So we want to check our differences before we deploy it. We can grab the XML for that. We know that XML is hard to review.
So we can open that up in Versus Code to use the flow visualizer to see exactly what we're deploying, or we can take a look at the flow in Flow Builder in our dev sandbox.
But, ultimately, what it comes down to is if we don't want to use the XML, we have to look at our flow in our sandbox, our flow in our production, and just try and figure out what's changed.
So now our third best practice, let's automatically deploy our flows as active.
So we spoke about different flow versions.
When we deploy a flow to production, what usually happens is it creates a new draft version of the flow.
Now until we activate that draft version, our changes won't take effect. So until we activate it, we're still gonna see users reporting issues, the issues that we've just fixed with our deployment. And if we miss that activation step, it's essentially like we've never done the work. From the user's point of view, the issue still exists.
So how can we solve this? How can we activate our flows after we've done a deployment to production?
Well, probably the simplest one is just with a post deployment step.
After we've deployed the flows, let's go and log into production and activate them manually.
But, obviously, you know, we don't really want to have to do things manually. We know it's error prone. We know there's a risk we'll miss something. So we really want to automate this step if we can.
You might imagine maybe we're deploying, you know, ten, fifteen flows, and we have to log in and activate them all. Well, what if we miss one of them? You know, that flow isn't gonna be activated. We're still gonna see issues there. So even with our best intentions, it's easy to miss this step or miss some flows within it.
So a better solution is within Salesforce, we have within the process automation settings. There's a setting which says deploy our processes and flows as active. And what that means is when we do our deployment to production, we'll still get the new version of the flow, but it'll be activated right away rather than being left as inactive. So we don't need to log in and activate it manually. That's all done for us.
Now the downside here is it's kind of a one size fits all approach. We either always activate our flows when we deploy to production or we never activate our flows.
Probably ninety five, ninety nine percent of the time even, you're gonna want to activate those flows. So, generally, that's fine.
But on those rare occasions when you don't want to activate the flow immediately, you know, maybe it's a larger project and the project isn't ready to go, but you're getting the flow into production. Maybe it needs to be there now for some of the dependencies.
We're then gonna have to log in to production and deactivate it. We're gonna have to change the setting before the deployment. So there's still a little bit of overhead.
So those are our three best practices.
First of all, let's make sure we're not working on the same flow at the same time. If we do, it's gonna be hard to combine those changes. We might have to redo work, and we might end up overwriting each other.
We can avoid working on the same flow at the same time by putting our stories into different sprints or assigning them to different individuals.
But if we can't do that, let's just make sure we're communicating a lot so that we know multiple people are changing them.
Before we deploy our flows, we want to double check what we're actually going to deploy, and we can do that by grabbing the XML from our change set or from Workbench.
We can use that XML to review what's happening in our flow. It does capture everything that's in your flow, but it's really hard to understand. It can just be too long, and it just feels almost like we're heading back to COVID at that point.
So what we can do is open up our flow in our source, open a path flow in our target, and work through to find the differences.
And finally, we want to make sure we deploy our flows as active. If we don't deploy our flows as active, then our changes aren't going to take effect, and that means that we have to log in and do it manually. Otherwise, it's like we never did the work.
So what I want to move on to now is showing you how you can follow all of these best practices with Gearset.
So in Gearset, I'm gonna select my dev sandbox, which is where I've made my change, and production, which is where I'm deploying to.
I'll start off my comparison, and at this point, I'm going to pull it in my flow.
I'm also gonna include custom fields because I know I've got some dependencies there, and then we'll find the flow that we've changed here.
Now let me open this up in a bigger screen.
What you'll probably notice right away is this looks pretty familiar. Looks quite like Flow Builder. You know? I can see all my different elements here. I've got my assignments and decisions, and, you know, that makes it easy to see what's changing.
Now first thing I'll look at is which version of the flow I've got. I can see I'm looking at version three from my dev sandbox.
Actually, I want to deploy version two, so I'm gonna switch over to that first. You'll remember that version three had some changes that weren't ready to deploy, whereas version two did. So I can just pull down here. Version two is exactly what I want to deploy.
Now over on the left, Gearset will show me all of the elements in my flow that have changed. I've got a new assignment. I've made a change to a loop. I've added an update records, and I've deleted one of them. And that makes sense because if you remember, I've moved the update records outside of the loop, So I deleted one and added a new one.
Now if I see anything in here that I'm not expecting, you know, if we had deleted a create records, for example, I'm not expecting to have made that change. So, actually, I can spot immediately there I'm gonna overwrite somebody else's work just because there's lots of deletions I didn't think I would see.
So it's really easy to spot now, are we overwriting someone else's work? Do we have any other work in progress here that's not ready?
Now if we move on to the diagram, I'll zoom out a little. You'll see, again, it looks just like the flow we had in Flow Builder.
But the nice thing here is we actually get highlighting on each element. I can see that my loop has changed through through the orange highlighting here. I can see that I've got a new assignment element, and I can see that I've got a new update records element. So we're not having to bring up two flows side by side to try and figure out where the differences are. They're all highlighted here for me.
If I want to drill down into an individual element to see exactly kind of what's changed, I can just click on the assignment there, and you'll see I get this table. Again, very familiar with Flow Builder. I get a little table telling me which variable I'm assigning.
And as we're going through this loop, we're gonna take the loop item, the opportunity that we're going through, and we're gonna set the state stage name to needs analysis, and then our update records element outside of the loop is gonna write that back to our database.
Now I can look at this for all of our records in here, even ones that haven't changed. So if I jump into this get records element, you can see here I'm getting records from my opportunity.
I've got some filters set up to say, I only want records for this account, and I only want open opportunities.
So I can get all of the information that I would see in Flow Builder without having to deal with any XML.
This really helps me check my changes before I deploy them. And by switching version at the top, even if we do have multiple people working on the same flow at the same time, I can choose precisely which version I want to deploy.
So we know we want to deploy that flow, and let me select that.
Now the other thing we might want to check is, are there any dependencies we need in this deployment?
I can expand this out, and we'll see here we have dependencies on account.
Account's the option that's triggering the flow. We've also got dependencies on opportunity and our account ID. So it's really easy for me to include these as well in my deployment and deploy everything I need in one go. Now I've actually got the changes I need from account and opportunity in my production org already, so I don't need to include any of these.
And I'll hit next to go ahead with deployment.
At this point, Gearset's gonna check for any issues in the deployment. If we've missed any dependencies here that were needed, Gearset's gonna offer to include them, and that just gives our deployment the best chance of success.
Now we'll move on and see a summary of what we're about to deploy here, and it's just offload.
I can give this deployment a name and some notes. So I can say, I'll move the update records outside of the loop. These are just to help my team understand what this deployment's for and give us that traceability of why we've done every deployment.
If I'm using Jira, I can associate a Jira ticket with my deployment, and then that will get written back to Jira for me. But what I really want to kind of call attention to here is this activate flows after deployment switch.
Now this gives us a lot of flexibility because we can control this on every single deployment.
So for the deployments where we do want to activate our flows right after deployment, just turn it on, and Gears will go and activate deploy the flow and activate that new version immediately for me. If for whatever reason I don't want that, maybe I'm working on the bigger project, I don't have to turn it on at all. So I get a lot of flexibility here as to whether I activate the flows or not.
So let's go ahead with that deployment, and we're gonna take the change we made in the dev sandbox in version two, deploy out to production, and then activate the flow after deployment so that it immediately takes effect.
Okay. So that's all gone ahead. And I can see over here from my results that we've deployed the flow and it's active. I can even jump straight into it in Salesforce. Now if for any reason we spot an issue in this layer after deployment, maybe we got a bug report from a user a few hours after deployment, Super easy for us to roll this back and just come back to Gearset.
I can hit rollback on my deployment, and we'll redeploy the flow as it existed in production before our deployment so we can get back to that known good state very easily.
So that's how we deploy flows with Gearshead.
So just to recap, with Gearset, it's easy and fast for everyone on our team to deploy flows.
We can see exactly what we're deploying. With that highlighting, we can see all of the new, all of the changed, and all of the deleted elements really easily.
That makes it easy for us to spot that when if there's any changes we're gonna overwrite and avoid doing that. We can choose a specific flow version to make sure we're not including our work in progress, and then we can set up our deployment to automatically activate our flows.
All of that means we just spend far less time worrying about how are we doing our deployment. Are we gonna make a mistake during our deployment? Are we gonna override anything? We know that we're not. We get that confidence in our deployment, and that means we spend more time delivering that value to users, and we can spend more time making our changes and less time worrying about the deployments.
So that's everything we had to say today on deploying flows like a pro.
At this point, I think we'll stop for any questions. And maybe, Ben, do you want to jump back in?
Alright. Thank you so much, Tom. Really, really insightful to see a few few tips to do with Flow and then, of course, get a lovely demo of gear set as well. So, yeah, we we do have, a a fair bit of time for q and a. So if anyone doesn't any questions, feel free to put them in the, the q and a box, and we can get around to as many as possible.
Just because just because you've just finished with gear set, we got a, a chat message from, Nicholas here, which James is helping the chat. I think it would help, everyone listening. Can Gear Set handle conflict resolutions on flows?
Yep. Absolutely. So Gear Set has a feature called pipelines, which is integrated with a version control system. So you can use GitHub, Bitbucket, Azure DevOps, whatever you're using.
Now when you commit your changes to your feature branch, what you typically see in version control is your version control system would try to merge those flow changes.
And your version control system doesn't know that it's merging a flow. It thinks it's just lines of text.
So let's imagine I've added a assignment element into our flow, and Ben's also added an assignment element on his feature branch.
Now if we try and merge those in the version control system, both of those assignment elements are gonna be in the same position on our respective feature branches. You know, maybe it's line thirty to line fifty. I've got a new assignment, and it's got a new assignment.
Our version control system can't normally merge that, whereas Gearset will recognize that, actually, this is two different assignment elements, and what we want to do is take both. So Gear Set will merge those for us and can recognize that, actually, the correct thing to do here is to take both of our changes.
Great. Thank you, Tom.
So, just because quite a few people have been asking a question, the recording, this is being recorded currently, and and we send it out afterwards. So, if you do want to send it around to your colleagues or watch it again, then, yeah, it'll be available.
I have a question from Ramesh here. When we deploy a flow as active with that setting, it's asking for code coverage. How do you get coverage for a flow?
Yeah. Great question.
So the process automation settings, it requires you to meet your code coverage on your flows. Now, obviously, having that code coverage on a flow is a great thing to have.
The way we're doing it in gearset is, effectively, we're mimicking you logging into the org manually and activating your flow.
So, actually, the gearset doesn't require that code coverage to be in place to activate the flow for you. That's still a great thing to have. I'm still you should obviously focus on testing your flows, but we don't actually have that same restriction as the process automation settings.
Mhmm. And next one. Is this behavior available when deploying through CI jobs rather than compare and deploy?
Yep. So what we typically see would be when we our CI job would take our, our branches in our version control system and deploy automatically out to our to our production org or, you know, staging UAT or whatever.
Now what we saw today where we get the diagram of the flow, we would see that part when we go and commit to our feature branch. So we can still check whether we've got any work in progress or whether we're gonna overwrite any work when we commit to our feature branch.
Activating the flows is something that will be coming soon to the CI jobs so so that we'll have a way to say, when I deploy through my CI job, activate my flow.
Cool.
Thank you very much, John.
And how can we avoid triggering our flows when we're doing bulk data loads, e g importing from another system?
Yep. So, obviously, the risk here is that, you know, if we have a flow that sends out an email whenever a new contact's added and we're doing a bulk data load, we don't really want to be sending out welcome emails or anything to those contacts.
So one way we can do this is if we create a permission set that has, you know, a particular permission in there, we can assign that to our data load user.
Now at the start of all of our flows, we can check for that permission. Does does the running user have the permission?
And if the user does, we can just exit our flow immediately before we send out that email. So through this extra permission, you're using a special user for our data loads. We can kind of have this early exit clause from our flows.
Nice. I've been there before sending out bulk emails to people, which, yeah, definitely is an idea also.
Good to good to get that The other thing is make sure your sandbox is you've got the invalid on the end of the emails.
Yeah. Yeah. Yeah. Very good point.
We've still got a bit of time. I see a few more questions, but if anyone has any more, feel free to drop them in the chat.
And, how can we architect our flows to avoid multiple people working on the same flow at the same time.
Mhmm.
So if we have a bigger flow, we're more likely to see more people working at the same time because it's gonna be doing more stuff.
Now, historically, Salesforce only let you have one before save flow and one after save flow per object. So we kinda got forced into this path of having, you know, these enormous flows that do everything.
That restriction has been removed now, and and we can have multiple flows per object. So we can have, you know, four, five, six, however many before before, say, flows on an account.
Now if we try and design these, say each flow is fairly small and has a kind of single well defined responsibility, that naturally means that our work's gonna be more spread out. You know? Odds are that we're probably not gonna have two tickets for the same piece of functionality at the same time, which means we only need one person working on that flow.
Cool. Yeah. That makes a lot of sense.
And how can we make sure we're following best practices when we're designing our flows? Is there anything like PMD?
Yeah. So there's a another Versus code extension called Lightning Flow Scanner.
So you get the XML for your flow, again, from the Salesforce command line, from your chain chat, wherever, put it into Versus Code, and you can run lightning flow scanner just like you'd run PMD.
That will check for any common issues in there. So it will detect things like you put the update inside a loop, and you're gonna hit your transaction limits. It will look for things like unconnected elements, which, you know, are floating around. They're kind of just adding noise to our flow. They're not doing anything useful.
It will check our then we put descriptions into elements, all of these kind of different rules, similar things there to make sure that we're not introducing kind of common pitfalls into any of our flows.
Yeah. Great. Very cool. Yeah. There's so many interesting Versus Code extensions around nowadays.
And there was a question about, sorry.
There was a question about gear sets learning platforms, and I think Holly put a link into the the, DevOps Launchpad. But do you wanna just give everyone a bit of an idea about what that platform is?
Yeah. So DevOps Launchpad, it's kind of our online learning platform. It'll take you through different pieces of gear set in a similar way to Trailhead where we have different modules. You know?
We have one module for here's how comparing and deploying changes work. Here's how our CI jobs work. Here's how backup works. Here's how sandbox seeding works.
So for everything you can do in Gearset, we'll have these modules which help you understand how how to kind of use those, what problems they're solving, and how you can get the best out of those.
Nice. Great. Yeah. It's very cool platform.
Alright.
I think those are all the questions at the moment.
Now we'll just give it a few more few more seconds just in case anyone's got any burning questions for Tom or myself.
Cool. Well, I think we can start wrapping up, and then, if we have any questions, we can we can quickly answer them.
So thank you everyone everyone for coming today. It's been a really insightful session. As as I'm sure you've gathered by now, flows are a super, super important topic. And it's vitally important also that, you know, that they're deployed right, and you just just ensure there's there's the least friction possible amongst your team and, and colleagues and teammates. So, yeah, thank you so much, Tom, for the presentation. And any final words before we we close the session?
No. Just keep using Flows. They're obviously great for taking more work. Really cool, all the functionality they're adding. And at GearSet, we always love to hear feedback, so you can try this out at GearSet dot com. There's a free free thirty day trial, or you can speak to our team. Any feedback at all, we'd love to hear it.
Cool. Fantastic. Thanks so much, Tom.
Thanks, everyone.
Thanks, everyone for attending. Bye bye.
