By
Mendy Green
July 5, 2024
•
20 min read
Fundamental Skills
Professional Development

Over the years of training and assisting various technicians, I've formed a set of guidelines that I've been known to drill constantly. The other day while talking to a newer technician and working with them I realized that I now have the time I didn't have before to actually write down what I've been ranting about for 14 years. I've dubbed them as the Laws for the Practical Technician.
There's a lot of nuance in each "law" so now that we got the TLDR version out of the way let's dive into the specifics. Note for the purposes of this post, each law has been given a title.
If you run around with your eyes closed expecting nothing to get in your way, you're bound to smack into a wall (or something) and fall down. If you keep your eyes open and aware of your surroundings you can navigate the obstacles and overcome them.
End users typically expect systems to work seamlessly and view issues as problems needing external help. Technicians, on the other hand, approach systems with the expectation that things might not work and are prepared to "figure it out" each time.
Key Points:
Example: When dealing with a software bug, an end user might see it as "broken" and wait for a fix. A technician, however, will explore various angles—checking logs, considering recent changes, and testing different scenarios to identify the root cause, or find a viable workaround
Computers and software are designed to be used, (it's actually the only way they make money!). Therefore, the information needed to operate or troubleshoot them is generally available on the screen or in logs, (although the language can be context-specific for the industry). To effectively identify and solve issues, it's crucial to explore the interface and ask questions. Thoroughly reading on-screen messages and prompts can provide insights into what might be wrong and how to address it.
When encountering an error message or unexpected behavior, don’t rush to conclusions, AND DO NOT SKIP IT!
Instead, read all the details provided. Error codes, system messages, and even seemingly minor details can offer significant clues. For instance, a message that seems obscure at first glance might make sense when considered within the context of the application or system you're working on. Even comparing against a computer that is working, looking for differences in behavior, or order of operations, screen activity, and so on, can provide clues (for example an error that takes a while to appear is likely caused by a timeout, vs an error that appears immediately is likely caused by an immediate rejection).
Example: If a user reports an issue with a software application crashing, instead of just noting "application crashes," you should read any error messages, logs, or system prompts that appear when the crash occurs. These details can guide you towards understanding the root cause and potential fixes.
To effectively troubleshoot, ensure you can recreate the problem and understand its significance. Start by asking the person reporting the issue why it's a problem and why it's important to solve it. Gather as much information as possible to understand all sides of the issue. You should be able to understand the problem at least as well as the person reporting it to you, otherwise how do you expect to fix it? Or even explain it to the next escalation point if you have to reach out for help?
Here are some ways you can work to understand the problem.
Example: If a user cannot access a shared network drive, ask them about any recent changes to their system, any specific error messages they receive, and how critical this access is to their work. Look at what the shared drive is mapped to, and if other people have access to it that are working. Identify the network the user who is complaining about is on and if it has connectivity to the shared drive host. This comprehensive understanding allows you to troubleshoot more effectively and escalate if needed.
Being intentional in your actions means making deliberate, thoughtful decisions rather than taking random stabs at fixing an issue. This approach prevents exacerbating the problem and leads to more efficient troubleshooting. Most technicians below Tier 3 will perform troubleshooting by way of "trying different thing to see what works", this is essentially closing your eyes and trying to pin the tail on the donkey, make sure you understand what is going on, and the logical reason why what you're attempting will affect (either negatively or positively) the current outcome so that you can make progress with every step.
Expand on This:
Example: If a printer isn’t working, don’t randomly try different fixes like restarting the printer, reinstalling drivers, or changing settings. Instead, follow a logical sequence—check for error messages to help point you towards a connection issue or a driver issue.
Always be prepared to reassess what you know. Technology and systems evolve, and what was true yesterday might not hold today. Keeping an open mind and questioning assumptions can lead to discovering the true cause of an issue.
Expand on This:
Example: If a network issue arises, don’t assume it’s due to the same cause as last time. Reevaluate the situation - start the troubleshooting process from scratch everytime until you've identified the root cause to the be the same as last time.
Always have a contingency plan before making changes. Ensure that any action you take can be reversed if it doesn’t resolve the issue or causes new problems.
Expand on This:
Example: Before modifying a system registry, backup the registry or export the key in question. Rename something instead of deleting it, or cut/paste it somewhere else. This way, if the change has unintended consequences, you can easily revert to the previous state.
----
Edit 2024/11/13 | This article has been presented and recorded at The IT Nation Connect 2024 in Orlando, Florida! You can watch it here: https://youtu.be/ZJqhT48pnLU

Episode 20 of By the [run]Book dives into HaloPSA v2.214 with a mix of practical improvements and some quirky additions. Connor and Mendy walk through everything from new dollar variables and asset controls to Avalara fixes and portal enhancements—highlighting what actually matters for day-to-day MSP operations. This episode is especially useful for MSPs refining workflows, automation, and reporting accuracy in Halo.
Watch Now: By the [run]Book: Episode 20
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
Mendy and Connor noted this was very useful.
Highlighted during the user action demo as a practical workflow improvement.
Called out as a genuinely useful UI improvement.
Allows more flexibility in how incoming emails are matched to tickets.
Enables automation of asset configuration through API usage.
Introduces a new variable to output custom fields in Q&A format.
Improves visibility into asset changes over time.
Returns the email address of the user associated with a purchase order.
Enhances usability and visibility of search results in the portal.
Provides control over configuration synchronization.
Ensures correct popup behavior when multiple rules trigger.
Makes ticket source available for reporting and filtering.
Adds safeguards when configuring email matching tags.
Allows distribution lists to target all email addresses tied to a user.
Improves clarity in Avalara transaction records.
Adds control over visibility of user actions in the portal.
Improves flexibility when using Accounts and Prospects.
Enables dynamic fields based on asset lifecycle status.
Ensures asset tagging consistency during stock processes.
Adds control over Avalara synchronization scope.
Allows a predefined score for surveys.
Improves visibility when prorating billing items.
Automatically generates a ticket alongside sales orders.
Allows column width customization in list views.
Changes ordering of lists in the team view.
Adds asset status as a usable variable in buttons.
Improves flexibility when viewing lists.
Allows visual customization of buttons.
Enables distribution lists based on ticket criteria.
Adds control over forecast data ranges.
Enhances performance of Azure/Entra sync.
Improves visibility of ticket closure information.
Optimizes webhook performance and payload handling.
Refines permissions for asset management.

Episode 19 walks through HaloPSA v2.212 and v2.214, covering a wide range of quality-of-life improvements, admin controls, and workflow enhancements. Connor and Robbie highlight updates around ticket forms, invoicing, templates, and automation, making this especially useful for MSPs looking to tighten processes and improve day-to-day efficiency.
Watch Now: By the [run]Book: Episode 19
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
Allows assets to be linked directly to a client instead of only via a site.
Improves tracking of report usage across dashboards.
Adds control over end-user assignment in templates.
Prevents actions on tickets for stopped clients or sites.
Allows updating custom fields directly via actions.
Prevents approval of expired quotes.
Adds variables for original customer addresses.
Ensures hidden fields do not retain values.
Adds advanced relative date filtering.
Adds preview functionality for templates.
Allows editing of existing meter readings.
Improves grouping of invoice items.
Enables merging duplicate assets.
Displays number of related tickets.
Enhances monitoring integration mapping.
Adds more control to purchase order lifecycle.
Enables workflows triggered by agent emails.
Adds mapping and geolocation features.
Introduces guided project setup.
Allows updating ticket fields post-creation in chat.
Prevents deletion of populated top-level structures.
Improves timesheet usability.
Fixes inconsistent quote PDF behavior.
Aligns quote email behavior with configuration.
Adds access to billing profiles from invoice screen.
Allows use of quote data in actions.
Adds new automation trigger.
Adds rich text support for asset fields.
Prevents closure when tasks remain open.
Adds approvals to activity feed.
Removes agent login option from portal.
Adds ordering control to lookup codes.
Adds planning field to releases.
Enables guided onboarding tools.
Adds note field to consignment lines.
Expands team visibility.
Extends accessibility tools to main app.
Displays previous invoice values.
Exposes billing data to API.
Adds search to selection fields.
Aligns call screen logic with ticket settings.
Links credit lines to original sales orders.
Improves invoice ID handling.
Introduces role-based API identity.

In this episode of By the Runbook, the team continues through the HaloPSA 2.212 release notes and spends time unpacking what several of these changes actually mean in practice. The conversation covers workflow design, mail campaigns, ticket views, reporting, and automation behavior, with especially useful commentary for MSPs trying to decide what to enable, what to ignore, and what to be careful with.
Watch Now: By the [run]Book: Episode 18
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
Check out MSP Blueprint for info on runbooks: MSPBlueprint
This allows the ticket screen to automatically refresh when a background automation completes.
Expands qualification matching to include custom field criteria.
Adds delayed and retry-based webhook processing options.
This change limits the available “From” addresses on a ticket action to mailboxes the assigned team can actually access.
Adds Email Address as another attribute option for follower behavior on the portal.
Allows changes to Mail Campaigns after they have started.
Restricts pipeline stages based on opportunity type.
Adds webhook processing options including delayed and retry handling.
Adds the ability to hide tickets from the change calendar.
Adds Service Users as a selectable option in distribution and user lists.
Allows campaigns to be sent from sales mailboxes.
Adds a warning when an action email will fail.
Adds asset relationship mapping during SQL imports.
Adds an isRunning field to asset discovery.
Expands qualification matching with custom field rules.
Allows ticket view to auto-refresh after automation runs.
Adds ability to update currency values on quotes.
Requires comments for negative KB feedback.
Adds control for showing nested tickets.
Enhances AI reporting capabilities.
Restricts KB edits to owners only.
Adds translation support in the portal.
Adds secondary MAC address support.
Adds character limits to text fields.
Adds more fields for OLA and rule reporting.
Prevents approvals from email replies.
Extends field copying to deeper ticket levels.
Adds primary asset as a runbook condition.
Adds AgentID variable for lookups.
Adds reporting changes to config tracking.
Adds filter profiles to child ticket views.
Adds more configuration options to other open tickets view.