HaloPSA for Beginners
A Deep-Dive Getting-Started Series (5 Parts)

HaloPSA is a powerful platform, but it is not a system you learn by clicking around. It is designed around structure, relationships, and defined behavior, which can feel unfamiliar to first-time users or to teams coming from other PSA tools.

This series is written for:

• First-time users opening HaloPSA for the first time

• Teams migrating from ConnectWise PSA

• Owners, managers, and technicians who want to understand how HaloPSA is organized before configuring or using it daily

The goal of this series is education, not instruction. Each article focuses on how HaloPSA is structured, how its core components relate to one another, and how work flows through the system at a fundamental level.

No setup steps are assumed.
No best practices are presented as facts.
No prior Halo experience is required.

By understanding the foundation first, everything that follows in HaloPSA becomes easier to navigate, easier to explain, and easier to manage long-term.

PART 1 — First Login and Navigation: How HaloPSA Is Structured

Why HaloPSA Feels Overwhelming at First

HaloPSA exposes structure instead of hiding it.

Many PSA platforms funnel users into a single primary screen (usually tickets). Halo does not. Instead, it presents a system built around objects and relationships. For new users, this feels unfamiliar, even if they are experienced in other PSAs.

This is not complexity for its own sake. It is architectural.

Understanding this early prevents frustration later.

What You See When You Log In

On first login, users typically see:

• A left-hand navigation menu

• A top navigation bar

• One or more dashboards or landing pages

What appears is controlled by:

• Role permissions

• Enabled modules

• Assigned teams

Two users logging in may see different menus. This is expected behavior, not an error.

Object-Based Navigation Explained

HaloPSA navigation works by opening records, not executing actions.

You do not “go to tickets to work tickets.”
You open a ticket record and then work within it.

The same applies to:

• Customers

• Projects

• Assets

• Contracts

Each record is self-contained and context-aware.

This design allows:

• Full visibility without jumping between screens

• Consistent behavior across modules

• Reporting based on record state, not user actions

Core Navigation Areas Explained in Detail

Service Desk

The Service Desk contains reactive work:

• Tickets

• Queues

• Ownership views

• SLA indicators

It is optimized for daily operational activity.

Customers

Customers are the system anchor.

From a single customer record, users can trace:

• All open and closed tickets

• All projects

• Associated users

• Linked assets

• Active contracts

This makes customers the starting point for investigation and analysis.

Projects

Projects are structured, planned work.

They exist independently of tickets but may reference them. Projects introduce:

• Phases

• Tasks

• Dependencies

• Timelines

Projects are not “advanced tickets.” They are a separate object type.

Assets

Assets provide context.

They help answer:

• What is affected?

• Where is it?

• Who uses it?

• Is it covered?

Assets do not generate work automatically. They enhance understanding.

Configuration

Configuration defines system behavior.

Changes here affect:

• How tickets behave

• How SLAs calculate

• How automation executes

• How reporting appears

New users should explore configuration read-only until they understand downstream impact.

ConnectWise PSA Navigation Comparison