This document describes the HaloPSA Ticket Types, Statuses design and purpose/flow of each type. Hudu Sync
Summary
Tags: #HaloPSA; #Status Standards; #Example document; #TLP:Green;
Halo Status Overview
In HaloPSA Ticket Statuses are a flat table that can be used anywhere throughout Halo. The purpose of the status is to group tickets for managerial oversight, enabling or disabling SLA Hold Reminders, and configuring Email Reminders which is controlled on a per status basis.
Status Standardizations
The color defined on the status will setup the way the ticket appears on the various views, including color coding either the ticket on the Gant, Kanban, or Calendar views and so ideally you want the colors to be standardized so that they mean something across the board.
As with many areas in Halo when you have a flat list, I like to turn it into a multi-dimensional list by introducing my favorite separator:
" - "
Note that this can be used with or without spaces, but you'd generally want to decide which way and keep it the same in each area. When readability is key, spaces work great but when unnecessary can get in the way.
Because different departments or use cases of a status can have different functions enabled, we recommend creating a group of statuses for each area. For example potentially you'd have the following "sets" of statuses created.
- Help Desk -
- Sales -
- Projects -
- Tasks -
BONUS TIP: Having standard well structured names (with separators such as "-" or ":" will make driving automation really easy to do as you can do string manipulation such as splitting by hyphen and then know the first part is the department/type and the second part is the status itself. (Just as an example, there can be as many parts referring to any area you want. As long as you keep it consistent you can bring in enhanced automation).
Global Statuses vs Specific Types of Statuses
There are some statuses that can be "Global" and don't need a prefix, and in some cases you can decide "Help Desk" doesn't need a prefix as that'll be the "main" set whereas the rest should have them.
You would then determine the statuses required for each set, for each state, and make one for each. For example a "New" status is probably required for each so you would have the following
- New (or Help Desk - New)
- Sale - New (or Oppo - New, or RFP - New)
- Project - New
- Task - New
And so on and so forth, you probably wouldn't create a set for Closed, as there can only be one Closed status in HaloPSA and you may or may not make a set for the With User, as you may decide that one Wth User works across the board (both in terms of coloring standards and settings) but this woulld be a decision you would make in terms of what statuses are needed as you go through your setup.
Creating the Statuses
When making each Status, it's important to note that you have the option of setting the Name and the Icon Name. In almost all cases the Icon Name is what will get displayed, and these do not have to be Unique. I like to use the Set Name for the Name field, and then for the Icon name the real state of the ticket. We may have three or four statuses with the Icon name "New" in this case however each one has a separate full name, described as above (Help Desk - New and so on).
Once you've created the various sets of statuses, you want to make sure you don't overwhelm the technicians (or yourself) on which status should be used at which time. You also want to make sure that you don't accidentally end up crossing the tickets to the wrong status Type/Set. You can do this by going to the Ticket Types in HaloPSA that are relevant to each status Set, and on the Allowed Values tab change the Status section to not allow all values, selecting the specific statuses you want to limit to.
Finally under each Ticket Type you'll want to adjust the following settings so that it makes sense, matching the created Status Type status.
TIP: You can also use the below list to help guide you when deciding the statuses you want to create within a "Set"
Details Tab
- Status after Supplier update
- Status after End-Users reopen a closed Ticket
- Status after End-Users reopen a closed Ticket
- Parent Status after all Child Tickets are closed
- Status after user appointment booking (resource booking)
Defaults Tab
- Initial Status
You'll want to make sure each setting is appropriately set to the matching Status "Set" based on the ticket Type, for example for Project ticket types you'll want to set the Initial Status to "Project - New", Task ticket types should be set to "Task - New" and so on and so forth.
Status Sequence
The final thing to note when creating the status is the Sequence number. The sequence number is the number that defines the order a status is displayed in on the screen. This can be if you're grouping the tickets by Status, (such as a Kanban View) which Status is displayed first, or if you're selecting the status from a drop-down.
The Kanban view displays Status swim lanes in the order of the Sequence number!
Sticking with the mindset of standardization, I like to assign a Tens number to the different status "Sets" and then assign a "Status" to the Ones number. So for example where 1 = "New", 01 = "Help Desk - New", 11 = "Project - New", 21 = "Task - New", 31 = "RFP - New" and so on. This will ensure the statuses are displayed in the intended order for each department and is easily memorable, and people don't have to go searching for it.
Service Desk / Help Desk
Since this document is describing the Rising Tide's own HaloPSA setup, and Service Desk isn't heavily used right now, this section has been skipped. Please check back in later.
Projects
In this section, we'll be reviewing the specific Statuses that get used by Projects and when/how each one gets used.
In Projects, we do not have an SLA, and the timeline is mostly set by the Client based on their availability. Since our Clients are primarily MSPs and the day to day is fairly hectic, we want to make allowances for them so that we don't end up putting additional stress in an already stressful life. SLA Hold Reminders are off, SLA's are not used (except maybe to gauge priority of a project for the Client), and finally all scheduling happens via a Calendly booking link and time gets locked in by the MSP either days, a week, or a month ahead.
Project - New
This status is for New Projects, ones that have not yet been assigned a future Schedule, nor have they been started. Projects get created in the New state upon signature of the Quote/Proposal, and then wait until the invoice has been processed. In some cases Projects may be scheduled in advance of payment but the invoice needs to have a payment confirmation prior to the scheduled date or the Project will need to be rescheduled.
Project - In Progress
This is the status that gets used once a Project is started. This will generally be the status an active Project sits in the most, as once started all further updates will occur to the sub-projects (Child Tickets) or tasks (Child or Grandchild Tickets) below.
Project - Scheduled
This status is used for projects that haven't been started yet, but do have an initial schedule date assigned, either a week, a day, or further out. Once a project has been scheduled, it goes into this state until the project has been started. Generally unless a Project goes stale it will stay in the In Progress status throughout its life cycle. If the project does go stale and then a new schedule has been set to resume the project, it goes back into this status, otherwise if a Project that is stale is waiting on the User/Client to schedule or resume then it will go to the next status on the list.
Project - With User
This status is used for projects that have been started, and hung. Communication was lost, and/or the project reached a point where there's nothing further that can be done without Client's assistance or intervention. If the next action is a meeting with the client, then once a meeting has been set the project would go to the Scheduled status, and then finally the In Progress once it resumes. Until then it'll stay here.
New Projects that have been paid and are waiting on a meeting to be booked by the Client will also sit here
Tasks
Task - New
Tasks are placed in New state as soon as they're created and stay here until they begin.
Task - In Progress
This indicates a task actively in progress
Task - Scheduled
If an appointment has been scheduled relating to the specific task, then it goes here
Task - With User
Tasks that are waiting on feedback or confirmation from the client, sit here until they resume the ticket, either by scheduling a meeting or replying back with the required information. Once information has been provided the task goes back to the In Progress state
Opportunities/Sales Tickets/Requests for Purchase
Since the most common types of tickets that aren't projects/tasks are RFP right now, we are using the Global statuses for this instead of using the Global Statuses for the Help Desk area. As such, we didn't specifically build out statuses for this set. Check back later, however, as this will be updated at some point.