Name: Automation at scale: Governing growing Jira instances
Uploaded: 2026-04-23T14:16:05.137Z
Duration: 44 min 40 s
Description: Automation at scale: Governing growing Jira instances

Transcript for "Automation at scale: Governing growing Jira instances": Hello, and, well, welcome everybody. We will get started in just one moment. We'll allow just a few more people to enter on, and we, yeah, we will, get started just here very shortly. That is true. Okay. I think we'll get started. And if more people join then they can kind of come in where we are. So, thank you very much all for joining today's webinar. Today's webinar, we are going to be talking all about automation at scale. So governing and growing your journey instances, but in a way that makes sense for the business as well. So myself, I am Dan Toombs. I am a senior solution architect here at Outfire. But today, I am not alone. I am joined by Adam, who is from Diviniti. So, Adam, welcome, and could you quickly introduce yourself? Of course. Thank you, Dan. So as as Dan had mentioned, I am currently at the site representing the divinities, and I am the senior Atlassian consultant at the divinities, which and so therefore, automations are basically my bread and butter in days, in my day to day work. Amazing. Okay. Cool. So let's jump right into it. So today, we're going to cover a few topics. The first, we obviously want to make sure that we explain what automation debt kind of actually really means. Then we're gonna look at the few different flavors of automation in Jira, kind of what you're gonna get, out of the box and what you're gonna be able to look at from kind of extensions with the marketplace. Then we're gonna talk about some real world use cases, and Adam's gonna give us an insight to all of the great customers that he's working with over at divinity. Then we're gonna look for some demos. We're gonna look at some feature requests and how that can be enabled using both JSM and Jira. And then we'll go and also think about how to enable self-service with JSM as well. So we're gonna look at just a couple of different ways, and then obviously finish up with some q and a. Now oh, okay. I think there is just a problem with some hearing. Let me just give me one second. Let me just pause there and just make sure everybody they can hear. Let's let's just hope that it's only one person because if it's a whole. chat, then that might. be the shot your end then. Yeah. Let's, Okay. Okay. let's let's you hear me, for example? Is that okay? I I hear you all fine. Let me just make sure that everything is okay. Give me two seconds. And, let me just hope that this is, coming through. Okay. Oh, perfect. We are hearing okay. That is great. So let me reshare the screen now that we've got some things confirmed. Okay. Awesome. Right. Thank you very much, Tat, for letting me know that they can hear us. So, yes, we're gonna look at some demos. We're gonna look at some use cases, and we're gonna finish with some q and a. Lovely. So let's start with that first point out there. What is automation debt? Now at a high level, it is basically the accumulation of lots and lots of little things. There's nothing that you're gonna be able to point to and be like, that is automation debt. It's usually a case of maybe poorly designed automation rules, maybe things that were suitable at the time, no longer suitable, things that have become duplicated. And we've all seen those with maybe lots of due date fields. That's that's typical. But things also around maybe unmanaged rules. In essence, it's anything that makes your system harder to maintain over time. So it's very similar to technical debt and things that you would have heard throughout your own journey, but it's it's based just solely for automation here. It can come through some other methods and they are around maybe high entry points. What I mean by that is you have to have certain skills in order to be able to do that. Now this is very, very typical when you think about scripting that you have to know the script language in order to be able to write that proficiently and get the result without breaking too much. Or it can also come with the overreliance on different additional products and services. And when you have those, that can also help accumulate levels of, automation and technical debt. So very bluntly, it is when the cost of maintaining your environment and automations outweighs the benefits that you're actually getting, and that is automation debt. Now McKinsey ran a study a few years ago with some CIOs. One of the leading CIOs out there in the world put out this really great quote that we we kind of pulled together. It's basically saying that when they're reviewed and understood and changed their perspective on how they manage technical debt, they went from 75% of repayment to 25% allowing for far more productivity against time than the tax before. Now this change perspective is really because they went from dealing with symptoms to dealing with the underlying problem, and that allows you to, like, get to grips of what is causing that tax, deal with the problem, then you're boosting and really kind of moving forward. But it's not a one and done situation. It is very much a case of as they are saying, they're still having 25% tax. They're just reshifting that focus. Now, if we think about the Atlassian ecosystem that we are all here for today, there are some common challenges that you'll see very specifically out there with Atlassian automation debt. Now, there's a couple of big ones that we typically see, and they could be around lost time because of misaligned rules. That's very, very common. It could be that you've got hundreds of rules and lots of people making them and kind of real no lack of oh, sorry. There's no real central visibility, which means that it's very, very hard to kind of deal with, in a scalable manner. Very typically, you'll also see things like duplicate or conflicting automations. And if you've got two rules fighting over the same field to be updated, that's gonna cause a bit of an issue. And also you can get things like mystery behavior, things, maybe rules that you all forgotten about. And when all of those happen or some of them happen, you'll typically find that your workflows will break. And that fragile workflow, when it does break, you know, we need to be able to well, realistically, teams never stand still. They need to constantly improve their processes, in order to kind of adapt with the real world. But that means our automation should adapt with them. And when we forget about things, when it's mystery behavior, all of that's gonna kinda break down teams from actually doing what they're meant to be doing. The big one though, is around difficulty of auditing and updating at scale. So there's a couple of things that we can do about this. There is naming conventions, deciding what, who, and why can make rules. So Thinking about what's the difference between team managed and centrally managed. Of course, the one that we're all going to really hate, but I have to say, is about documentation. We really have to be able to understand what we need as a document so that the next person can come along and instantly jump in rather than having to kind of get distracted. So that's a lot for me to digest immediately. So, Adam, what are our options to automate within Jira? So when we think about that thank you very much, Dan, for this introduction because it is very important to mention that you are never going to know when the actual depth starting to pile up. It's something that's happening, and you are only going to notice it whenever you take a look at this And at and you are suddenly the organization with over 500 users and over 2,205 to to fifty, hundred, or many more automation rules, which are scattered across your whole instance. You don't know what's going on and where, and, actually, how can we manage that. But there are ways and levels how we can approach that. So we what we, as a social partner, what we, as a team, firstly take a look at and we need to think about is the actual stack of the Atlassian product. So within the Atlassian itself, when you think about the automation, you immediately think about the automation rules. Like, those are the rules that we are that many of us are familiar with when it comes to products themselves. This is something that allow you to extensively affect and operate on your Jira data based on the different type of the triggers, automations, conditions, and and on all of this other needs stuff that allow you to automate your day to day processes. The great thing about this from the overall perspective is within the fact that it's being developed extensively. There's a great focus on that, from the Atlassian site as well. And when you take a look at the comparison of what they can do, like, three to four years ago to what they can do now, when it comes to your day to day, when it comes to integrating with external systems, your databases, infrastructure, deployments, and all of those things stuff, that's, like, the great area of expertise. But it's not only about that. It's also about the it's also about the post functions or things that you can do within your workflows when you can condition them to behave or fill out the data based on the certain information directly into them. And the last but not least, like, something that we all often hear about, is the artificial intelligence at the Atlassian site, Atlassian intelligence, namely, global agents, which they can not only automate your processes and help with your day to day operations directly onto the tickets by the predefined actions, but they can also be launched and used and utilized efficiently within that as an ecosystem. So to sum it up, there are plenty of options that you can do here, which can help you manage your processes. But what is very important, that also means that there are plenty of areas that can go wrong when planning ahead and building and scaling up your automations. Because if you miss the proper labeling, a certain semantics that you would like to do, structure around those rules, then at some point, you are going to find yourself in situation that I have described at the very beginning. A lot of information, a lot of data, your data usage is being used extensively. You hit your limits very fast, and suddenly you need to calm down your rules, find the optimizations. And suddenly you've got a very simple, easy to use system, which is very easy to use and generate the rules for, but the amount of time that you spend your maintenance is quite extensive. That's when it is very wise to think when you build and think about your strategy is to extend what you can do, what you can do natively based on the application. And this is something I'd like to focus on the next slide there. So when we think about Atlassian stack, we can do a lot. But there are plenty of options or the approaches when it comes to how can we we how can we take it even further. And besides the fact that you've got plenty of option available for extending this on the Azure marketplace, the app file applications, such as JWMB or JSL, can help you with building your own automation rules, which is one of the things which is very important. You can build them in a more extensive way and the more business cases and scenarios when you take it when you compare them to some of the things that you can do within the automation rules themselves, have a better control over them. And overall, if you think about it, there are also a part of the area that when you build them up and generate them, you've got your own backlog of them, one place where you can sort them out, and generally building a policies around them or planning your costs for the usage is going to be more efficient at some point when you scale them up. But what is very important to mention, which I'm going to cover a little bit when we talk about about the use cases, is the fact you do not have you do not have to necessarily pick. You are not forced to use either out of the box solution or if you invest into the plug in, just use the plug ins. They complement each other. They are the tools that you can use and work, within each other, and they can help and complement their cases, your business processes, and overall. Of course, a proper governance policies and the document documentary structure for your rules is still very important, but you can pick and it generally build this across a certain strategy. So to focus this a little bit more to give you a context of what we, for example, did for one of our past customers, how we are working with them, Let's start, with the governance, for the financial and high regulated companies. There are, of course, quite a few benefits that those companies get. They are not that different from us when it comes to the, from from us for the private sector, when it comes to the building the revenue, finding the optimization, and doing all of the stuff that helps them grow or operate on their day to day basis as much efficiency as it is possible. But what is very important in that context is with the fact that when you take a look at, this from the perspective, it needs to be highly regulated, and you need to have a place where you can store and manage this information under this place. And what is explicitly mentioned in here, but something that needs to be that needs to be spoken, loudly and exclusively is the fact that margin for the human error is very low. And even if there is, there is a very high need to be able to find when this error happened, outdid it appropriately, and first and foremost, never allow the situation to actually get to the point when this mistake is happening. What the other applications such as JW and JSO allows you to do, if you maintain a better control over those rules and if you manage those outside of not only having the automation, native automation within your Jira, it's much easier with the usage of those application to actually control the amount of rolled out changes, rolled out automations, rolled out scopes, scripts, codes, and any other of the stuff. And if you are looking for the audit logs and actually finding, okay, so where did the error come from? Was it from the human side? What happened in here? The amount of responsibility and the overall maintenance is going to be lessened. And if you add to the benefit of that that you no longer need to think about your limitation on your own, because this is also very important. It'll in those highly regulated environments, limitations, when it comes to automations, they might be very fatal for the businesses. If you reach that and you actually got a gonna get stuck, with the amount of the things that are happening across them, then for your business, it's not only about the efficiency in your revenue, it's also about the risk of the breach of data or the risk of your daily operations. With JSOH and WAE, because of the benefits that those apps are providing you with, you are no longer that at risk with that. And if you have a proper policies, because remember, every every error or every mistake is happening around the humans. So if those humans have better tools to manage that easier to maintenance, then the probability of the mistake is much easier. And, of course, as I said at the very beginning, whenever there's, like, the rolling out, you add more services to your catalog, you add more customers to organization, or even something more, team level when you add more TPU or department in your organization, expanding those with the preconfigured set of rules built within those applications is much easier to do than a copying over and duplicated some of the automation rules within Atlassian. Still possible, but we are looking at the efficiency and the proper scalability in the structure. And that actually brings me quite smoothly to the next, example when you think about the working, not only from, let's say, tech side of things or regulatory side of things like IT. We're also thinking about, okay, but can it be actually used efficiently when we work around this for the manufacturing companies? And there is a few cases. Like, the one example that we had, in the past that we analyzed, that we wanted to implement and went through was within this situation not the case when you've got the processes revolving around only. Here's my quotation marks for the software because those are very complex processes. But let's talk about something that is more physical. Actual hardware that is being stored into the magazines, actual equipment that can be damaged or destroyed or stuff could be happening with it within the real time. In this type of the companies, whenever you are working on those activities and you need to scan this on your daily basis, this hardware that is coming back and forth into your stock, when you need to update the information about the current state of the repair, when you are in a need of having all of the sock inventory built around from different places, updated on almost an hourly basis to make sure that all of this either working properly or the people who are focusing on that is working on this already. And we know to the very hours when it's going to be happen. The automations there are very important. And why it is also important to mention those, the channel applications, what the app for apps apps can do, how they can complement the automations there. Because it's not only about the limitations of the automations when it comes to the amount of usage or the sheer size of the stuff that's going to happen. But when eventually, when you think about integrating it or building the custom scripts or some custom also custom connection, middleware between your, let's say, stock magazine software and the software that you have within your Jira, This is where those plugins play a great role to actually manage, flow, and actually be able to utilize those automations efficiently. Of course, the same principles apply. Proper governance, people who need to take a look at it and work on this very efficiently and, you know, have a proper policy in place before you extend this with these options. But what is actually important there, that is also a great way to actually utilize and convince people who needs to service those machineries, and they need to focus on the actual work working with the equipment or inventory itself that in the background their system is working, it's being optimized efficiently. And let's say the information when they scan the tool or when they put the information to the mobile Jira application, that they are going to fill and adjust the data either within the assets, within those configurations, and when they are actually doing this. And why is it important? One of those things is named directly into one of those bullets. When you've got those ISO standards going on, when you've got other audits that are coming for your organization and you need to actually undress and take a look at this, you need to have a system that's going to be able to retract every possible action done manually by your core employees or the contractors that you are in collaboration with. And that's where those applications are shining, and this is how we actually improve that, not only the automations, but also the rules, Ruby scripts, and all of the stuff that is very essential for this JSON. So that would be my part to talk about those cases, and I believe the stage in our studio is now coming to the den. Amazing. Thank you very much, Adam. There obviously, some very detailed use cases out there. You can see some similarities, for yourselves. Now we have two different demos for you today. We're going to look at one that's kind of more point clicky, very much more about the the no code style options that we're going to get with JMWE. The code stuff is nothing and we're gonna start with a quick overview and Yes. That's true. We've lost Adan for a little bit, but we are in touch with him, and he'll be getting back to us. Yes. Exactly. He lost his connection, but don't worry. He's going to get back to us exactly like, like, exactly like I promised. Was I was I disappearing? It it disappeared for around fifty seconds. Like, unfortunately, for the crucial part when you started, and you started to show us a video, but you need you you course I did. I can hear you. I can hear you, Perfect. and I. hope the rest of the audience can hear you as well. Awesome. Right. So we will try the quick overview and get going again. Okay. So JM big for one that you would expect, which is decisions who follow these as etcetera. Happens in that process have an action. Now the second part is actually around shared actions. This is the bit that Adam mentioned earlier, which is that we can, if something is duplicated and reused, we can actually create templates effectively and reuse them across. Now the other parts then are something that you'd be more familiar with from native automation, which is event based actions and scheduled actions. So if on a timeline or on a specific use case, if this is the trigger, then this happens. Now both of those are built in if, then, if, this, then, that kind of style. What's the condition? What's going to happen from that? You can see there's lots of options. Now the specific, more simple use case we've got here is that a software team is using JSM to help filter out some of the requests that get to their backlog. We've got one here that is going to be asking for the ability to bulk update users and they want to be able to work out what's going on here before they actually commit to doing the work. Now this is their workflow and you'll see they're going to do some reviewing and then they're going to either push it to rejected or approved and we want some actions to happen on both of those. We're going to go ahead and actually look now into for the specific workflow and we're going to find our feature request workflow that we have and we're going to edit it. Now we get in this, you'll be very familiar with this. I'm sure if you are a Jira admin and we're going to find a specific transition that we want and we're going to add a performing action or those post functions if you're still used to the old workflow editor. Now in this case, because we want to now effectively copy our feature request in our JSM project work item over to our software project software space. We're going to use the create issue post function and we're going to just fill in this wizard. We're going to say which project we want it, what work type is it, and then start filling in the details. Now you'll see through here we can choose whether we want to copy all fields or we want to copy comments, or we want to specifically state which fields that we want to copy. In this case, that's exactly what we're going to do. We're going to add the description priority, which is going to copy those across and we're actually going to add a specific specifically state in a script format what that intention is. Once we're ready, we're going to hit Add. Now, we also, because we want to keep our customers informed of what our teams are deciding, is going to add a rejection comment. Again, we're going to go through the same process, add a post function, add a specific comment one, and we're going to now add in here. Now you can see I'm starting to use some dynamic variables again with the two curly brackets. This allows us to add in a level more of, that's going to offer a better customer experience but still in a automated standardized way. So we're not going to have our agents speak over or go beyond what there is originally intended. In this case, we're just saying, hi reporter. Display name. Thank you for raising, but we're not going to do it. Once we're ready, we can save it. Now in action, this is what it would look like. Your team would push it to support. They would do the review and in this case, we're going to decide to approve that ticket. Now in the background immediately, JNWE has created a linked work item. Now you can see in the summary, we've pasted a little bit of standardized text, new feature from customer and automatically copied the previous summary across. It allows us a bit of opportunity how we want to work. Now in this case, we're going to reject the comment now and see that we actually are going to have our comment automatically posted for us straight away. We don't have to do anything. Our agents are saving time by not having to do that response and they can immediately go with it. Okay. That was a bit of a whirlwind. I understand, but there's a lot to cover in a very short time and and we can always follow-up afterwards. But what is the slightly more complex one? Now we've already heard two use cases in the past, but there is a third one and this is actually something that comes from one of my stories. Now in a previous life, I was a Jira admin like probably many of you here and I took part in an internal hackathon. Our subjects that we got was that we had to improve internal life. So as the Jira admin team, we decided to see if we could make a self-service portal. We already had our processes about when Jira projects should be made, Jira spaces, confluence spaces, updates to custom fields, etc. We thought, well, it requires a lot of manual effort. Why not let's look to see if we can make JSM forms and use JMWE to handle the automation between them. That's exactly what we did. In this case, we've already got our ticket made, but you can see here that we just click on and save it. There we go. Suggesting make a point. Then we've got the summary is our new Jira project name that we're trying to pull out. We've also got an attached description here so that we can know what the project description or space description might be. We're actually saving the reporter as the person who might be a new space lead that we always need to know about as well and we're going to work with that information. Now if I keep fast forwarding through, we're going to now create inside JMW an event based action. This would be what you might be a bit more familiar with with native. We're going to still have our trigger point. We're going to say that when an issue is trying to work item is being, we can of course send you the recording. I've just seen that comment in chat. We will send those later. But when the issue is transitioned between these two points, we're going to look at this scope. We're going to say if it's in this space and this issue work item type. Then what we're also going to do is specify the specific request type that it must be. In this case, it's about requesting a Jira project. Now as a good agent service team should be or as a good agent should be, we should always be making sure that our customers are informed as possible. In this case, again, we're going to provide a comment to them, letting them know what we are doing, even if it's through an automated fashion. Again, we're saying, hi, reported. Display name. Again, we're trying to standardize but still be dynamic to this situation. Thank you for raising the ticket. Now we're going to go ahead and automate creating this Jira space using the details you have provided. You can see here I'm listing out what they should be, project name, key, description, etc. Once we've gone ahead and may finish the typos, I'm going to actually start entering the issue custom fields, sorry, the work item custom fields that we need to put. As you can see, I'm adding in the description here, the reporter, the key, the summary as the name of the project. Once we are all ready, we can go ahead and click save. But that is our communications. Now we need to actually work on creating the webhook through the API call that we need. We're going to add our build our own script. Now just for time, I've gone to the Atlassian API documentation, found what call I need to make for Jira projects, and I've added it to the screen. We're going to just work through all of that detail now. We can see that what the body would have to be in terms of the specific call. We've understood what URL we need to go to. We've understood what the headers need to include, which is basically the authorization, so that username and the API key that we're going to do, and we're going to add those to our headers. Now, obviously, I will not be showing an API key out to the wild, but you can imagine this is exactly where you would be putting it right now. Again, I'm just adding in the final headers. Again, application JSON accepting what we've got to do. This is where again, you would add in that user authorization. Let me just wait for that. Now once we've completed this, we need to go through the body. Now as you can see, there is a lot of information here that we can cover, but we haven't asked that everybody when they're filling in their request form to give us this. But in theory, you could specify every part of configuration for a JiraSpacer, permission scheme, notification scheme, workflows, etc. In this case, like I said, we're just going to keep it a little bit simple. I'm shortens the JSON file, that payload that we want to put and specify the specific fields that we want to make a call out to. Again, I'm asking for the description for the space description, what the new name would be, what the new key would be, and that's done. Now once that is, I've come back and added the actual authorization, this is what would happen. You can see our ticket is transferred, moved to in progress. We're going to go ahead and action. You can see that a comment would have been added If I search for the project, it is created here and is copied across all the values that we would expect to do. Now, that again was a little bit of a whirlwind, but there is key things that I want to just call out, which I think is always key. Adam's done a great job doing it so far, which is the common question we get is, what's the difference between native and marketplace? It's always a really, really good question. I think a lot of it comes down to maybe some of that centralized management and governance that we typically want to talk about. Where they are kind of admin controlled and admin owned, it is a great way to make sure that we understand, you know, these are the things that our system, wide, these are the things that every part of the business relies on so they're gonna be managed as they should be. And maybe what we wanna do is allow native automation to be team managed and allow the teams to explore new ways of finding and improving their processes, let alone, of course, for also working with Rovo. I think that's a key differentiation that we always like to say. Now, let's move away from some of those demos. If you've got any questions, please feel free to share them out and we can obviously share those demos later as well. We have spoken about two specific examples that are ITSM or ESM related. But how can we kind of elevate with Appfire and DaViniti in general? Now here at Appfire, we have four main portfolio focus areas. They are enterprise strategic planning, so planning, tracking, delivery at scale. You've got ESM, which is around the process automation and anything to improve your service delivery regardless of the style of the team you ask whether your IT, marketing, HR, legal, facilities. There's lots and lots out there. Now of course, you've got platform administration which is helping all of you great Jira admins in the world kind of understanding what you can do to help that governance and scale and knowledge management. Now this comes around time and time again but it is really important that we take care of our knowledge, especially in the world of AI now because obviously that's what's going to give us the best value from it. Now those are our four main portfolio focus areas, but of course, everything is underpinned by workflow and automation and it is the backbone to any successful and productive team. In terms of end to end service delivery then, as I said with those two demos having a slight ESM lens, how would it fit into the bigger picture? Now, JMWE, maybe along with some of the other apps that exist out there, things like chat for JSM or dashboard hub for great BI or importing tools, or even something like Time two SLA and Camera Responsys Pro to enhance native functionality can really help teams elevate to their full potential. So that is our fight. And, Adam, can you just help give us a quick overview of how divinity may be able to help? So what we essentially do since as the company, as the social partner, the consultants team that usually is working, we are no longer just the guys from the software and the tool side of things. What we are trying to do then is we complement our skills and knowledge from the different areas of expertise, be it the manufacturing processes for the companies, Sky and flying business as fintechs, of course, PMOs and ITSM went from the overall more general perspective. And what we are focusing, at this stage is we are not only taking look, okay, Let's just provide us with information. What are you what are you expecting from the system and exactly what are we going to look at and automate? We do the whole audit of your processes. We take a look from discovery perspective. We discuss it you know, your day to day operations, what you're actually doing, what are the missing areas, what we could extrapolate based on our experience and the frameworks that we are aware of. And based on that and the team of this whole webinar, we are not only setting up the proper setup of the tools themselves, but we also recommend what can you do within the Atlassian ecosystem and its products, what can you do natively, to what extent you can use robo automations or native post functions for your processes, as well as how can you utilize efficiently other tools within the company, within the company or the one that we are aware of and are familiar with, like j s or j w m v from Fire. And then we apply this on your processes and find the business benefits of that. So you're not investing into only the improvements and the classic, okay. So how do I build a pro proper automation rule? But we're looking at we've got the incident management in our organization, which is not being utilized efficiently enough. We've got a shop to floor operation model when we operate with a lot of external contractors and a lot of inventory and a lot of inventories we need to update on your on our daily basis. I need to have the proper information. We'll help you find the missing points and address those and address those areas as well. So if there is any type of the business, a proper person from this field and from this information, not only provide you with a nice and proper PowerPoint of what's the missing areas of what you would like to do, but also help you configure it, implement it within your organization, train your end users, and help you with scaling this app. So you are going to have a at the very least, you'll get a proper template how to do things from now on, how to take a look at them, and it's going to be only up to you as the organization to decide whether or not you'd like to do this further with us or on your own with your fully aware knowledge and the practices that we could do for you. Awesome. Okay. So that is, the end of today's webinar, but, of course, we wanna make sure that you guys have a chance to ask us any questions. I believe I can see there. So That's the that's the best way, to give the place for the question. Okay. So any questions, and then we lost him. So that's, like, the perfect opportunity. Oh, We've lost you. for about five seconds, and you went once again doing the crucial part. So Of course. I don't know what is going on with my Internet today. So, Adam, do you guys provide training for newbies around this? Sorry. Could you please repeat? Because now I maybe I haven't heard you. Sorry, Dan. Did you see me? Could could you please repeat? You're muted. Let me just come off. Hopefully, this is a little bit better. We will see. Mhmm. Okay. Can you hear. me? Okay. Yes. I can hear you, and I can see the I can see also the question. Thanks. I know what you've been asking for. I didn't want to miss this. Yes. I've seen the question. Yes. This is something that we do. We do train the newbies. We, of course, adjust the agenda, in a way that's going to, you know, best to be applied to the organization. So it's not only about training in general. Sometimes it is if it's something that we think this is going to be the most valuable for the organization. But if you are looking for the experience more adjourned, more adjourned, with the, let's say, your day to day processor, or would you like to apply this in the real life environment, this is also something that we do. It all depends on the context, your actual business is what are you looking for. Hopefully, we can get to that question. That's amazing. Okay. So how would we want to prevent teams from creating duplicate or conflicting automation then, Adam? So, that's not, that's, that's not actually that easy to do because this is something that, of course, you can only do when you've got the proper processes in your governance of place. There is not, like, out of the box features that, like, allow you to do so. It needs a certain process in place. For example, the way we do that and the way we recommend it for our customers, is to use the proper labelings. So, essentially, whenever you've got the proper semantics, for your either automation's rules, post factions, names, or anything that you set up, be it within the Appfire application of the automation app, there is, like, the whole checklist that needs to be done. Before we add this particular automation, let's just type in the section or the label that this has been approved across the whole organization, check from the list that what's already available in there, what are the potential causes, the proper description of this automation does. And usually, that's just enough. And why you why you think it sounds simple, like, the proper labeling system or the proper policy in place, but in the end, it's always going to be a chance for you to stick to it and something that needs to be taken care of whenever there's, like, the, as I said during the webinar, there's, like, the additional department of the new process at TriNet. So this is where it but it is crucial because as Dan explicitly mentioned and as I have discussed during this call, it is very important for you to know that at some point, those policies needs to be done. Those checklists, they needs to be in place because you are going to get this guys, and you won't even notice one. And we've got the next question. How does JWMP help with compared to native automation? So, Dan, that might be best for you. From your application overview, what would you, recommend here? If, of course, we can view. That's that's the question. Hopefully, you can hear me. My does seem to be a little bit spotty today. Of course, it is. But yeah. So how does JMWE help the governance compared to native? And I think if there is a this is I was mentioning about the split. So it is really key to work out, as you kind of develop your automation kind of strategy going forward, what, centrally managed versus what you would allow your teams to go in ahead and and try. Now, native sorry. Because native automation can be used for project admins and it can be allowed for individuals that have that power to kind of try things, that is where we tend to say that is great for them to go ahead and do. However, we would say because things are hidden and can only be managed by admins in order to use JMWE, that is also a really, really great spot. So anything that is process orient, like very specific process orientated that can be attached to specific maybe moments within a workflow or something else, that is it. Now I know that doesn't technically kind of make a difference, but it also all comes down to kind of that level of governance, how you want to think about the split, how you want to think about where you want to maybe best use, as Adam said about, like, maybe the robo tokens and using that within automation and the the limits that are presented there. There's there's lots of things to consider, but ultimately, I think a lot of it will come down to that process. Okay. And that is the questions so far. So we will give it a a couple more seconds just to see if anything else has fled through, and if not, we will wrap it up. Okay. I think that is it for today's webinar, so thank you very He he does not have a, chance to, like, some, to Dan doesn't have a chance to say, the proper welcome from Hyde. It's always the most crucial part. So maybe to use that benefit, I'd like to say in your name then and in our name together, thank you very much all for attending today and for listening to us, about the governance automation policies. As, mentioned during the chat, the recording is going to be shared with you. And, of course, if you are interested in hearing about it more or discussing even further, you're more than welcome to follow the newsletter, our company, or even the the media's newsletter about what's happening and how we are operating. Thank you very much, and have a great day.