Turning Hudu's useless expiration alerts into fully linked HaloPSA tickets

Well, if I know you, and I think I do, you want to find out how to turn your Hudu expiration alerts from something like this to this. Let me show you.

So I'm pretty sure you've looked at expiration alerts in Hudu before. And without much investigation, let's be honest, you quickly find out not really going to get anything that I want to display to my customers or really that's going to be useful to my team from the built-in alerts as they are. Like, if I go to new alert here, obviously so fancy, the only option I get is an email address. So that's fine. I can send this to an email address with whatever Hudu have decided is relevant to me, which again will say this screenshot. You're not really getting what you want. It's going to tell you in this case warranty 30 days and I'm going to get like a bit of a GUID that I don't know what that relates to and how am I meant to tell my ticketing system what that relates to. There's all these sort of unknowns. I've fixed them. I've got a runbook that sort of does what we're looking for and I'm going to show you how it works and what it's doing. And if you fancy, you could build it yourself. Otherwise, you could speak to us and potentially I could try and do it for you. But that's a question for another day.

This alert here does have the option for a configurable webhook. Obviously, using a webhook URL and a webhook payload. So I've already preconfigured that and I've set it to alert for all expirations using the single expiration. So this time instead of getting a list for a customer or something, I'm getting a new ticket, new alert for each expiration that exists or comes from Hudu using these variables here. I'm pulling the company name, record name, trigger days, and Hudu URL as part of the JSON. So I'll just show you what that is quickly. If I go in here, I can pull the webhook payload down here, and you'll see this is what I'm using. It's pretty straightforward. I'm just using exactly as they are down here, piped into a JSON format. So that's what I'm going to receive. These dollar variables will be updated by Hudu and then when the payload is sent to my Halo webhook URL in this case, it's going to contain the information related to the single expiration I have selected here.

And another big important thing for this is obviously in this case I'm setting it for 30 days. You could have multiple of these where you set it for different periods. I haven't built in anything in my runbook to merge tickets or do anything with a set amount of days, but in theory that could be improved on. So in this case, I'm stopping alerts after reaching the trigger. It's triggering once at 30 days. It's sent in the alert and I've got a ticket 30 days out in advance.

So if we swap out of Hudu and we go into Halo where I've built this out, there's a runbook here which is using a few different methods and it looks quite large and daunting, but these three paths here are effectively just using different endpoints due to the fact that the Hudu API doesn't necessarily work well with separate asset types or layouts or entities. So I have to use different endpoints for each. I'm just going to edit this quickly and get rid of that because I don't know where that came from.

So first thing I'm doing is I'm doing a post to the SQL database for our Halo instance to trim a URL. I can't remember exactly what it is. It's a full report to trim the Hudu expiration alerts HA URL that's received from the payload. So in this case, if I check my log and the last one's going to be the Connor or Robbie, I think it is. Yeah, Connor admin. So this is the payload I received. It's the Renada Hudu cloud Connor admin account there.

So what I'm doing with this is the slash A tells me that it is an asset. So if I go back now to my flowchart and I open this again, we're effectively checking if there's slash A slash is an asset, slash website is a website, slash KBA is a KBA which is a knowledge base article and then I'm doing a bit of a trim after that effectively. You saw that it was Connor-admin and a bunch of numbers. That's the slug. So I'm then pulling the slug and the expiration type out as part of this.

I can then get the company detail from Hudu using the company name, which was another part of it. And then I can output the Halo ID cause that'll be linked as a synced integration. So that's another thing you're going to want to have. You're going to want to have those companies synced from Halo to your Hudu. And I can pull the Hudu company slug and ID as well, which are used a bit further along. We're getting the general user ID for the Halo company. So using the Halo ID from this method from Hudu like again query Halo database with that company ID to get the general users ID.

And then based on this initial trim, we've done some additional things to get it in the chain which we need further down. We're now checking if the initial trim URL is an asset, a website or an article. So obviously if it is an asset it's hitting this path here. If it's not it moves to website. If it's not a website or an asset it moves to article. And then in each of these stages they're basically the same thing. I'm doing a GET for the detail of the asset, the website or the article. Then using that information I am then finding the expiration of the asset, the website or the article. And then I'm creating a ticket off of the back of the information that I've obtained from these two things which is giving me the final output in this case of Connor's admin as the asset name.

The object type is obviously an asset. It's an asset field expiration type. So the field is called Connor admin and that is what's expiring. So it's not necessarily the asset itself. It's the field of Connor admin and an ID of the asset and then as well a direct link which effectively is just an HTML formatted href to the link that I've received in the payload. And then there we have it. That's the linked Hudu entity. And the documentation URL, it's all there. It's a lot more useful for your team. It's a lot more useful for your clients to see this.

And additionally, you'll notice in the screenshot again, I'll get it put it up. It doesn't link to the right customer. Um, to be fair, you're not going to see that in the screenshot, but you don't have any information or relevant pointers or even a sniff of who that's related to, whereas this one is specifically finding the information and it's attaching it to the correct client as well. So, even when it gets logged, you know exactly who it's for. You know what it relates to. You've got a link to it. You got the ID for it and it's on the correct customer. So it's a really good thing. Um, it's a shame that it has to go sort of through a whole process, but obviously it's going to save you a lot of time trying to figure out where and what this is related to.

Hopefully, Hudu can add a bit more API changes in the future that let us get this information initially or update the actual payloads directly with a bit more information, maybe some more variables. There's a few different things that we could do. It would be really really helpful. But, as it is, this is a really cool workaround. Let me know what you think. Um, if you've got any questions, anything you think should be added. Obviously, like I mentioned, you could do additional alerts and potentially merge that into the same ticket. If it's maybe closed, it would reopen it kind of thing. Not something I've implemented right now. And I'm curious what other things you guys have. Any other ideas? Any other problems you want to try and solve with alerts? Let me know down in the comments. See you next time.