How We Worklet: Automate User Notifications

Ever feel like your users are experiencing notification fatigue? If so, this Worklet shakes up how you notify your end users to make sure your messages are actually received and read. The best part? It cuts a task that often takes more than 30 hours down to just 5 minutes – with better outcomes for everyone.

In this video, Jessica shares the inspiration behind the User Notification Worklet and the different use cases it can be applied to. We have a hunch you may find your own use for it!

Video Transcript:

[Hey everyone. My name is Jessica Onorati and I am the Lead of Organizational Security here at Automox and I am absolutely ecstatic uh to roll out a brand new internal initiative that we have prepared for you called: How We Worklet.

Uh We'll get into a little bit more what that is in just a second. This particular episode in the ongoing series will be about a macOS Notification Worklet. But since this is the first in the series we want to give you a quick outline of what the How We Worklet initiative is all about.

So here at Automox we strive to bring unique content and value to our customers. And we also use our product internally to firstly secure and manage our corporate assets and secondly improve our products through early access to releases and via internal testing.

So when we asked how can our internal IT and security team provide direct value to our customers, the answer was obvious: Let's provide our customers with the unique solutions and use cases that we have used at Automox internally. From this series you can expect to get a glimpse into how we're using our own product internally.

So what you can expect is uh creative ways to use the product beyond patching business and test cases, new Worklets added to the console catalog, blog content, video how-tos, and a lot more.

So what's a Worklet? Um if you're unfamiliar with Automox or maybe you're a new customer, Automox Worklets are super helpful automation tools that hand over the reins so that you can automate any scriptable action on macOS, Linux, and Windows devices. If you're a customer and you're not using Worklets you're missing out on limitless potential.

The best thing about Worklets is you can reliably script any manual task and eliminate it from your regular routine. Anyone can create and offer up a Worklet in our online community. Um but we internally offer expertly crafted Worklets with the platform.

But just as often it's our customers who have a great idea that comes to life um in a Worklet form. We dubbed these users internally as SuperUsers and they're the ones that are providing uh really helpful content um peer-to-peer within our online community.

So within this overall How We Worklet initiative we have some sub-content called uh Winning Worklets. And so you're probably wondering at this point what's a Winning Worklet?

Well, uh, Winning Worklets are the ones that we, the internal security and IT teams at Automox developed for ourselves and found particularly useful or interesting. These are Worklets that we run regularly internally, that bring us value that we want to pass on to you. And so, without further ado, let's talk about our first Winning Worklet.

So the Winning Worklet this month is macOS Notifier. The problem is something that you're probably very familiar with. Um So here's the pitch: Have you ever socialized an upcoming change share endpoints repeatedly only to have users on the day of the change claim say they didn't know what was happening today? Well, us too.

Recently, we rolled out a brand new SaaS platform internally that we knew was going to be pretty disruptive to our internal users because it impacted the way that they interacted with their tools every day.

So with that in mind we did what we felt was our best to communicate this change. We communicated it repeatedly in multiple different forums via Slack announcements in our general channels and to managers. We did a monthly newsletter where we mentioned it eight times, so eight months in a row. Um, we had emails that went out to the entire company, we had an Ask Me Anything that went out to the entire company where we did an FAQ as well as answered everyone's questions. Um, and we had Confluence stocks out there ready to be referenced by any of our users with FAQ as well as the project rollout schedule.

But despite this, we still had these issues on the day of - users claimed that they didn't know that this was happening.

So we thought to ourselves, how can we improve this? How can we make sure when critical system changes are happening that our users are aware? So after thinking about it, we thought what if we prompted our users with a native OS notifier when a critical change is happening. We thought certainly if there's a critical change and a pop-up appears on a user's desktop that they couldn't miss it. They couldn't possibly miss it. They would definitely be aware of any really important changes or notices that the needed to know.

So with that said, now that you kind of understand the intro of the Worklet that we're gonna be looking at today, as well as what this initiative is all about, let's get right into the tech content here and show you a quick demo of what this macOS notifier looks like in practice. This is a page that a lot of our customers are probably undoubtedly familiar with.

This is the Automox home dashboard. From here we can go to our manage tab and then the Worklet Catalog.

Within the Worklet Catalog, what you're gonna find is all of the Worklets that the internal engineers at Automox have developed specifically for our customers. And these are all the ones that are tested, tried and true, ready to go. So unlike the ones in the community where they are community provided peer-to-peer, customer-to-customer, these ones are the ones that we have tailored specifically for our customers internally.

Once we're in here we're gonna go ahead and go to our macOS notifier. So this is a very easy uh, pretty simple Worklet that I found was really helpful during this fast roll out that I was just explaining. The evaluation code, simple exit one. But you can really do anything you want here. And when we rolled it out to our internal customers for the SaaS rollout, what we did was an evaluation script based off of the date um where the date was the enforcement date for the SaaS product and then we notified our customers every day for seven days leading up to that date. So as long as the date was before then it would go ahead and notify the customer. And then our remediation code:
This is the actual meat and potatoes of our Worklet. This is what's actually going to complete an action on the end user's workstation.

So here we've got uh, in the simplest form of this Worklet, your title text, um the summary of what you want to tell your user, and then the message text. So the bulk of the message that you actually want to let them know about. So we'll go ahead and start by creating this policy.

So we create a policy and we'll call it How We Worklet: Winning Worklet One. Like I said this is going to be an ongoing series, so there will be additional Worklets followed on with content monthly. Um, but enough about that.

We're going to associate it with a test group. This is when I pre-populated early that just has my workstation on it. So I'm going to go ahead and associate it and then we have our remediation code. So this is where we're gonna go ahead and set up that title and message that we want our user to see.

Okay, so for this example let's say that we are rolling out some kind of critical software. So for our title we'll go ahead and say Critical Software Install.

And then for our message, let's say you are getting software XYZ installed today. Save your work and prepare for a reboot. Okay, so again, this is the simplest version of the Worklet. Uh, this will just pop up a simple message showing you this text.

We'll go ahead and set a schedule for this. You do not have to do this for this Worklet. I'm just going to do it for simplicity because we're gonna run it multiple times. And I want to save. You guys have trouble seeing the pop-up about scheduling. You can also add something here that if a device misses a configured patch time that it will patch the next time the device checks in. So for instance, let's say we're running it at 12 am like we have it set here. Um, if the machine is offline when the user logs in for the next workday, let's say at like 10 am, they'll go ahead and get this automatically when their device checks in. And then down here we do not need a reboot here. So this isn't actually making a change on the machine, it's just uh running a script in the background to create a pop-up for the users so we do not need to reboot. So we should make sure that this is not enabled. Then we're gonna go ahead and create our policy.

So if I look for our policy now I can see this one that we just created. I'm gonna go ahead and run that policy. And voila, just like that, we get our notification about our critical software install. Again, this is the most basic version of it, so this is all you really need to do if you just want a simple Worklet.

Um I did though add some additional variables in there um for your use if you are so inclined. Some of the things we added was configurable buttons. Um so the default is okay but you can add one or multiple buttons if you wanted to prompt users in a different way.

So the button text could really be anything that you want. Um We're gonna go ahead and add a button text here just so that you guys can kind of see what that would look like if we change their button. You can add multiple buttons if you want there to be actions later on and I will go into that in a little bit later. But for just for now, just so you can kind of see how it works, let's go ahead and configure a button.

So the title text and message text doesn't change, but we're gonna go ahead and grab this button text as well as the rest of this and then we're gonna add that here. We're going to replace the OSA script as it was before and the exit message. So we're just going to paste over the top of that our button text. Let's just say for our example here that we want to call this uh, "cool button," just so you guys can see what it looks like. Again, the default is always going to be “okay.” So you do not have to configure this. But if you wanted to say something else like um "exit" or "learn more" or something like that, this is where you configure it. So we'll go ahead and save that. We'll go back into our
policy, How We Worklet. And then we'll go ahead and run that again. So there you are, we get our exact same message, but now, instead of saying okay, our button says "cool button." So, you know, nothing too fancy but a little bit of extra configurable value for you if you wanted to do a couple of things.

What I would expect to see users use this for is if they're doing multiple button options like "okay" or "exit" or "get me out of here" or "learn more" or "help," maybe for a help desk or something like that. The default is okay which is perfectly fine, if you don't need additional information, if it's just informational. Um but if you want multiple actions, you're definitely gonna want to configure probably more than one button. You're probably gonna want that button text to be configured.

Okay. So like I was saying you can add um button actions, we won't be doing this in the demo but just so that you know, you can add default button actions here, um which would indicate which button is the default return and then which one might be like a canceled action. Um This is not mandatory for multiple buttons. You can have multiple buttons without default actions but this is configurable here. You can also
set the type of alert. This is another one we're not going to be going over in the demo, but just so you know what it is, uh the alert type is essentially going to just configure the kind of icon that you see in the pop-up in the macOS notifier. So your options here are critical, warning, or informational.

If you plan to use this Worklet, definitely play around with these to see which one visually looks the best for you.

Another one that I've added in here, we're not going to go over in the demo again, is a timeout feature. So by default the pop up will appear and it will not disappear until a user interacts with it by clicking a button but you can add a timeout. The timeout is an integer measured in seconds. So if you want that notification to disappear after, let's say 30 seconds, you just use this section here with the dialogue time-out and go ahead and add 30 seconds here. So it'd just be 30.

Alright and this is the feature that probably took me the longest to add and figure out which is a redirect to URL. What this redirect to URL does is when you click a button you can define a button's action to actually open up a web page.

So you can configure here to open up the URL in Safari based off of the button's return. So in this instance if the button named "returned" is okay then you can go ahead and um configure a URL to be opened up in Safari. I went above and beyond here um and added a default browser. The Safari one is fine if you're going somewhere publicly facing. For my internal use I wanted if you pressed "learn more" for it to take the user to a FAQ page and if you pressed help, I wanted it to take the user to our internal help desk. Now both of those are behind authentication, internal to Automox.

So if I just use Safari if their default browser didn't happen to be Safari then they would have to re-authenticate, which kind of defeated the purpose in my mind of having an easy pop-up that's going to take them exactly where they need to be. So what I did was wrote an additional topper on top of this default URL. I added this default browser so now you can configure your button to open a URL in the user's default browser which would again maintain any authentication or session so that they wouldn't have to re-authenticate necessarily to use it. So this is the one that we're going to go ahead and show in our demo here.

There is a little bit of a gotcha here with this Worklet and I just want to point it out so that no one makes this mistake. So what you'll see here is the button name is named "okay." So that is the default button um of the script. So like I said the default is always going to be "okay." So this is assuming that you do not have um custom text. So just keep that in mind that this is assuming that you do not have a custom button. Each of these are meant to work independently.
So in order to build them into each other, you're gonna have to do um a little bit of building on top of each other. I'll show you how to do that in this instance here um and show you kind of what I'm talking about with this example. So what I'm gonna do is I'm gonna pull this URL and button name here. Alright, so for our URL we're going to call it Automox.com. And for our button name remember button name is assuming that you are using the default but we are not, we're using a button text called "cool button."

If we want our action to be based off of "cool button," we're gonna want to edit that here. Um and then I didn't pull up this from the bottom. Before, what this line looked like was just the OSA script here, right? Um and then the reason why I didn't copy and paste it is again, these are meant to be independent modules that build on each other. So the one down here, just so you can see, it does not have that button text here because again, it is assuming that you're using the default button name of "okay."

So we want to make sure that we are including that button here, just at the end, uh so that we're getting all of the functionality that we added before with the button text being a dynamic thing that we are actually custom reconfiguring and then the dialogue output. That's pretty much the difficult part of it.

So we're going to go ahead and grab the rest of it here. And what we're gonna do is we're just going to throw that onto the end of this script that we have already configured here. Uh, so we're gonna just uncomment all of this stuff, you can either do this within the uh Automox console itself or if you have an um IBE of choice, you can go ahead and edit it there, uncomment it there. That can be a little bit easier because it has short keys. Additionally, you'll be able to make sure that you don't make any mistakes uh with indentations or spaces etcetera. So I mean that would actually be the ideal way to do it but I just want to do it all in the console so that you guys can kind of see what I'm doing and I'm not bouncing around.

Okay. So this section that I just uncommented… Uh, one is actually getting our logged-in user's user name. And then the second function is actually going out to Apple.com in order to determine what browser this user is actually using. Then this line is actually echoing out what this function returns. So the complex name of the default browser. And then this line is changing the browser name into something that's readable - just the application name - so that later on we can go ahead and call that application name. So if our dialogue output, which again is this dialogue output OSA script, our display alert with our title text, our message text, and our custom buttons. So if that dialogue output returns, this button returned button name, this is the one we returned here again by default. This will be "okay." And if it's anything custom you need to go ahead and edit that to your custom button name, then it'll open the browser name that was returned by the previous script and then open the URL that you have configured here. So in this case it's Automox.com. So if that button is returned it'll exit otherwise it'll exit. Um This might seem a little bit redundant.

Um The reason why it's configured this way uh is it doesn't always have to be just one button. Um In several cases actually in the most typical of this case there will be multiple buttons in play like an "okay" or a "cancel" or an "okay" or "tell me more" or something to that effect.

So now that we've edited our Worklet, we have all of our cool new stuff in here. We have our title, our message, our custom button name as well as the URL that we want the user to be redirected to, you can go ahead and save this policy. We'll go back in and find How We Worklet. And then we'll go ahead and run this policy.

Alright. And there you have it. It's exactly the same as before, "Critical Software Install" with our message, "cool button." But now when we click "cool button," we get a pop-up of Automox.com. Uh This can be any uh URL that you like. It could be any publicly or internally facing websites, so long as the user has access to it.

Again, you would want to use a default browser if you want the most clean experience for your end users because that's going to go ahead and pull up the URL in their browser of choice. But it's pretty simple. And this is going to give our user an idea of something that might be something really important that they need to know about um something either happening to their system or maybe just like a general announcement. And then you have the option of bringing them to uh an external URL to pass on additional information that doesn't fit in the notification.

Okay. So that concludes the content for this month's Winning Worklet: The macOS Notifier. If you're interested in utilizing this Worklet, you can go to our blog for additional information. There's some written-out information about the business case on why we wrote this and how we're using it internally.

And you can also just check out this Worklet in your console um if you want to play around with it and see how it works or if you're just interested in it and you think that this is something that you could use. Thanks for checking in with us and we hope to see you again next month for next month's Winning Worklet. Have a good one.]