Transcript
I'm Garima Arora, Product Manager for our platform team. Joining me today are Ajinkya and Amit. They're going to talk about enhanced task controls and execution in RMM. We'll quickly run through the agenda. Ajinkya, if you mind going to the next slide, please. Thank you. That's the agenda. We'll quickly learn about the program. Jumping onto the next slide. For those who are new to office hours, what we do here, we provide live product demos, followed by focus Q&A, and we look at new features, standard use cases, and most importantly, the best practices. Why do we do it? We want to have a direct dialogue with you to get feedback and help you with any queries. We are here every Wednesday, 11 a.m. EST, mark your calendars. Quick check on housekeeping. Next slide, please. We send all the recordings of the sessions to the registrants within 48 hours. These are also available on YouTube. You can play the playlist for ConnectWise product office hours. All of these are also on our university calendars. Weekly schedules are posted there. If you're facing any technical issues, let us know in the Q&A section, which is on the right, third icon from the left, on the right top. It says question mark, ask your questions there while the session is going on. Now, I'm going to hand it over to Arjun Kher. The floor is yours. Thank you. Thank you very much. Before I actually go to the demos, I'd like to set some context on the improvements that we've brought as part of the changes that we've been doing. One of these changes is already released and a couple more changes are due to be released by the end of this week on 18th of May. I'll get started with the first change that we've been working on. Now, this is with respect to a feature that was not available on the schedule tasks page, and that is the ability to actually enable or disable a schedule task in bulk at a task level, at a task instance level, or an individual endpoint level. Now, just going back a few months, around 20th of October, 2025, we had a big AWS outage. As a result of that outage, all the recurring tasks that were set up in automation got disabled. Now, as a result of this, partners reached out to us so that they could re-enable these tasks. We didn't really have a mechanism present that where they could easily go back and enable them. You could do it from the recent tasks panel, but a lot of partners had tasks set up in local time zones, which meant that the tasks with the same names would appear multiple times on the recent panel, and it became very difficult to identify and enable them back. So we got this done from the backend for all our partners, but at the same time, we immediately understood the need to address this, as well as to give more flexibility in terms of controlling the tasks at various levels. So I'll get into the demo, but that's the first part that I'll talk about. The second part I'll talk about is improved statuses for trigger tasks. We received a lot of feedback with respect to when trigger tasks actually matured for them to get started. The status that was available on the screen was not very accurate or was a little confusing, so partners came back asking questions on what do these execution statuses mean. So we've ensured that we accurately now represent these trigger statuses based on where they are in their lifecycle. If a trigger is active or if a trigger is expired, what it means. All of this information will now be available across the pages as well. And the third one, which is actually a very big item, which is enabling next-generation check-in for recurrent or run-later tasks. Now, we actually have data on how many recurrent tasks are set up across all our partners in ConnectWise today, and that number is pretty large. And in terms of recurrence as well, I'm talking about hourly recurrence. Close to 90% of all our tasks are set up as recurrent hourly tasks. Now, as I understand, this could be for multiple reasons, but the most important reason is to ensure that that task successfully runs on the endpoint. So if the endpoint was offline, we understand that you want to make sure that whenever the endpoint checks in during that day, that task immediately runs. So there are multiple occurrences to compensate for these failures. Now, with this change, you no longer need to do that, no longer need to have hourly recurrences unless they're absolutely necessary. And I'll talk about that at the end as well. Quickly, on the same slide, with respect to upcoming releases, like I mentioned, Enable and Disable is coming up later this week or by the end of this week. We're also working on file sharing, which has been a huge ask from all our partners. So this will go into early access by mid of June. And we're also working on script isolation, which is to make sure that we can enable automated partners to smoothly transition into ConnectWise RMM. And at the same time, make sure we have parity with a lot of features that are present in the automation system. All right. So I'm going to move on to the first one, which is adding the capability to enable and disable tasks at our task level, task instance level, and endpoint level. So right now, if you focus on the third task, I've created a recurring schedule for retrieve memory and CPU usage for process. And I'm just going to jump inside that schedule. If you see the schedule has been created starting today, and it's supposed to run every day through 15.5, so for a couple of days. Now, if I go back to, if I go into the history, what you'll see is one such occurrence of that schedule has already happened because I had scheduled that around 4.45 PM IST, and based on the time zone in which the machine work, there were multiple instances created. So that is already done. And the next schedule has also been created. The new additions that you see here, and I'm just going to click on one of these task instances here. The new additions that you see here are these three dots, which are going to let you enable and disable this particular task for all assigned devices. Now, as you can see, the enable is grayed out because this task instance is actually in the enabled state right now. I can disable this for all assigned devices. This is at a task instance level. So once I click on disable, and I hit submit, it's immediately going to take the request, fulfill it, and say that both these tasks have now been disabled. As you can also observe under the outcome of the task instance, the status changed to suspended. Now, this is very intentional because there could be many other statuses where you could have a postponed or a canceled. That may come up here based on the various activities that you are doing. So in order to account for that, we want to make sure that we have one common status which is suspended across the task instance. So as you can see, at the task instance level, I disabled both the devices, and I disabled the task for them. Now I'm going to go back and enable it for all assigned devices. And you can see that the task was enabled for both devices, and the status went into scheduled, and the outcome also went back to schedule. Now, going to the task, going to the endpoint level, I'm going to disable it at an endpoint level. So as you can see, the task was disabled successfully. You can also see that the outcome still remains scheduled because there is one, at least one endpoint on which this task is still scheduled, and that's why the outcome is going to be scheduled. If I disable this from here, which means I have disabled all the endpoints that are on that task instance, the status is going to go back to suspended, which means everything was suspended. Now I'm going to enable this once again. So I've now put this back into the enabled state, and again, similarly, for the next instance, you can do the same operations. Now, these were the operations or the controls that you saw at the task instance and at an endpoint level. If I go back to the scheduled tasks, which is actually at the task level, you will now see the same controls that are available here, which means you'll see disabled for all assigned devices. So if I say disable, it's going to be disabled for all assigned devices. And as you can see, the status went into suspended state. Once again, if I enable it, it's going to enable the entire schedule for all. All right. One other thing that I do want to call out is to be on the task and schedule tasks where you can see the status of all the tasks that are on the task. So if I click on the task, I can see all the tasks that are on the task. So if I click on the task, I can see all the tasks that are on the task. So if I click on the task and schedule tasks, which you see the actions more of like icons. Now we are moving to a standard menu, which means you'll see three dots. And we've also simplified this for you. Initially, we offered icons. So now it's going to be text, which is going to tell you what exact options you have. We had a pause button that was used to cancel next scheduled instance only. So we've made sure that we clearly call out what it does. We had a delete button that used to deactivate. So we removed the icons actually and made sure that we have the right verbiage that's available on this page. OK, so that was the first part where I spoke about enable and disable on the schedule tasks page. Now I'm going to go to the trigger part. I've actually already created. And let me just show you this. So I created a trigger task that's already created. And I ran it. The trigger was based on I'm sorry, I'm looking at the. So I've already created a trigger active demo task. What I did was I created a trigger for machine restart is required. And once I go to history, you will be able to see that there are certain changes in how this data is going to appear. Earlier, when a trigger event or when a task matured or was eligible for the trigger event, you would see that the outcome of the task went into running. And you would see the outcome as running. You would see the status as running for the entire duration of the trigger that you had defined. If you had not put any end date on the trigger, it would just be in the running state forever. Now, these statuses would not match what you would see on the other pages as well. So what we've done is as soon as the trigger matures or the time that you define and that time is crossed, you will see one task instance which says that the trigger is active. Now, if you scroll and if you click on any one of these rows, it's going to show you the same output which says that this is a representative entry. And because each trigger event creates its own execution entry. So what this means is if for this particular device, there would be an event that would occur after the trigger became active, which has happened. You would see a task instance, which is true today as well, where the task ran on that endpoint and you would actually get to see the output for that. So now, this is a very clean look where you understand that a trigger is active and any instance that occurs because of the event that triggers the task that you set up, you will start seeing instances coming up over here. Now, when it comes to triggers, again, these actions will not be available today. This is going to be something that's going to be incremental. But triggers are set up slightly differently than schedules. So at an endpoint level, this is not available today. But if you go outside, again, for triggers, you will be able to see that you have the ability to enable and disable. This is an expired. So you saw everything grayed out. But as you can see, there's another active 13-minute trigger active demo where you can disable the trigger for all assigned devices. So only at the endpoint level is where we will work on an incremental release where you'll be able to disable a trigger for a specific endpoint as well. Now, there's one other call out that I need to make here is when we had triggers, and if you chose an endpoint for the trigger, the system would create two instances. One was the instance that I just showed you. And the second was the instance where you decided to end it. That's no longer going to happen. You're just going to see this one instance. If the instance expires at the defined time, the same instance will change to trigger expire. And that's what I'm going to demo now. So now, if I go to now, this is a separate task, which was the trigger expire demo. If you see, this particular trigger has now expired. And this is a separate task, which we made sure that it expired. Again, it shows you that this is for the expired trigger and whatever occurrences appear because of the events will be seen in history. So during the time period for which this trigger was active, there was one occurrence that happened on this endpoint, and that occurrence was successful. So now, you no longer have to deal with two different instances where one instance was when the trigger activated, and the other instance was when the trigger was supposed to expire. Also, you see accurate outcomes with respect to trigger active and trigger expired. Now, the same data will also be reflected across the automation page. And if you see here, this also gives you a very clear idea of what's happening. So I've navigated to the same endpoint on which we had the trigger active and trigger expired demo processes created. If you can see that 13 may trigger active demo. So this is a trigger which is actually active. So it's the same word page or same lines that I showed on the schedule tasks page. And for the active, you had one instance that came up, and this was the data or the output for that. Similarly, for the expired demo, you have a trigger that has expired. And for the expired one, you also see an instance where the event occurred, and the task was run on that particular endpoint. So that was with respect to having more controls on execution and more granularity with respect to enabling and disabling. Now, the next part that I want to show is the ability to, and let me go here, is the ability to actually execute on NextAgent check-in. Let me just use the old devices picture. So as you're aware, ConnectWise recommends running all tasks at NextAgent check-in. And you also have an option when you are scheduling these tasks. You did not have this option on the recurrent tasks, and now this option has been made available. So one of the things that I do want to call out once again is if you have tasks or scripts that have been scheduled on an hourly basis, recurring basis, just to make sure that you can compensate for failures because devices are offline, I will request you to revisit these schedules and see if you can leverage the execute at NextAgent check-in functionality. At the same time, I can also tell you that we are reviewing the data that we have today with respect to recurring tasks and seeing if we can write a utility to get this move to a NextAgent check-in to ensure that we have better results with respect to passing rates. Now, on the Run menu as well, like I mentioned, and I understand that this is where this gets used a lot, you will see this option come up, execute at NextAgent check-in. Now, based on the selection and based on the unit or based on the recurrence, you'll be able to put hours or days over here. The same option will be available if you decide to schedule a task from the Tasks menu. As you can see here, execute at NextAgent check-in. And as you're aware, we are also working on the New Devices page, and this option has also been extended to the New Devices page, where you will see that the execute at NextAgent check-in is available for recurring tasks as well. All right, so those were the three key items that I really wanted to focus on today and talk to you about. I think I've covered what I wanted to cover as part of the demo today. Garima, should we open it up for questions? Yes, sure. I see Amit has been addressing some of the questions in the chat. Let's see. There is one question from Steven. He's asking, is there going to be an option to retry a task that has failed for multiple devices? Yeah, so I believe this request did come up some time back, and we were considering this. But at this point of time, we would like to see how this particular option helps to reduce the number of failures. Steven, we could always talk about the use case that you have and the problems that you are seeing. So yeah, we can definitely review this. I'm just trying to pull up three questions. There's another question from Simon. He's asking, what if we want to stop the task if it succeeded after next agent check-in? Yeah, I mean, on the Schedule Tasks page, you always have the option to de-schedule the task if it's successful. But if it's not successful, you can always On the Schedule Tasks page, you always have the option to deactivate the task or disable the task. So even if it did succeed, you can just go ahead and disable the task. I would recommend that you schedule it in such a way that you are not really worried about too many occurrences. But I do understand where you are going with this, where if a certain task has executed on an endpoint, then you do not want further schedules to run on that particular endpoint. That is also feedback that I have. But like I mentioned, we look at this incrementally in terms of which ones we can pick up. Thank you. I'm going to take the next one. It's from Colin. He is asking, can you clarify, please, if a device is offline at the time that a recurring schedule is due, that task will run when the device next comes online? Right, so that is the feature that I mentioned. And I'm just going through your question if it was offline. Right, so what's going to happen is, let's say that you scheduled a task at 8.50 PM my time. Let's say you scheduled a task to run on an endpoint at 9 PM IST. At 9 PM IST, and you said execute at next agent check-in. And you said, I'm willing to wait for this for the next one hour, which means until 10 PM. At 9 PM, the schedule matures, which means that at 9 PM, the task is supposed to run on your endpoint. But at 9 PM, the agent detects that the endpoint is offline. Today, on a recurring scenario, what happens is that particular task will fail on the endpoint, saying that the machine was offline. But if you choose execute at next agent check-in, what it will do is, with an expiry of one hour, what it will do is it will wait for another hour for the endpoint to come back online. If the endpoint comes back online in the next hour, let's say it comes back online at 9.30 PM, it will detect that the endpoint is online, and the task is still eligible to run on the endpoint, and it will run on the endpoint. What this means is a failed task that would have, or a failed occurrence of that task that would have happened at 9 PM was avoided, and the task successfully completed at 9.30 PM. To just extend this, because if you're worried about recurring hourly schedules, and that's why you're scheduling it, now you could just say that, if I need to run something once a day, I don't have to do it hourly. Run it on a daily basis, and wait for 23 hours, and it's just going to wait for the endpoint to come online, and you can basically avoid anywhere between 1 to 20 failures. I hope that helps. Great. There's another question from Mike. He's asking, what is the difference between deactivate and disable? Does deactivate basically delete the task and prevent it from being re-enabled without scheduling a new instance of the task? That is accurate. So once you deactivate the task, you're done with the task. You can no longer take any further action on it. It's basically purely deactivated. It does stay on the scheduled tasks page for 30 days after you've deactivated it, and after that, it gets removed from the page. With respect to enable and disable, I think it's like I mentioned. If you disable a task, it stays disabled, but it's still in a state where you can put it back into enable state, and it will revive all the schedules that you have created. Great. There's another question from Mark. He's asking, I have a script to install a Huntress agent. I would like it to run automatically when a new agent is installed, or if the agent somehow gets uninstalled. I was considering making the next agent checking task, but I'm worried that this will be too much activity. What do you recommend? So I believe if you look through the triggers that we have, Mark, we have a trigger which says forced agent check-in or forced check-in. I believe you could leverage that particular trigger where when you install an agent and your endpoint forced check-in or the agent forced check-in with the endpoint, that is when the task can get triggered. So I'll recommend if you could use that. And I was just going to come to monitors as well, and Amit added that I believe the triggers were created at a point where the monitors for the same thing were not available, and that's why it's under triggers. But you can also use monitors instead of using automation tasks, and I believe that that would be a better way of doing it as well. Okay, very good. Do we have more? There's a follow-up from Simon. Just checking his last question. Yeah, so his last question was, what if we want to stop the task if it succeeded after next agent check-in? And then the new question is, yes, but what if... So Amit answered it as you can cancel it anytime. And his follow-up question is, but what if I need to run a script on multiple computers throughout the company? I don't want to disable the task itself because I want it to run on other computers, but I don't want it to run again on those computers that succeeded. That's the goal. Got it, got it. So Simon, like I mentioned, I do understand this use case. This is a feedback that we have received earlier as well, and we work on this incrementally. I do fully understand. Like once it runs on the endpoint, you're done for the endpoint, but you still need the task to be alive to run on the other endpoints. Yeah, we have one. Yeah, I see we have like addressed all the questions that were in the chat. Maybe we have like last a minute or so. If you still have any questions, please ask. Okay, maybe Ajankit, do you want to like summarize it in like last 30 seconds or 40 seconds that we have? Okay, sure. So like I mentioned, we've given more control in terms of enabling and disabling tasks at various levels, which is the task level, the task instance level, as well as the endpoint level. And we've also improved the status, the trigger statuses that you'll start seeing in the system today. Once again, I would like to reiterate to go back and look at the next stage and check in for recurrent and run data tasks. I believe that's going to save you a lot of time and also save you a lot of failures that might happen because endpoints were offline. And at the same point, I do want to acknowledge the feedback and thank you for sharing that. That is something that we have been receiving. And like I mentioned, we want to make sure that we prove the quality of life for partners by making sure that they get what they're essentially looking for. So that's a feedback that I'm going to take back from the session. So that's it. Thank you, Arjun, for that. I also want to call out, there were a lot of positive feedback in the chat. I didn't read all of those because I was focusing on questions, but great job, thank you. We can move on to the next slide. So on the screen, you are seeing a QR code for our ConnectWise YouTube channel. This is a great place you can catch replays or deep dive into other content. Although Wednesday sessions are uploaded here, so I'll pause for like five seconds there so that you can scan this QR and subscribe to it. Make sure you have your phone handy and you can scan the QRs. There are a couple of them coming on the slides now. Okay, thank you. So next up, this is how our schedule looks. So we covered today RMM theme session. Next, we have CPQ. Then again, RMM on 27th and 3rd June PSA. These are some details on topics in description. On the next slide, you would get a QR for our immediate next session, which is focused on CPQ. The topic is multi-level approval enhancements for better approval continuity. This is the QR code for registering for that session. In general, if you're wondering what's coming up next in the sessions, you can always find our schedule topics on university calendars or look for in-app notifications directly on the platform. Okay, moving on to the next slide. So we also have a university day coming on, university day by Connectwise coming on June 2nd till 5th. If you want to attend, this is gonna be a great session by our education team. You can scan the QR codes to register for this session as well. And that would be it. Thank you all for joining us today and for your great questions. Thanks Amit and Arjun. And also we look forward to seeing you next week on Wednesday. Have a nice day. Thank you.
