Jira Workflows: Build Custom Workflows That Match How Your Team Works

1. Course Introduction: Welcome to this course all about Jira workflows. My name is Dan Lefeb and in this course, we'll learn how to build custom workflows that match how your team actually works. By the end of this course, you'll be able to customize workflows for different work types, like ideas, tasks, bugs. They can each have their own workflow in your Jira spaces. We'll also learn how to add restrictions so only specific people can perform certain transitions. We'll learn how to validate data before a transition proceeds between two different statuses. We'll also learn how to automate tasks with actions and AI agents, deploy workflows to your space using Workflow schemes, connect your workflow to agile boards, and so much more. This course focuses on company managed spaces, which gives you full control over workflows and schemes. That also means that we'll have global administrative permissions to be able to configure workflows across our entire Jira instance. Now, if you are using team managed spaces, you'll still get value from most of the lessons in this course, because the workflow editor in team managed spaces works the same way as it does in company managed spaces that we're using throughout this course. By the end of this course, you'll have a fully functioning status workflow with restrictions, validations, automative actions, AI agents deployed into your space. Now, before we hop into Jira, let's take a few moments to get on the same page about the core concepts of Jira's workflows, and we'll cover that in our next lesson. 2. Core Concepts of Jira Workflows: In this lesson, we'll cover the core concepts behind Jira's workflows before we hop into the Jira interface itself. Every workflow in Jira consists of two main parts, statuses and transitions. Statuses represent where a work item sits in its life cycle. The basic statuses are to do in progress and done. But we can extend these by creating any custom statuses that we want, like code review, ready for QA, QA testing or blocked, things like that. With that said, no matter what status is we create, each status belongs to one of three categories. Those categories are to do in progress and done. While we can't create custom categories in Jira, they are mostly for Jira's own back end organization to help it determine what any type of custom status that we create is. Basically, any custom status we create is going to live inside one of those three categories, and then that determines how Jira knows when to do certain things. For example, if something is in the done category, then Jira knows that work is completed. No matter if you call the status done or complete or finished or whatever we might call it for the custom status, because it's in the done category, Jira knows that work is done. Transitions represent the action that moves a work item from one status to another. Technically, a single transition is a one way move. If we want to move back and forth between two statuses, we need two separate transitions. Now with that said, there are some ways that we can allow Jira to transition statuses in any direction, and we'll look at that in this course. But just know that on the back end, if we move work from to do to in progress and then back to to do, that's technically two different transitions. One from to do to in progress, and then a different one from in progress back to to do. That's important because we can tell Jira what sort of things we wanted to do with each of those transitions. If we want the work item to do something different when it goes from to do to in progress, then when it goes from in progress back to do. As you can imagine, things can start to get complex pretty quickly. So it's important to come up with a solid naming convention for our statuses and transitions. So we'll know what each one means and what it does. And here are a few tips to get started. Number one, use clear, consistent names. Code review is better than review stage or even in development. That leads into number two. Avoid overlapping meanings. If we have both in development and in progress, that can be confusing. But in progress and code review as separate statuses, our team will know which one represents active development versus handoff. And as the jure administrator, we might come back to a workflow months or years from now and not remember what they're used for if those statuses sound similar. As a little bonus tip, if you're not already, start making documentation about our naming conventions. That way, if we do, for some reason, choose to make similar sounding statuses, we can refer back to those in the future to know why we chose to go with something specific. And if your organization is using Atlassian's documentation tool called Confluence, that's a great place to store all of that naming convention documentation. Third, keep it simple. Don't add a bunch of statuses just to try to over organize things. Add the bare minimum to start, and then get feedback from our team in the upcoming weeks and months about whether or not we'd find adding more to the workflow helpful, maybe add one or two more things and then see if that helps. If not, removal. If so, keep it around. The more that we have in our workflow, the more complex it gets, and we don't want things to become unmintainable. Now, if you've been using Jira for a while, you might be used to some older terminology that has changed a bit with recent updates. So in this course, there are four types of workflow rules that we'll encounter, and the terms for those rules have changed. First, we have the restrict transition rules. Those were formerly called conditions. Those control who can see and use a transition. If a user doesn't meet the restriction, then they can't transition between statuses. Next, we have the request input rules that pops up a screen during a transition that asks the user to fill in specific fields before the transition proceeds, and we'll cover that later in this course. It's kind of like a validators friendlier cousin that prompts for data instead of blocking it. And then we have the validate details rules. Those are formerly called validators. Those check whether required data exists before allowing that transition. So it's more strict than just requesting for input. For example, requiring the fixed version field to be set before closing a work item. And again, we'll look at that later on in this course. Then we have the perform actions rules. Those were formerly called post functions. Those run automatically after a transition is complete. They update fields, assign users, or they can trigger AI agents, and we'll look at those later on in this course. Now, there's also something to keep in mind about permissions. A user needs more than just workflow permissions to move a work item. They also need to be able to edit the work item itself. So when you're testing restrictions, make sure to use a user that has at least basic edit permissions for that work type. So to recap, workflows consist of statuses and transitions. Each status belongs to a category that determines its board appearance. Transitions are one way actions between statuses, and there are four types of rules that we can have on transitions. They can restrict who can make that transition, can request input during a transition. You can validate data before transitioning and you can perform actions after transitioning. Now in our next lesson, we'll jump into Jira so we can convert a default workflow into a custom one, and then we'll start building from there. 3. Configuring Custom Statuses & Transitions: In this lesson, we'll hop into Jira and start building our own custom statuses and transitions to build out our software development workflow. First, let's get to the workflow editor. Now, there are two ways that we can get there. We can go through our space settings. So we can come into these three little dots, go into space settings. And that is handy. If we're already working inside of our specific space, we can get to the workflow that space is using. But since this is our first time jumping into Jira in this course, and we're working as a global Jira administrator, Let's go through the global Jira settings where we can see and manage all of the workflows across our entire instance. So we can come up to the settings, come down to work items. And then over here on the left hand side, if we come to our workflows, this is going to show us all of the workflows that we have in our Jira instance. Now we are working with a space called software development, this one right here. So this is the workflow used in this space. Let's come into three dots. Come down to edit, and that will take us to the workflow editor. I'm going to close this just to give us a little bit more room so we can see the editor here. Now, here we can see the default statuses and transitions from the Scrum template. That's the template that I used when I created this space. We have to do in progress and done. And then up here, we have start, right? So I'm going to actually hold down Control, use my mouse wheel to zoom in just so we can see this a little bit easier. So here we have start. And this is not really a status, but it's the start of when a new work item is started, right? So when it starts, it then goes through this create transitions, and that tells Jira, when you create a new work item, where does it go? In this case, and by default, it goes to this to do status. Now if we wanted to change that, all we would have to do is to select this transition here and then move it to a different status. Let's say we want it to be in progress. Now if we were to create a new work item inside of this space, it would be in progress as soon as we update this workflow. Why, of course, realistically, that doesn't make a lot of sense. Let's leave this at to do for this status. And that brings up a good point because before we go through the process of making a lot of changes in the workflow editor, I would highly recommend that you take the time to sketch out exactly what you need in your workflow first. So by the time you get in here, you already know what you're going to be doing or have an idea of how everything is going to connect together. Now, if you are using confluence alongside of Jira, you can use their digital whiteboards. It's a great place to do that by drawing out every status and transition in a very loose manner before coming in here and actually making it functional in the workflow editor. Of course, you can always change things later on, but that bit of pre planning will give you a good starting point. That said, sometimes it is helpful to see how other teams work first. So I've already gone through that process of figuring out how I want this workflow to go that we're using today. So let's start by adding our new statuses to work with, and we'll go through the process of creating them all at once, and then we'll organize everything and connect it all together. So I'm going to come up here to the ad status up at the top, and we want to create some statuses. So let's come in here and we either select a status that we already have created in our Jira instance, or I'm going to come in here and start typing in. No, we don't have that status yet, so let's create it. The category is going to be in progress. And then we could allow transitions from Edi status right here, but I'm just going to go ahead and click on Add, focus on adding in these statuses to begin with, and then we'll organize everything later on. So let's go to ready for QA is our next status. Create that. Again, the category is going to be some form of in progress. At status, we're going to come in, and this is going to be QA testing. Again, the category is going to be some form of this is in progress. We're going to add in our block status. And then we're going to add one more status here, and we're going to do a won't do status. And that's going to be another form of done. So that we'll have a couple of different statuses in the De category. And rather than having all of them be this work is actually done, if we come in here and add one that is won't do, if we add work into the won't do status, then we can go back later on reports and filters and see the ones that we consciously made the decision that yes, this was actually completed, this is done, or we made the decision to actually not do that work for whatever reason. And then in the work item itself, you would add whatever the reason is that you didn't decide to do that work. Alright, so now we have our statuses created. Let's come in here and start to create some transitions. So on these statuses that we already have, this is the any transition. That means that work items in the done status can transition into this status from any other status. So if it's in progress, if it's to do, if it's any of these here, it can actually transition into the done status from that other status. But we may not always want that. So let's start by organizing this creating some new transitions between these statuses, because right now, these are highlighted, which means there's no way that anything can transition into the code review status. We can't have work in the code review status if there's no transition into it. So I'm going to come and take one, let's say, from in progress, we want in progress to go into code review. And let's give this status a name. It's always a good idea to name everything. And this is where the pre planning can come in really helpful, what you're going to be naming things. So this is going to be submit for review. So it goes from in progress to code review to transition is submit for review. For the next transitions, we're going to say, Okay, when work is in code review, it's going to come out of code review, and then we're going to have it be ready for QA. And this status or this transitions, I should say, is going to be called approved, right? So it's been approved, and then it goes from code review. The code review approves, and it goes to ready for QA. Now, another possible workflow for this is if it's not approved, if there's something that needs to change, we can come in and say, Okay, code review, let's take this back to in progress. And this is going to be the transition is going to be request changes. There we go. So that's another potential workflow that our work items could have. And we can rearrange this if we want to just to have this make a little bit more sense in how we have all of this organized. Next, when work is in the ready for QA status, what happens here? Okay, so ready for QA in this workflow is basically going to be the to do status for our QA team, right? They're going to once it's gone through code review from the developers, it's going to be ready for QA. And then anything in the ready for QA status, our QA lead, that user is going to be able to know, Okay, this is ready to go. And then as they're actually working on it, they can take work, drag it over to QA testing to show that the testing is actually started on this. And for this, let's say, we're going to simply call this start QA. And then it can come from QA testing, and we actually want this to be go into done to say, Yep, okay, this has been completed. There we go. Or just like we did with the code review, if there's a change that needs to happen, we can take this from QA testing back to in progress and say, this needs to be sent back for a fix. There we go. And then for these other two statuses, there certainly will be times where we want to do a global transition from any status to other status, and at any time, we want to be able to say, we made the decision not to do this work. So for this, we're going to add a transitions, and this is going to be from any status to won't do. Go ahead and create that. And then same with blocked, we're going to say at at any point, any work can be blocked in this workflow. There we go. So we have our workflow created here inside of the workflow editor. And now we have our workflow ready to go. In our next lesson, we'll start looking at some of the rules that we can add to our workflow, starting by restricting transitions. 4. Restricting Transitions: In this lesson, we'll learn about the first type of workflow rule restricting who can execute a transition. The restrict transition rule was formerly called conditions in older versions of Jira, and it controls whether a transition is available at all, based on whatever rule we decide. Probably the most common use case for this is to restrict a transition based on who the user is. So here's a common scenario that we're going to learn how to set up in this lesson. We only want developers to be able to submit work for code review. So in our setup, Ethan is a developer, and he is in the developer's user group. Maxwell is our QA lead, and he is not in the developers group, and we want Ethan to be able to submit for review to transition from one status to another to the code review status, but Maxwell should not be able to transition from in progress to that code review status. So let's set that up. What we want to do is to use this submit for review transition that we created in the previous lesson. Under this transition, because that's going to be any work that comes from in progress to code review, it has to pass through this transition. Let's come over to our rules, restrict transition, add a restrict transition rule. And then we want to restrict based on who the user is. So restrict who can move a work item. And we can choose either specific users, or I found a better workflow is to use groups. That way we can add users to the group, and all of these rules will automatically be applied rather than having it just be individual users. So I'm going to come in and pick groups, and let's select the developers group. So that means only developers will be able to use this transition to go from in progress to code review. Hit AD there we go. We have this added to our rules over here on the right hand side. Now, for this to go into effect, we actually have to update the workflow. So right now, we're basically in a draft mode. We haven't actually updated this. So for this to become live, we need to update the workflow. Now that our workflow is updated, let's see what this looks like for our team. So first, I'm going to log in as Maxwell. This is logged in as Maxwell Carter. He is our QA lead, who is not part of the developers group that we just added that transition restriction to. So if we were to come into one of these work items that is in progress, you can see Maxwell can't even take this to the code review status because the only way to do that is to go through this submit for review transition that we have restricted. Now, if I were to log in as Ethan, who is one of the developers in the developers group, let me pop up that window here. I'm logged in as Ethan here. Now logged in as Ethan. If we were to look at one of these work items, see the status. It's in progress. If I pull this down, we can use that submit for review transition to transition it into the code review status. And there we go. Now, Ethan can change the work item to be in the code review status because of this transition, the submit for review transition only allows people in that developers group to go through that transition, which is the only way to get into that code review status. Same status, same work item, different user permissions. It's a powerful way to enforce role based access in our workflow without relying on us to just remember what the rules are. The system can enforce it for us. Some other common restrict transition use cases can include things like maybe only allowing this approved transition to be project leads or managers. Or maybe since we have a QA team set up, maybe only the QA team can actually complete the QA and send it to Dunn after it's done with QA testing or maybe even can only start the QA. Maybe we only want the QA team to be able to start QA once it's ready for QA, only the equa team can actually start that QA testing, that goes through this start QA transition. It's the exact same process. We come in here to the transition, come to restrict transition, add a rule, restrict who can move it. This time, instead of the developers group, let's restrict to the QA lead. Add that. Go ahead and update this workflow. And now we can take that work at them that's in code review, bring it over to ready for QA, but only our QA will be able to take it into testing. So let's see what this looks like, again, when we're logged in as our developer here, Ethan, so let's say, okay, it's in code review, it's been approved. So that means it's ready for QA. Ethan can take it over to ready for QA, but it can't then be approved and taken out of that ready for QA, right? Except, we do have it set to, I believe that's because of this transition right here. Yep. So even though we have this transition here, we have this setup for any status. So if you wanted to remove that, we could simply come in, hit Delete, update that workflow. So now the only way to get to done is through QA, so if we hop back into being logged in as our developer here, pull this in, can no longer take it to the De status. The only way to do that is through the QA team, which means we're logged in, we're going to switch again to being logged in as Maxwell here, being logged in as Maxwell, this is ready for QA, and he can go ahead and take that to the QA testing. Yep, okay, it's ready for QA testing. And then once he's done, he can complete UA testing, and that work item will be completely done gone through that entire workflow. So to recap what we learned in this lesson, we learned how to restrict a transition from certain users based on the group that user is a part of. And there are so many more ways that we can add complexity to this if we wanted to. We can even add a child rule to this if we wanted to, say, maybe restrict a transition from someone who is in the developers group, and also someone who was in a QA group, things like that. Now, I encourage you to create a test workflow and start playing around with the restrict transition rules in the workflows on your side to see how you can use those to your own advantage. And when you're ready, I'll see you in the next lesson where we'll learn about another type of rule for our transitions, request input. See you there. 5. Adding Request Input Rules: In the last lesson, we looked at the restrict transition rule. In this lesson, we'll look at the second type of workflow rule request input. Request input pops up a screen during a transition that asks the user to fill in specific fields before the transition proceeds. Instead of just moving the work item from one size to another, Jira pauses and says, Hey, before we go any further, I need you to fill out a few things. And this is useful when we want to collect data at the exact moment that a transition between statuses happens. So here is our scenario for this lesson. When someone moves a work item from QA done from QA testing status to done, that uses the complete QA transition. We want to make sure that the fixed versions field gets filled in so we know what version of our code contains that fix. We could just hope people remember to set it, but a better workflow is to use the request input to prompt them right away when they're completing that work to fill in that field. So let's hop back into the workflow editor and get that setup. After QA testing, in order to get done, as you might expect, that needs to live on this complete QA transition. So let's come in here to the complete QA transition and then come in to request input, add a request input rule. Now we need to tell Jira what screen to show. So there's only one thing here. We can show a screen, select that. What screen do we want to show? Now, we can pull from any of the other screens. You can see there's a lot of different screens that I have set up on my side in my Jira installation. But if we don't have a screen already created, we might want to come in and create a new screen. So I'm going to do that, and that will pop open a new tab. There we go. Now let's come up to add screen. And give a name. Naming is always good. So this is going to be for our complete QA transition. Request input for fixed versions. There we go. Give it a description if we want. But I'm going to hit on add. Now we have our screen created. We can close out of this tab that'll take us back to our workflow editor. And let's find that. So it was something with fixed versions. There we go. Find that screen, add that to our rule. And now, whenever something comes from QA testing and is ready to be done, it will show that screen, of course, as soon as we update our workflow. So let's do that. Now that our workflow is updated, let's go in and let's see what this looks like on the other side. So we need to log in as Maxwell. Who is our QA lead, right? Because remember, we set up that restrict where Maxwell is the only one that can do that. So as soon as it's done with QA testing, it's ready to be completed. Now when we set it to Dunn, it's going to pop up this transition. But wait, where is our field? I actually forgot a step. Let's come back and cancel out of this. So it's not going to move that transition. That's something that's important to keep in mind. If you cancel out of that, it's not going to complete that transition. And let's hop back into our screen here. This is a great way to show how we can adjust this after the fact. So let's find our screen. It's going to be the fixed version screen here. We forgot to add in the actual field that we want to be added on this screen. So right now, there's nothing configured for this screen. That's why it didn't show anything. So let's come in and add fixed versions. There we go. There's no save or anything like that. It's already saved. And because we already have it set up in our workflow, let's hop back into our workflow editor here just to show that it's already set up. It was our software development workflow, this one right here. So it should already be set up that once it's on complete QA, Yep. Okay, that screen is showing up, and that screen now has that field. So if we hop back into being logged in as Maxwell, take this work item and complete it, it's done. And now, we have that fixed version field. Of course, it looks like I don't have any versions actually in here in this space. So let's come in to our releases. Those are the different versions. Yeah, we don't have any releases actually in here right now. And it looks like Maxwell does not have the permissions to actually create one. No big deal. Let's hop back in as our administrator and create a new version here. So I'm going to hop back into the software development space, come into the releases, and now we can create a release. So let's say, Okay, this is Version 1.0 of our software. Save that. That's been created. And then now with Maxwell, if we refresh the page, he will see that version show up. There we go. And then back to the work item, once it's done in QA testing, we can complete it'll pop up our screen, and he'll see that fixed version that he can associate that with, add any sort of comment that he wants, update that. And now that work item will transition into the De status. Sort of recap. In this lesson, we learned that the request input rule pops up a screen during a transition. We learn where to go to add fields to our screen. We even looked at where to go to set up a new version in our space, so it shows up in the fixed versions field. Of course, that screen can include whatever fields we want. And we can even take that to the next level by controlling what fields are required on our screens using a field configuration scheme. Actually, speaking of requiring things, let's move on to our next video where we can learn how we can basically set up that exact scenario with the validate details rule. And we'll learn all about that in our next lesson. I 6. Validating Transitions: In the last lesson, we use request input to prompt users for data during a transition. In this lesson we'll learn how to use the validate details rule. The validate details rule used to be called validators in older versions of Jira, and it checks that required data exists before allowing that transition to proceed. But unlike request input, which prompts the user to fill in missing data, validators take a stricter stance. If the validation fails, the transition is blocked entirely, and the user sees an error message. Think of it this way. Request input stops the user and says, Hey, fill this in before we continue. Validate detail says, No, you can't proceed until you complete these steps. So here's our scenario for this lesson. We're going to build on what we did in the last lesson where we added in a screen that allowed a user to fill in the fixed versions field, right? But instead of just prompting for it during the transition, like we did with the request input and then expect it to be filled out, what we're going to do is to block that transition if it's not actually filled out. So let's add in a validator on the complete qa transition that checks that to make sure that field is filled out before it allows it to continue. So hopping into the workflow edit in here, under the request input, we have the validate details. And in this case, we want to make sure that the fixed versions field is filled out. So when we come in to validate details rule, add that in. There's a bunch of them that we can do in here. In this case, we want to validate a field because as we saw in the last video, fixed versions is a field. So we want to validate that field, select this now we need to tell Jira how we want to validate the field. Do we want to make sure that it has a single value instead of multiple values? Or do we want to make sure it matches an expression? Maybe the summary of the work item starts with the same words and whatever that expression might be. In this case, though, we want to make sure that the field is not empty at all. It has data in it. Now we need to tell Jira, Okay, when you want to validate that a field is not empty, what field? Well, in this case, we want it to be the fixed versions field, the one that we added before, right? So this one here. And we can either leave the error message blank, which is going to add a default one, or we could add in our custom error message if this fails. Say, you need to add a fixed version first. There we go. Go ahead and add this. Now, here is an important point because the order of these rules matter, right? So they actually run from top to bottom. So because we have the request input before the validate details, this will pop up the screen that will allow the user to add the fixed versions field using the screen that we set up in the last video. If they do that, this validate will validate whether or not there's data in that field. So they have the opportunity to add data to that field before it tries to complete that transition. If they don't do that, it will pop up that error message and say, that needs to be filled out. That field cannot be empty. So let's update our workflow and see this in action. I'm going to update the workflow, so that's now live. And then let's hop in to being logged in as Maxwell. Remember, he is our QA lead, and we restricted the transitions. So we want to make sure that this is taken to the QA, although actually, we need to log in as Ethan first because it has to go through code review. Remember, this is the process that we have from in progress, it has to go to code review. And then from code review, once it gets approved through code review, then it's ready for A. Okay? So now that it's in QA, we can log in as Maxwell on our qua team. It's ready for QA. Okay. And it's in QA testing. Now that it's done through QA testing, Okay, it's completed, it's done. We can come in here and we can add it into our fixed version. Or if we just come in here and try to update this is going to say, no, it needs to add. We need to add a fixed version first. That is the error message that we told it to give us in that validator. That is our validator working right here. But as soon as we come in here and add data to this field, watch what happens. I'll be able to update this because that data has been validated on the back end. Once again, in the workflow, that is this validate details rule coming in here and saying it's checking this field. If it isn't empty, basically, it has data in there, it allows it to pass, and when it didn't gave us this error message right here. So to recap, the validate details rule checks that whatever validation we set up is fulfilled in order for the transition to complete. When the validation fails, the transition is blocked and the user sees an error. Of course, we can use any field beyond the fixed versions field. And as we saw when we set up the rule, we can do even more than validating fields themselves. But hopefully, the gears are starting to turn for how you can use this in your own workflows. So I'd encourage you to take some time between lessons, to try it out on your side and start playing with some of the different rules to see how they can help in your organization. We have one more type of rule to look at. So in our next lesson, we'll move on to learning how we can build on this even further by performing actions in our workflow transitions. See you there. 7. Performing Actions: In this lesson, we'll learn about the fourth type of workflow rule performing actions. Now, this one's a little bit different than any of the other rules we've looked at so far because they happen at the very end after all the other rules have successfully completed, and they're not really validating anything. If you've used older versions of Jira, these used to be called post functions. So they're different because they're not really deciding about whether or not the transition can happen. They're the cleanup crew that happens after everything has already been validated. They do things like updating field and assigning users, stuff like that. So here's our scenario for this lesson. After our work item transitions successfully into the ready for QA status, let's automatically assign it to our QA lead, Maxwell. That way, he'll get a notification of work being assigned to him, and he knows it's ready to start testing. So let's hop into Jira and set that up. What we want to do is once it goes from code review into ready for QA, that means we need to apply it to this approved transition right here. So under approved transition, select that, scroll down, perform action. We're going to perform action rule. And there's a couple of different ways we can do this. We could come in and update a work item field because assignee is a field that we could update. But that's such a common thing that Alasian has actually surfaced that to appear. So we can assign a work item without having to dig through all the different fields. So let's select that. And now we need to tell Jira who we want to assign this to, or alternatively, we could strip any assignee that is currently assigned. If we wanted to do that, we could strip that right here. If it was already assigned to somebody, we could just remove that assignee at this point in the transition. For our scenario today, let's come in here and pick our QA lead. That's Maxwell. Add that. Okay, so after this transition runs, the action at the end is to assign the work item to Maxwell Carter. So let's update our workflow to see this in action. All right. So let's hop into being logged in as our developer, Ethan, right? So let's take one of these work items here. Let's say just this one right here. Let's say, Okay, from to do to in progress. And then from in progress, it's ready for code review. After code review, it gets approved and sent to QA. Watch what happens to the assignee when it gets approved and sent to QA. There we go. It got assigned to Maxwell Carter. And now Maxwell Carter can take it through the rest of the way, because, again, logged in as Ethan, he can't go through and actually move it past QA. He's taking it as far as he can take it. Now it's up to Maxwell Carter, and it's assigned to him. To come in here and actually start QA testing and run it through the rest of the workflow that we've already set up. Now, one thing to be aware of, just like the rest of our rules, the actions run from top to bottom. So if we have another action in here, if we were to come in and say, we also want to update one of the fields, we could select one of these fields. Let's say, I'm going to add in the description, something like that. If we want to update that field, the order matters, right? So if I were to take this and drag it up above, now this is going to take place before this gets assigned. Now, in this case, and this little scenario that I set up, the description being updated happening before it gets assigned, that's not really going to change anything. But it's important to keep in mind because if you're starting to update fields and you're running this sequence of different actions that are being performed, this order does matter. So you can click and drag in order to reassign or update that order in the stack, essentially, right? So everything runs sequentially from top to bottom. And at any time you can come in here and delete those rules if you want to in order to clear out any actions that you don't want in that. So to recap, in this lesson, we learned how to add actions at the end of our workflow transition. Some classic and most common use cases for this include the auto assign that we looked at here, but also doing things like setting field values, clearing fields entirely or maybe copying field values entirely or triggering an AI agent or webhook. Speaking of AI agents, let's move on to our next lesson where we'll take a few moments to look at how we can use those with our transitions. See you there? 8. Triggering AI Agents: In the last lesson, we looked at the rule that performs actions after a transition completes. In this lesson, we'll build on that by looking at how to trigger AI agents. Now, triggering an AI agent isn't a rule in the same way as the other rules we've looked at so far at the root level of those rules. Instead, it's nestled under the perform actions. That's the same place that we went to auto assign a work item after it transitions, except instead of auto assigning a work item, this time, we're going to trigger an AI agent to look at the work item and then do something based on whatever prompt we provide. I'm sure it comes as no surprise that when we're triggering AI, that has some of its own caveats depending on what version of Jira you're using. You do have to have Rovo enabled in your Jira instance for this to work. Rovo is Atlassian's AI platform that powers the agent infrastructure, the agents, the credits, the connection to Jira workflows and all of that. The good news is that Rovo is included automatically with paid Jira Cloud plans, standard premium and enterprise. So there's no separate license to purchase. Now, in my case, I'm using a Jira Cloud standard license without anything extra. So here is our standard for what we'll use AI for in this lesson. When someone submits work for code review, we want the AI agent to automatically run a first pass analysis on the work item for us, suggest any changes that might need to be made on that work item so that whenever somebody comes to actually start reviewing the code, they'll have a head start. So let's head into Jira and start by going to the transition where we want this action to actually happen. That is this transition right here, submit for review because when work goes from in progress to code review, it has to pass through this submit for review transitions. So under the transition over here on the right hand side, just like we've done before, let's add a perform actions rule. And this time, we're going to add a trigger agent action. Now we need to tell Jira what agent we want to use. Now, these are the pre installed agents that come with Rovo. We have a coding agent, delivery agent, or a triage agent, but some agents are only available on premium or enterprise. This is really where your plan tier can make a difference. You can also install additional agents or even create your own custom agent if you want to. But for our use case today, we want to use the triage agent. Its job is to read the work item and then triage it, figure out what's the highest priority and what needs attention first. Now, it does have a default set of commands. We could just add this if we want to, but we can customize this by adding in our own prompt. So here is a prompts that I have to analyze the work item for code review readiness, since that's moving into the code review, suggest a priority based on the description, flag any related or duplicate work items, it might find and note whether the description has sufficient detail for a reviewer to begin their work. And then this is going to give us a comment on the work item with its findings to help our team get a head start. Let's go ahead and add this. There we go. Now we need to update our workflow, and then hop into Jira, login as one of our developers, login as Ethan here. So let's pick one of these work items. I'm actually going to take this status column, move it over here just so it's a little bit easier to see. What the actual work is next to the status. So we're not pulling one of these we've already worked with in this court that's already done. Let's say, okay, let's say this build API inputs. Let's say we want to start working on this. It's in progress. Ethan's working on it. And now, okay, it's ready for review. Before we actually do this, I do want to open this up so we can see on this work item, there's nothing in the work item itself. It's pretty much just the summary. You can see there's no description. There's no comments, anything like that. But if I were to take this and submit for review, watch what happens. Immediately, it's going to start triggering this agent, right? The agents going to start going through the process. It's going to go through that prompt that we added. Then we just give it a moment to go through the process. And of course, we're watching it actually do this. Normally, when you transition something, it just happens on the back end we're not actually watching it happened, and there we go. Here are the things that it came back with and recommended. It says, Do we want to link this other work item? It found a similar work item. This one because it's talking about the API endpoints? Hm. This might actually be related to this work item, so we might want to link that here inside of Jira. We might actually want to change this rather than an idea right now. This is an idea, work type right here. And the agents saying, You might actually want to change this to a task because it seems like we're actually working on this task, right? The content is describing a task rather than a high level idea. And right now, it's saying, Oh, actually, Ethan, we're logged in as Ethan. He's the one that's doing this. We might want to change the assignee from being assigned to Dan to actually being assigned to Ethan, since he's the one doing the work on this. And now we can come in and say, do we want to actually accept this? Do we want to refine, which will open up a Rovo chat window where we can talk to Rovo and maybe refine some of these suggestions. Or we can pair this with some of the other roles that we've looked at by auto assigning it to someone on our team before it gets to this triage agent, and then maybe position the AI agent underneath it in our transition and add something in our prompt to look at whether or not the work that they've suggested has been fit with the other work that they already have assigned to them in the space. You can start to see how powerful this can be. But always keep in mind that this agent makes recommendations like this. It's not going to make automatic changes. A human still has to come in and review whether or not to accept all of these changes or not. No, it is worth mentioning that in our demo space, we only have a handful of work items. There really wasn't any description or anything further that the triage agent is going to look at to add in a comment or anything like that to our work item because we don't really have a lot in this work item. Normally, when you're working on something, you would have a lot more of a description of what this work actually is. But we can accept these changes, and then the agent is going to go through the process of actually updating those. And we can see it's been assigned, it's been linked. It looks like it wasn't able to update one thing because of a problem. You can either go through that process. It looks like the one thing it wasn't able to do was to change the work type, which is no big deal. We can come in here and update that very quickly right here. And then we could either reply and chat to open up that chat window with AI in order to try to fix that or we could just dismiss that in order to close out. So you can see how that very quickly helps us just get more organized and to triage our work even better. Now the last thing I want to point out before we wrap up this lesson is that even though we use one of the pre installed agents, that triage agent that comes with Rovo, the agent ecosystem in Jira extends well beyond those defaults. If we come back in, we could even add in another one if we wanted to. So you can see, again, with the stacking order that matters, so this one would go below the one that we already added. And if we wanted to add in a different agent, or if we come in here and look at all the different agents that we have, you can see there's a ton of different agents. Some of them are based on the license. It's not available for my current license. But you can start to see a ton of different agents that we have from a lot of different providers, right? So a lot of these are from Atlassian to do specific things. But there are some from maybe GitHub or a Cloud Agent for Jira. We can integrate that directly into Jira very, very quickly. And of course, if none of the prebuilt options fit our needs, we can come in. We can create our own agent inside of Rovo studio to really do whatever we want. So to recap, the trigger agent action rule lets us run an AI agent automatically when a work item transitions between statuses. And in this lesson, we learned how we can set that up using the pre installed triage agent to analyze work items and then suggest some changes. But again, as we saw, it doesn't actually make those changes until we approve them, and then it will go through and implement all of those changes. One last thing to keep in mind, depending on which AI agent we're using, they can consume Rovo credits each time they run. Now, each Jira Cloud plantier comes with monthly credit allowance per user. So it's always a good idea to check your plans credit allowance when you're testing AI agents, and be thoughtful about which transitions we attach them to so we don't burn through credits unexpectedly. Now, in our next lesson, we'll take a step back from the workflow editor and look at the big picture, creating a second workflow and tying everything together with a workflow scheme. See you there. 9. Connecting Workflows with Workflow Schemes: In this lesson, we'll learn how we can use workflow schemes to tie together multiple workflows. That also means we'll need another workflow. So we'll learn how to create a new workflow, too. But let's start by getting a solid understanding of what a workflow scheme is. Basically, a workflow scheme is a map that tells Jira which workflow is used by which work type within a space. For example, a workflow scheme might tell Jira to use the software development workflow that we've been using throughout this course for the ideas and tasks in our space. But maybe we want Jira to use a completely different workflow for the bugs in our software development space. To see that in action, we'll need another workflow beyond what we've been using so far. So let's start by creating a simple workflow for our books. I'm going to close out of the workflow editor that we've been using. And in our workflow in the administrative area, let's come in. This is actually within the space settings. So I'm going to come into our overall global Jira administrative settings and then come into workflows. And then let's come in and add a workflow. We're going to create a new workflow. Give this a name. So this will be our bug workflow. For the bug work type, create that. All right. So this has been created. This is just a very simple workflow. Let's come in, and we're going to do this quickly because we've already looked at how to add statuses. But I'm going to add in the same default statuses that we had before. So instead of creating new ones, we're just going to add in some very simple ones to do in progress, reusing statuses that we've used before and done. There we go. And then instead of being open when new work is created, let's take that to do, and we can remove the open status. Okay. So basically, what we've created very quickly is a new workflow that is exactly the same as the workflow when we first started this course in the software development space. Remember, it just had those three different statuses. And of course, we could add more statuses, transitions and rules, just like we've done with the software development workflow in our earlier lessons. But for now, this gives us what we need to demonstrate how a workflow scheme can handle multiple workflows. So let's update our workflow here. Now we need to tie this to our software development space with a workflow scheme, because you can see right now this is an inactive workflow, which means it's not being used anywhere. So let's hop back into our settings here and into our workflow schemes. Now, by default, just like Jira created a workflow for our space when we created it, we also got a workflow scheme. Spaces always need a scheme to tell it what workflows are used. It's just that by default, there's only one workflow in each scheme. Let me show you what I mean. We are working with the software development project. So this is the scheme that's being used in that project. If we come in here and edit this, this is how most schemes are set up by default inside a Jira. Basically, if just saying every single work type, remember work type that used to be called issue type, so you might still see that terminology somewhere in the administrative area. So every single work type inside of this project is using the workflow that we've been creating throughout this course, that software development workflow that we've been working with. If we wanted to change this and say, You know what? For bugs, we want to use a different workflow, we can come in here, add an existing workflow, and that's why we wanted to create the new workflow first because it's looking for an existing workflow. Let's add this BG workflow. Next, for the BG issue type or work type, as they're called now. Now, anytime that a bug in the space that's using this workflow scheme is created, it will use the BG workflow, right? So let's go ahead and publish this and see this in action. Now, we might come across a little bit of an issue going to associate anything, it's going to go through and check and make sure that all of the statuses are good. I does come across an issue where maybe we've removed a status in the workflow, but there were work items that were in that status. Say, if we removed in progress for whatever reason, and there were work items in progress, it's going to say, Hey, what do you want to do with these? Do you want to map them to a new status? Do you want to remove those or not make that change? It's just letting us know. In this case, because we just set this up, we don't have any existing work items in those statuses that we're removing, right? We're adding a workflow to it. We're not removing any workflows from our scheme. But if we come back into our project, let's look at the project here, just a quick way to get back to the project. We might come across an issue that we'll need to fix because I'm not sure if we were to come in here and create a new work item. I'm not sure if we have bugs in here yet. No, we do not have bugs in our space. So let's come into our work items, types. And let's add in a work type. So we want to make sure that we actually add in bugs, so we can use bugs in this space. There we go. Hit Save. Now we can use bugs in our software development space, and anytime we do use bugs, it's going to use that bug workflow instead of the workflow with all of the other work items are using. You can see the difference here, right? So all of these are using the workflow that we've created, and we've been working throughout this course. But this work type is using a different workflow. So let's see this in action. If we were to hop back into our space here, let's come in and look at all of the different work items that we have. We're going to close the menu just so we have a little bit more room here to see in the columns. So these are the work items that we've been working with throughout this course. Let's look at this one right here, okay? Look at the status, right? This is what we've looked at throughout this course, block in progress. Once it's in progress, then we can come in here and we can start to take it. We actually have it because we're not logged in as our developer. If we log in as our developer, as Ethan, he can actually take this and run it through the different workflow, right? So this is the workflow that we've set up. But if this work item were to change, we saw how we can change the work item in a previous video to a different type. If we were to change this from an idea to a bug, watch what happens. So it's saying, Okay, wait a minute. This has been changed. How do we want to map this to the new workflow, right? Okay, so right now, it's an idea. We want to change this to be a bug. And then it's going to go through and say, Okay, what is the status of that? Is all of this good? And because we're actually in the in progress status, everything seems to be okay. There's no issues. This is a simple summary of what's going to happen. It's going to change from being an idea to a bug. It's going to change from being in progress in this workflow to being in progress with this workflow. And now that it's in the Bug workflow, it's no longer going to go through that same QA process that we set up in the software development workflow. It's going to go through a completely different process, which means it can just come in. It can be to do. It can be done. It's not going to go through that QA process that we set up in the software development workflow. And the back end of that is in the workflow editor where we can see let me open these up side by side here so we can see these two different workflows under the workflows. We have the bug workflow. So I'm going to open that up in a new tab. I'll open up off screen that will pull up here soon. We have the software development workflow that we've been working with throughout this course. Here we go. So this is the workflow that the idea was when it was first created. And then when we changed it, it changed to this workflow, the bug workflow. That we just created, which means it's not going through any of those other statuses that we have here, right? In the same space, it's still used in the same space, but it's only used for the BG work type. But here, this workflow is being used for all of the other work types inside of the space. Okay, so to recap. In this lesson, we learned what a workflow scheme is. It's a way of mapping work types to workflows in a space. We also learned how to create a new workflow and use the scheme to tell it which work type to use with it. And as you might imagine, all those transitions and rules and things that we've learned about so far are included with each of the workflow, so we can customize that bug workflow even further if we wanted to. Now, in our next lesson, we'll tie everything back to our team's Agile processes by seeing how workflows affect our agile boards in Jira. 10. Using Workflows with Agile Boards: In this lesson, we'll see how workflows and Agile boards work together, since that's where our team will most often interact with workflows every day through our Agile board. In a nutshell, Agile boards and Jira are simply mapping the statuses from our workflow to a visual board display with columns. Remember, every status belongs to one of three categories to do in progress or done. The board groups statuses by these categories, too, which you can tell by the gray, blue and green bars at the very top. Gray being to do, blue being in progress, and then green being the statuses that are in the done category. Now, let's see this in action. I'm going to hop into the agile board for our space. So let's come in, and we're going to come into the space itself. And then we can hop into the space using the breadcrumb just a real quick way to get there. And that should take us to the overall space itself. We might need to go into the board view if it doesn't take us there by default, but it looks like it's loading the board. Alright, so this is the Cbon board that we have set up in our space. Now, if you're using a scrum board, it's basically the same process, except for, of course, the difference between scrum and Cbon using sprints on scrum boards and Cbun boards don't. But on the back end, the way it ties into workflows is the same. These columns are tied to the different statuses for the work items. So if we come into the board settings, we can see this on the back end, come into the columns. And we can see To Do in progress and done are mapped to these different columns. But we can see a lot of the different statuses that we've created in our workflow are not currently mapped to anything. So we can really customize this however we want on the board, and that's going to allow our users to very quickly transition statuses from one to another. So let's set this up real quick. Let's say, okay, for code review, let's say we want to add in a new status here, a new column, I should say. Add that in. Oops. Code review. And then we can map that status to this column here. And I want to actually move this. So it's going to be in progress to code review, and then blocked can be under in progress as well. Won't do is a done status. For quar, let's actually build a single column for A to work out of. We're going to take this. It's going to be after code review. So again, with Agile, you're going left to right. Ray for A, QA testing can be in the same column. There we go. So we have everything configured on the back end mapping the statuses to the different columns. Let's see how this will work in practice. So let's hop back into being logged in as a developer, Ethan. So if we go to the board in our software development project, we'll see how all of these tie in, right? So we have these different work items that are the different statuses tied to that column. So we can see this one here, if we open this up, the status is code review. But if I were to change this, if we were to change this, let's say transition this to in progress, what happens is that's going to move on the board to now be in progress. So that's the basic process, right, is when you take something and you change it from being on one column to another, on the back end, all Jira is doing is the exact same thing that we've done so far. It's going through the process of transitioning between those different statuses on those work items. So now that we've changed the column, the status of this work item is also changing as well, right? So that's now in code review. It's actually run through the agent. So you can see it ran through the same triage agent that we set up because that's part of the transition between those different statuses. I still happens on the board as well. It's just waiting for our input. Do we actually want to change the priority level of this, right? So that's the suggestion this time. Yeah, let's go ahead and change the priority level of that. It's going to update that. We can even see on the board the hot Back here. I don't know if you notice, but right here, it's saying there is a triage agent on here. So when we drag work items into that, it's going to trigger that agent, which means you probably want to go in there and check and see what it's going to do. Again, the triage agent isn't going to actually do anything without a human reviewing it first and making sure that they want to accept those recommendations. So behind the scenes, the workflow is still controlling everything. Everything that we set up is still being controlled on this board. Even the workflow schemes. So watch what happens with this bug. It's in progress. But we can't take this to code review. We can't take this to QA. We can only take this to done because if you remember, when we created the BG workflow, it only has three statuses to do in progress, which it's already at or done. We can't take it into these other statuses because that work type is not associated with the workflow that has those statuses in there. So that's where you can really get a fine layer of control over not only the workflows themselves, which work types are using different workflows, and you can really see how you can start to customize this for your team. So here's where the workflows can really start to be complex, depending on how you have it set up. If you remember, we set up some rules on our transitions. So to go from code review to A, even though on the back end, we have multiple statuses mapped in this column. When we're logged in as our developer, as Ethan, he can only transition into the ready for QA status, which means if he were to take this over here, he can only transition it to ready for QA. Even though over here is in progress, he can choose which status he wants this to be for QA, he can only see that one because of the restrictions that we have because he is a part of the developers group, and only users in the developers group can go into ready for QA. Once it's in ready for QA, watch, that's going to update, be automatically assigned to MAX. Again, that's something else that we set up in this course was to auto assign to MAX. Now, if we log in to being assigned logged in as MAX, we can see this item right here, it'll pop over here. You can see that updated in real time to being in QA. So now that we're logged in as Max as part of the QA team, he can actually take this and he can update this. Now, he can't take this to Dunn because this actually needs to walk through and needs to be on the next step in our workflow. If you remember the next step in the workflow is to transition this to being to start QA, right? So you actually have to start a before it can be done because of how our workflow is set up. So that's where we might want to come in here and be like, Okay, do we actually want only one column for QA or do we want a second column that will allow us to start QA and drag that in there so Max doesn't have to come in and open this work item up like we just did. He could simply drag it in now once it's in the status of QA testing. It's being tested. It's not ready for th qua. Now we can drag it into Dunn because he's walked through that process. And again, that is all on the back end here in our workflow that's tied to the columns on the board. So if we wanted to spread that out, we could do that. We could add a second column if you wanted to for QA. Really kind of depends on what works best for your team and how you want all of this to go. Of course, the catch to that, of course, is now as Ethan, he's going to see that other column show up as well on his board, but he's not going to be able to drag anything to it. He's just going to see what work items are currently in testing. He can't actually drag that over there because of the restrictions that we have set up. You can see he's not able to drag that over there because of the restrictions in our workflow. To recap what we learned in this lesson, status is mapped to Agile board columns. And you can even have multiple statuses share the same column. When we move work from one column to another on our board, what we're really doing is transitioning it from one status to another in our workflow. And that means all of those rules in our workflow apply also. So if you have trouble moving work from one column to another, that's probably because of the rules like restrictions or validators that we learned about in this course. We. That's a lot, isn't it? And with that, we're just about done with our course, but I'd like to invite you to join me for one last video where we'll take a few moments to reflect on everything that we've learned in this course. 11. Course Summary: You made it to the final lesson. In this course, we walked through building a custom workflow all the way from the basic statuses and transitions, through workflow rules, AI agents, and then tied it all back into our agile boards. Let me leave you with the main things that I really hope you take away from this. Start simple. We didn't build a 30 status Behem. We had a few statuses that covered our needs. If you haven't built a workflow before, start with what your team actually does every day. Only add complexity when the workflow proves that it's needed. Next, match workflows to work types. Some work types share life cycles, like the ideas and tasks in our case, but others don't got their own workflow, and you don't have to force one workflow to serve everything if the life cycles for those work types generally are different. Also, use rules to solve problems, not create new ones. You can restrict transition to control who can move work, validate details to ensure that data exists, perform actions, to automate updates, request input, to collect data at the key moments. Each rule type has a job, but don't stack them on there just because you can. Have a purpose for each one that you use. And be mindful of Rovo credits. We use the triage agent with a custom prompt on one transitions, and Rovo is included with paid Jira Cloud plans, standard premium and enterprise as of this recording. So there's no separate license to worry about, but each plan tier comes a monthly credit allowance per user, and agents consume credits each time they run. So deploy them where their analysis genuinely adds value, not on every single transition. And keep getting feedback and updating your workflows. You'll tweak this as your team processes evolve, add statuses when new handoffs emerge, remove them when they stop being useful. Test changes before you update your workflow for your whole team. The hardest part about building workflows is overcoming the belief that it has to be perfect on the first try. It doesn't. Build something that works for today. Iterate when the team needs more, and that's how you end up with a workflow that matches how your team actually works. Thank you so much for joining me on this journey. Whether you're a Jira administrator, a space administrator or a team leader, I hope you now have the tools and the confidence to build workflows that match how your team actually works. Thanks again for watching.