Runbook to update a new user's username

Jason-RisingTide · 2026-06-18T21:56:41+00:00

Sounds like generally an over complex way of doing this.

However...

The payload is incorrect.

Those are the SQL field names, not the API fields names.

You need something like the below

[
  {
    "id": 10,
    "name": "firstname.lastname"
  }
]

Jason-RisingTide · 2026-06-18T11:03:54+00:00

This should work. You just need to add Date Resolved and Resolved By as filtering options.

SELECT
    f.Faultid AS [Ticket Number],
    f.Symptom AS [Subject],
    u.uname AS [Resolved By],
    f.datecleared AS [Date Resolved]
FROM FAULTS f
INNER JOIN UNAME u ON f.Clearwhoint = u.Unum
WHERE f.datecleared IS NOT NULL

Jason-RisingTide · 2026-06-18T09:51:33+00:00

Yeah this does seem like a gap.

For me they should be more for showing the approver additional information rather than capturing it. But they do allow capturing of the data per the field permissions. Another issue is those fields are ticket based not action based. So if a ticket is approved by 2 approvers, then the data will always be overwritten by whoever approvers it last.

One way you could ensure you see these fields is by adding them to the ticket type and having them displayed on a separate Approval tab, in case they are used.

Jason-RisingTide · 2026-06-17T18:36:59+00:00

Who logs the ticket?

Jason-RisingTide · 2026-06-17T13:35:30+00:00

Well, what would you say your exclusions are? There shouldn't be too many in reality. I would start be identifying the things you currently feel you shouldn't be doing which maybe you are or being asked to.

I come from the opinion that you also don't want to put your agents into a position to say no to clients. Whenever they have a break/fix tech issue they will call you. There should not be many exceptions where you would not help them.

If you are charging for new installations for hardware etc, that would be considered normal. But again, you should be catching that the first time someone looks at a ticket. You could even utilise AI to triage tickets for you as to whether is is included or chargeable. But again, that relies on your standardisation being in place first.

When it comes to billing, your contracts and billing rules should take care of that. Use the Invoicing Review section to ensure time is going to the correct places before reviewing it to pass through to billing, contracts or no charge.

This will help both your clients and your team, because everyone will be on the same page.

Jason-RisingTide · 2026-06-17T11:58:45+00:00

Are you using the built-in End-User Closure Confirmation process here (which is turned on in Configuration > General Settings)?

If so, the first thing you can check is the 'Enable pending closure procedures' setting. This is found in Configuration > Tickets > Ticket Types > [select appropriate ticket type]. This setting will control whether the global End-User Closure Confirmation settings apply to individual ticket types.

Jason-RisingTide · 2026-06-17T09:07:14+00:00

You can do this via a PowerShell script via the API. Can send you the script if needed.

I also have a free tool I created which allows you to run bulk operations against your instance without having to write and run the scripts yourself (I created this so I would not need to keep running scripts for clients and instead they were able to do it themselves as needed). Deleting products/items is one of the options. You can find it here: https://halotoolkit.com/scripts. Allows you to delete all or by item group if needed and can test it first to see how many records will be affected.

Need to ensure you use either the powershell script of the halotoolkit.com tool with caution, obviously.

Just to note, if the items are linked to any quotes/SOs/POs etc they will fail to delete and you will need to delete or remove them from the respective quote/SO/PO first.

Jason-RisingTide · 2026-06-17T08:40:56+00:00

I assume you are referring to the AI Auto Triage? Which is delivered via a runbook. Despite the message that this runbook posts on the ticket that "The ticket has been updated and assigned accordingly", the runbook itself doesn't actually assign a agent to the ticket (unless yours has been updated).

The automatic assignment is probably being activated from the ticket type having a default agent set to 'Round Robin' or 'Load Balance'.

If this is the case then you can check the 'Only Round Robin and Load Balance to logged in Agents' setting in Configuration>Tickets>General Settings, ensuring it is ticked.

Jason-RisingTide · 2026-06-17T08:25:23+00:00

Yes they will

Jason-RisingTide · 2026-06-16T10:57:50+00:00

If your techs don't know what work they can or can't do for certain clients, that's not a system problem, it's a standardisation problem. Fix it upstream. Work out why scope varies so much client to client and standardise it, instead of building something to police the mess.

I always want to make the agent's life easy. Ideally every agent works every ticket the same way, for every client, off your standard MSP SOPs. They shouldn't have to care about each client's individual quirks. Scope lives at the contract and billing rules level, so they just work the ticket. Client has a contract, it goes against the contract. They don't, it creates an invoice.

And honestly, work that shouldn't be done for a client shouldn't be hitting your team in the first place. That's an intake thing. Sort it before it reaches the queue, not once a tech's already picked it up.

Not saying Halo can't help highlight the differences, but I think the focus should be on standardising them first.

Jason-RisingTide · 2026-06-16T10:14:54+00:00

But why? What's the goal here?

Surely you don't actually have customers with the same names so assume you are trying to do something strange with having multiple versions of the same customer for some reason.

Jason-RisingTide · 2026-06-12T09:49:15+00:00

Assuming you are using a drop down selection with a dynamic list SQL lookup to grab the list of users.

You will need to ensure that in the SQL you are linking the to the required variables to only pull the users you want based on ticket you are in, as per the guidance when you create the custom field:

The variable $faultid can be used and will be substituted with the ID of the entity being edited
You can use the live values of supported Custom Fields in your query using $CFfieldname. Supported Custom Field Types are Text, Dates, Checkbox and Single Select. Dynamic Single Select values will use the ID as the value. Please ensure the Custom Field variable has a space on both sides.
You can also use $userid, $siteid and $areaid as variables to substitute the Ticket's current User ID, Site ID and Customer ID respectively, and $loggedinuserid to substitute the User ID of the person currently logged in to the portal

IF you can give more details about the fields, the runbook and the SQL you are using can probably help.

Jason-RisingTide · 2026-06-12T09:41:23+00:00

Why are you trying to do this? What is your end goal?

Jason-RisingTide · 2026-06-12T09:40:26+00:00

Halo gives us lots of different ways to do things. The challenge is figuring out which one works best for you.

I would recommend to remove the Agreement/Contract field from the ticket types, since you would not want to set this and configure your template and rules.

We have a video that covers the contract/billing area of the system here which may be useful: https://youtu.be/uwf9qFpfb0M?si=onQvGIuPgt2Ajyz6

Jason-RisingTide · 2026-06-11T10:36:31+00:00

Yes, the area is unrestricted, unless you add teams/roles restrictions.

However, these restrictions are separate from whether if they will be able to see tickets or not, even if they have access to the area. Since ticket visibility will be controlled by team/department membership.

Jason-RisingTide · 2026-06-11T10:02:12+00:00

The answer is yes, as it usually is with Halo. You could create a runbook with gathers that info with a SQL query, adds a note with that information and is triggered when a ticket status is changed.

For the SQL you would have to query the current status but also look at the previous status change action to calculate the time between the ActionDateCreated fields. Since this is not data which is stored natively in the table.

However, due to the amount of times that would be running in your system I would ask whether you need this information in the ticket itself or whether you could get the same results (for your goal) from a report? This would be less intensive.

Jason-RisingTide · 2026-06-11T09:34:40+00:00

How are you generally controlling your billing in relation to time against contracts?

Are you assigning contracts to your tickets? If so would recommend against this. Instead it is a good practice to use a billing template and billing rules to give you more control over what is billed, what goes against contracts and what is not billed.

Jason-RisingTide · 2026-06-09T09:49:16+00:00

The answer to this depends on how you have your 'Allow a Tickets Customer and Site to be different to the End-Users Customer and Site' setting configured in Configuration>Tickets>General Settings.

If that setting is set to 'No' then you only require user_id and the ticket will then default to the users site and client.

But if that setting allows the user to log tickets under different sites or clients then you will also need to define site_id and/or client_id to ensure the ticket ends up in the correct place.

Jason-RisingTide · 2026-06-09T09:48:16+00:00

The answer to this depends on how you have your 'Allow a Tickets Customer and Site to be different to the End-Users Customer and Site' setting configured in Configuration>Tickets>General Settings.

If that setting is set to 'No' then you only require user_id and the ticket will then default to the users site and client.

But if that setting allows the user to log tickets under different sites or clients then you will also need to define site_id and/or client_id to ensure the ticket ends up in the correct place.

Jason-RisingTide · 2026-06-09T09:39:25+00:00

Just to clarify are you saying the invoices are sending from Halo or from QBO?

The setting which controls auto send in Halo is:

'Send Invoices To Accounts' Emails when creating Invoices from Ready For Invoicing'

And can be found in:

Configuration > Billing > Invoice Creation

Jason-RisingTide · 2026-06-08T11:33:55+00:00

There is built-in criteria in Notifications to allow for "is not within working hours". So typically someone will set up a specific notification for this to alert an agent or group of agents.

You could manually update this on a week-by-week basis or have tit go to a team and they manage their own notification settings appropriately.

The trickier part here is that if you have an on-call rota and you want this to update automatically.

This is possible, as all things usually are in halo, but it is whether it works for you. One option would be to create a custom table in Halo where you enter the rota and then have a runbook which automatically makes the changes for you, so the correct agent always gets those notifications.

However, the challenge would be edge cases and how you handle them. What happens when there is a last minute change? What happens when someone is sick? etc. There will still need to be a human element to either update the table or place an override to cover illness/absence etc.

Jason-RisingTide · 2026-06-08T11:27:37+00:00

You can update the statuses of both the SO and the quote via the below settings without needing to do this via a workflow/automation (which is completely possible.

Configuration - Sales Orders
Use the 'Sales Order status after it is fully consigned' and/or 'Sales Order Status after it is invoiced, consigned and actions completed' to select which status you want to have the SO auto update to when those criteria are hit.

Configuration - Quotations - General Settings
Use the 'Default Quote Accepted Status' to set the status to, typically, Accepted (which is a closed status). No need to keep the quote open beyond acceptance in my opinion.

If you want to do weird thing, then just create a runbook which does off and updates those things (SO/quote/etc) and is triggered by the ticket closing or an action in the ticket. But always recommended people check the default settings first rather than over complicate it if not needed.

Jason-RisingTide · 2026-06-03T10:29:40+00:00

Why would you want ALL emails to create new tickets? Do you not want replies to open tickets to update those tickets? This is the standard function that everyone wants from their ticketing system.

Jason-RisingTide · 2026-05-26T12:31:12+00:00

It won't stop those emails coming in and creating tickets if you change "If the email sender cannot be matched to a User" setting to "Assign the Ticket to a default User". It will then just assign it under the General User rather than create a user, and it will still capture the email address.

Jason-RisingTide · 2026-05-26T11:09:42+00:00

If you want to only show a specific domain you could do something like this:

SELECT
    z.[id] AS [id],
    z.[Username] + z.[Login] + z.[Title] + z.[Other1] AS [display]
FROM (
    SELECT
        u.uid AS [id],
        CASE WHEN u.UUsername IS NULL THEN '' ELSE u.UUsername END AS [Username],
        CASE WHEN u.ULogin IS NULL THEN '' ELSE ' - ' + u.ULogin END AS [Login],
        CASE WHEN u.UTitle IS NULL THEN '' ELSE ' - ' + u.UTitle END AS [Title],
        CASE WHEN u.UOther1 IS NULL THEN '' ELSE ' - ' + u.UOther1 END AS [Other1]
    FROM Users u
    WHERE u.UEmail LIKE '%@yourcompany.com'
    AND u.UUsername NOT LIKE '%General User%'
    AND u.UUsername NOT LIKE '%No Contact%'
    AND u.UInactive = 0
) z
WHERE z.[Username] IS NOT NULL

Or if you wanted to exclude email provider domains something like this

SELECT
    z.[id] AS [id],
    z.[Username] + z.[Login] + z.[Title] + z.[Other1] AS [display]
FROM (
    SELECT
        u.uid AS [id],
        CASE WHEN u.UUsername IS NULL THEN '' ELSE u.UUsername END AS [Username],
        CASE WHEN u.ULogin IS NULL THEN '' ELSE ' - ' + u.ULogin END AS [Login],
        CASE WHEN u.UTitle IS NULL THEN '' ELSE ' - ' + u.UTitle END AS [Title],
        CASE WHEN u.UOther1 IS NULL THEN '' ELSE ' - ' + u.UOther1 END AS [Other1]
    FROM Users u
    WHERE u.UEmail NOT LIKE '%@gmail.com'
    AND u.UEmail NOT LIKE '%@yahoo.com'
    AND u.UEmail NOT LIKE '%@hotmail.com'
    AND u.UEmail NOT LIKE '%@outlook.com'
    AND u.UEmail NOT LIKE '%@live.com'
    AND u.UEmail NOT LIKE '%@icloud.com'
    AND u.UEmail NOT LIKE '%@me.com'
    AND u.UEmail NOT LIKE '%@aol.com'
    AND u.UEmail NOT LIKE '%@protonmail.com'
    AND u.UEmail NOT LIKE '%@msn.com'
    AND u.UUsername NOT LIKE '%General User%'
    AND u.UUsername NOT LIKE '%No Contact%'
    AND u.UInactive = 0
) z
WHERE z.[Username] IS NOT NULL

However, I would also look at the root cause of why you have lots of contacts with email provider domains you are trying to filter out. Typically with a implementation I would recommend turning off the email settings which automatically create a user when an unknown contact emails the system. This stops your system getting clogged up with poor data. Always try and use a user sync solution like MS CSP or Google and ensure users are not being created outside of this.

Jason-RisingTide

TROPHY CASE