Once helpdesk integration is live, the next foundational layer is the people side. Horizon needs to know who works tickets, what teams they're on, and when they're working. Almost every other configuration in the system — triage routing, assignment policies, watchlist deadlines, scheduled todos — assumes this layer exists.

Users

Problem: Tickets need owners. Notifications need recipients. Calendars need owners. Panels need someone to log in. Every one of those things needs the same underlying record: a person.

Horizon's answer: A user is the Horizon-side identity for a person who works in your account. Each user can:

• Log into one or more panels (Agent, Dispatch, Admin).
• Belong to one or more teams.
• Have a default panel they land on at sign-in.
• Receive notifications via configured contact methods (email, in-app, others).
• Be linked to a helpdesk user.
• Be linked to one or more business hours plans (covered below).

Where users come from

You generally don't create Horizon users by hand. New agents get created in your helpdesk provider (ConnectWise, Autotask, Zoho, HaloPSA), and Horizon ingests them on the next sync. After the helpdesk user mapping covered in helpdesk integration runs, those people show up under People → Users automatically.

The flow is: hire someone → create them in the helpdesk → wait for sync → map them in Horizon → finish their Horizon-side configuration. The "create them in the helpdesk" step is where the source of truth lives, so you don't have to manage two systems out of sync.

What you do manage in Horizon

Once a user exists, you configure their Horizon-side behavior under People → Users:

• Default panel — Agent or Dispatch. Admin is not a valid default panel; admins land on Agent or Dispatch and switch to Admin when needed.
• Panel access — which panels this user is allowed to enter.
• Team membership — which teams they belong to.
• Notification contacts — how to reach them.
• Business hours plan link — which schedule applies to them (covered below).

Three relation managers appear on the user edit page:

Treat a new user as production-ready once team membership, notification contacts, and a business hours plan are all set. An agent with no team can't be picked by team-based assignment policies. A user with no notification contacts won't receive anything Horizon tries to send them.

Teams

Problem: You don't assign tickets to "the company" — you assign to a group. Tier 1, NOC, Onboarding, After-Hours, Project Services. Without a way to express those groupings, every assignment rule has to enumerate individuals.

Horizon's answer: A team is a named group of users. Teams are how Horizon expresses "this ticket goes to that group of people" without naming each person.

Teams show up everywhere:

• Triage policies route tickets to a team based on conditions.
• Routing rules decide which team owns a ticket before assignment runs.
• Assignment policies pick a specific user within a team using a method (round-robin, next-available, etc.).
• Business hours plans are linked to teams so the system knows when the team is working.
• Queues are owned by teams.
• Watchlists can scope to teams.

Teams are managed under People → Teams.

Creating a team

1. Navigate to People → Teams.
2. Click Create.
3. Give it a name.
4. Save.
5. Use the Members relation manager on the edit page to add users.

A user can be a member of more than one team. There's no concept of primary team — when assignment runs, every team the user belongs to is considered.

Tip: Resist the urge to model your org chart. Teams are operational groupings used for routing and assignment, not your HR structure. "After-hours on-call rotation" is a fine team. "Marketing" probably isn't, unless marketing actually works tickets.

Business Hours

Problem: Your team isn't online 24/7. Some agents are in different timezones. Some teams cover business hours only, others cover after-hours. If Horizon doesn't know when people are working, it can't make sane decisions about "when is this ticket due?", "who's available right now?", "what's a reasonable booking slot to offer?"

Horizon's answer: Business Hours Plans. A business hours plan defines a working schedule — days of the week, hours per day, holidays, exceptions — and a timezone. Plans get linked to users (and teams use them transitively through their members).

Business hours plans live under Settings → Business Hours, but conceptually they belong with people. Once you've set up users and teams, this is the next thing you configure.

Creating a business hours plan

1. Navigate to Settings → Business Hours.
2. Click Create.
3. Give the plan a name (e.g. "US Eastern 8-5", "UK 9-6", "24x7 NOC").
4. Set the timezone for the plan.
5. Save.
6. Use the Entries relation manager to add the schedule — for each day of the week, the hours the plan covers. Add holiday or exception entries as needed.
7. Use the User Links relation manager to attach this plan to one or more users.

Why timezone lives on the plan, not the user

Different users on the same team may be in different timezones, and the same person may be covered by different plans at different times (e.g. "normal hours" and "holiday coverage"). Putting timezone on the plan instead of the user gives you the flexibility to model that.

In practice, most accounts create a small number of plans — one per office or coverage region — and link each user to the plan that matches their schedule.

What business hours actually drive

Once plans are set up, downstream features use them:

• Watchlists can compute deadlines in business hours rather than wall clock — "due in 8 business hours" skips overnight and weekends.
• Assignment policies can exclude users whose plan says they're off.
• Booking links offer slots only during the host's plan hours.
• Scheduled todos can constrain auto-creation to within business hours.
• Reporting can use business hours when computing time-to-respond and time-to-resolve.

Without business hours, Horizon defaults to wall clock — which is rarely what you want for an MSP that doesn't run 24/7.

Tip: Set up your most common plan first (e.g. "US Central 8-5") and link the bulk of your users to it. You can model edge cases (after-hours rotation, regional coverage) once the common case is solid. Don't try to model every user's exact schedule on day one.

When this is set up correctly

You know the people layer is set up correctly when:

• Every active agent in the helpdesk has a corresponding Horizon user, mapped via helpdesk user mapping.
• Every Horizon user belongs to at least one team.
• Every Horizon user is linked to at least one business hours plan.
• A test booking link offered to a customer shows reasonable available slots in the host's timezone.
• A test triage rule routing to a team correctly identifies a user from that team.

Tip: People configuration is high-leverage and easy to get almost right. The mistake most accounts make is half-finishing — users created but no team membership, teams created but no business hours, business hours created but not linked to users. None of that breaks loudly. It just makes downstream features behave subtly wrong. Audit this layer end-to-end before moving on.