 Welcome to Visual Studio Toolbox. I'm your host Donovan Brown, and today I'm here with Charles, and we're going to be learning about work item rules, I believe it is. Why don't you introduce yourself to everyone? Yep. So I'm Charles. I'm a Program Manager for Visual Studio Team Services and Team Foundation Server, and we're going to be talking about rules. Okay. So what are work item rules? Why do I even care about these? All right. So when we say work item rules, what we're talking about is the ability to essentially automate the behavior of fields that you have stored on your work item type. So that could be fields on a bug, on a user story, anything like that. The reason behind it is a lot of people want the flexibility to streamline their workflow, sort of take off the manual labor of changing fields and customize that experience based off of what their needs are. When you think about the history of TFS, a lot of this stuff was done manually via XML configuration. I remember that. I lived that life for a long time. Oh yeah. So a lot of our customers have been saying, great, we really want to come to VSTS, we're super excited about it. But there's a gap here where we used to be able to customize the behavior of our work items with rules on TFS, and you don't offer that on VSTS. Okay. So we've really invested heavily in trying to bring a first-class experience to VSTS that has a really nice UI, is really simplistic to configure, and makes it just, like I said, just dirt-simple for you to configure rules. So you're trying to give me the features that I had in TFS but not make me become an XML expert at the same time? Pretty much. I appreciate that. So pretty much when you're thinking about rules, this is a process admin space. These are administrators, and whether you're thinking about a large enterprise or even a small shop and you have Joe Schmoe there, you want him and everyone to feel empowered. They can very easily come in here and configure rules on the fly. Awesome. Cool. So show me how they work. All right. So I have a bug here. It's called fix error and rule dialogue. Okay. So what you'll notice here is very generic work item type. We have a remaining work value of six. So what I'm going to do is I'm going to go ahead here, and I am going to change the state to resolved. So you notice something happened here. When I changed to resolve, remaining work got cleared out. Right. So you're telling me that without the rules though, this wouldn't have happened, right? Yeah. Exactly. So without the rules that remaining work would have been six, I would have closed it and then I as your manager would have been confused on how is there still six hours remaining and you claim to be done with it already. Exactly. Got it. So you think about these work item types, you're pumping through these as a dev, multiple times a day. You're not necessarily thinking about updating every single field on all the work items that you're updating. So by putting rules in place, we can automate that behavior for you and take care of some of it. Got it. So how did we define this rule? How does a rule actually get defined in? All right. Cool. So let me just flip over here and I'll actually show you what we do. Okay. So if you look here, this is in the process space underneath the count settings, and we're underneath the fabric and fiber process underneath the bug work item type. When you get here, it's literally just an inline experience so you see here, I have a rule, I've called it resolve bug. So essentially what this rule means is anything defined here should happen when the bug is in the work item state resolved. Okay. So here I've just said when a work item state changes to resolve and you notice we get that left to right experience just natural reading. So when a work item state changes to resolve then clear the value of remaining work. So what other conditions do I have? What's in that dropdown? All right. Cool. So we have a host of different conditions that you can choose from. They are differentiated between what we call state-based conditions and field-based conditions. So a state condition is literally what it sounds like being able to automate behavior based off of changes to the state of a work item, and then field-based conditions being, I want to call something to happen based off of the value of another field or if a change is made to another field. So those are the two different types of conditions. Okay. And then you can do a host of different things. So if you want to do something when it's created on a state change. Got it. When it's in a specific state for a duration, when it's not in a state, if you want something to happen, and then the other one's the value of equals, not equals, and these should look familiar to customers who are used to TFS and the XML configuration. Behind the scenes, you're still getting the same sort of configuration when changed, when not changed, but they're mapped to these much easier friendly UI. So it's same power, just a much better user interface and experience. Pretty much. Got it. Okay. So you've shown me this rule. This is the rule that we already had applied. Show me how you actually created this. How would I create a new rule? Cool. So if you want to create a new rule, let's go ahead and get started by clicking on new rule. And what we're going to do is we're going to call this one change in priority. Or actually, you know what? Let's call it a high priority bug, because what we're going to do is define behavior that should happen when the bug is high priority. Okay. So what I'm going to start with is by defining my condition, I'm going to say when the value of priority is one, so one in this case being the highest priority. Okay. Then what I want to happen is I want to make required risk, because this is a high priority bug. I want to make sure that I want to know what the risk is. I see. So this is just one type of a mini scenarios that customers might try and configure. But we just go ahead and click Save, and you've saved your rule. So now the only thing you need to do is flip back over here, and let's just close this one. Yeah, we don't think confirm our changes from before. Now let's create a new bug, and actually, let's refresh here, made some changes, and then we're going to create a new bug. You're creating a new bug, but would these rules also apply to all my existing bugs as well? No. So they do not go back retroactively and apply it would. So let me step back. Okay. So it depends on the type of rules. So if you're setting the value of a field, we're not going to necessarily go back and update the values of all fields that all work has been stored in the past. What would happen is if you create a rule, and then you open that work item, that old work item, then that rule will trigger when you open it on. Then when you save it, it should update. But we're not going to automatically just change all of your history. Great. So if I were to open the one that we were working on before and change this priority to one, that rule would then affect it and force us to do it. Exactly. Why don't we just go ahead and do that then? Okay. So if you open up this one, let's go ahead and just change this priority to one, and then all of a sudden there you go, risk is required. Got it, got it, which it wouldn't have been otherwise. So they take instant effect, and this now affects all the bugs that I opened from this point forward. Exactly. Got it. So one other thing that I have a question about, if you go back to where we define the rule real quick, I don't recognize this process template, right? I've been around the TFS for a long time, and it was either CMI, scrum, or the agile template, and it looks like you've created your own template. Can I apply these rules to like the base templates as well, or do I have to use one of my own templates? That's a really good question. So no, you can't. Let me just flip back over and sort of accept the context here. So just like you said, we have three out-of-box templates. We have agile, scrum, and CMI, but with the inheritance process model, what I did is I just created an inherited process from the agile out-of-box template, and now with that inherited process, I can add whatever customization that I want to that process, but we don't actually allow you to come in here to agile and specify rules, and I can actually just show you, so if you were to come here and you were to flip to work item type, you see that rules pivot doesn't even exist there. Gotcha. And we also do go ahead and sort of give you warnings here at the top that system processes cannot be customized, so you have to create an inherited process to add customization. All right, got it. Very good. So right now this is in preview, or is this ready to rock and roll? So this is in preview currently. We're actually preparing to ship at GA at the end of this current sprint we're in, so that would be over the next three weeks. Got it. Customers would start seeing this, so it's incredibly exciting. There are some other features we're adding to enhance the experience, and I want to point out one thing that we're really making a very conscious effort not to ship this and walk away. What we want to do is we want to leverage telemetry, we want to leverage customer feedback, and really make sure that we're investing in this and continuously improving the experiences we're offering rather than just shipping this and saying, hey, we're done. Yeah, with the demand for customization that I hear from all of our customers, there's no way they're going to let you walk away from this. Exactly, exactly. There's no way. They've been dragging their feet to get to VSTS because they can't customize it like they do in TFS. Being an ex-process consultant, I don't always agree with all the customizations that they want, and I thought we were doing them a favor by forcing them to use the tool correctly, but I digress, and I think that people are going to be really, really excited to see the level of customizations and how easy you're making it, because I remember the days of living inside of that mountain of XML. That's how you should talk about with customization. Like it's just a mountain of XML, right? You download the process template, it's just XML file after XML file, and trying to figure out how the rules work and testing it was a nightmare, but now it seems like we're making it literally a really nice experience to go back in and make those customization, which is a plus and a curse in my opinion, because you're making it so easy, they're going to go nuts, right? But it's cool to have that power. So thank you so much for coming and showing this stuff. Is there anything else you wanted to say? Yes, I mean, I think you made a really good point with just sort of the simplified experience that we have here, and that's something that we've really put a lot of effort into. I mean, even if you think about just sort of this language here, Win, and then we did a lot of customer feedback, we brought in a few customers to actually come in and look through early prototypes and tell us if the language made sense. But what we really want to do, like you said, is just make it incredibly simple for you to come in and define these rules. And to your point about sort of allowing customers to do this customization, it really is the valuable feedback that we get from customers that's going to help us improve it. I think you make a really good point in that people will come in here and they will try and do numerous, numerous things, but we can only imagine or assume as so much of what people will do that that type of behavior is what's going to help us figure out where we're going wrong or what we're missing. So definitely encourage people to play with it and take advantage of it. I am sure they are going to shock you with some of the stuff. I remember them doing an XML, it's going to be an adventure, but I'm glad to see this stuff finally making its way to VSTS so that we can remove one less excuse that they have for not going from TFS to VSTS. TFS, great product. I love it, it has a place, but if you can get to VSTS, you definitely should. Yep, and we definitely want to make sure we're building that bridge to help people get there. Awesome. Thanks so much for coming and hanging out with us today. Thank you so much for seeing us, guys. Bye. Thank you.