Skip to main content
The Get Technician Context tool feeds a dispatch agent a structured, pre-computed snapshot of your technicians — who’s working today, when, how loaded they are, and who has the right expertise — so it can make a good assignment decision quickly without re-deriving any of it from raw PSA endpoints. It works for ticket-triggered runs and for scheduled (ticketless) sweeps; specifying the technician pool via the ticket’s company or board team requires a ticket, while passing an explicit list of technicians works in either mode.
Auto-injected for any workflow whose PSA integration has its scheduling-equivalent permission group enabled at Read+ (ConnectWise Schedule Entries, Autotask Service Calls, Halo Appointments, ServiceNow Users and Groups). You’ll see it in the toolbox automatically — no need to toggle it on manually. It pairs with the agent’s Dispatch Decision Framework skill, which the agent loads to interpret the context.

​
What It Does

It returns, per technician:
  • Calendar — weekday working hours (days flagged “Not working” when off), timezone, holidays, today’s existing appointments, and a wrap- and timezone-resolved “on shift / off shift right now” summary so the agent doesn’t have to re-derive overnight-shift or timezone math itself (it still overlays time-off and holidays before deciding)
  • Workload — open ticket count, recent assignment volume
  • Expertise — the technician’s profile plus PSA-configured skills (ConnectWise and Autotask; plus ConnectWise certifications), prior work on similar tickets, the relevant configuration items or technologies
  • Recent Neo assignments — which tickets the agent recently dispatched to each technician, with timestamps, so it can round-robin fairly across the team and avoid handing consecutive tickets to the same person
  • Teams availability (optional) — from your own M365 tenant: each technician’s live presence (Available / Away / Busy / In a call / Offline / out-of-office), so the agent won’t hand work starting now to someone who’s away or on a break; plus their shift rota (upcoming Microsoft Teams Shifts, with each shift’s label — an on-site client name or an absence marker like Annual Leave), so the agent can prefer whoever is actually rostered on — now or for a future slot; plus their Shifts time off, with the reason you gave it — an absence reason (Annual Leave, Sickness Absence, Bank Holiday) is a hard block for work overlapping it, while a reason that just records where someone is working (London Office, Working from Home, On Call) is read as context, not as absence
The agent uses this to choose an assignee (or to decide the ticket should be escalated or left unassigned), then acts via the PSA API — for example setting the ticket’s owner or adding a schedule entry.
Picking the pool from a ticket’s team is PSA-aware, with a graceful fallback. The agent can source candidates from the ticket’s company team or board/queue team, or pass an explicit list. Board/queue teams are a ConnectWise concept; on Halo, Autotask, and ServiceNow — or whenever the ticket has no board/company team, or the team is empty — the tool doesn’t error. It returns the PSA’s full active technician roster as fallback candidates and flags that it did so, so the agent knows to confirm each candidate’s team/skill/availability suitability rather than treating the list as a curated team match.
Teams availability is fetched only when the agent asks for it. Presence is a current-moment signal (who can take this now); shifts are the rota (who is scheduled on, now and for future slots). Both require the Microsoft Teams — Technician Mapping & Availability integration connected and technicians mapped to their Microsoft user; shifts also read the Teams you selected when mapping (your service-desk Teams). When a piece isn’t available, the agent falls back to PSA calendar availability. It’s the same signal as the Dispatch Ticket action’s “Teams availability” setting, surfaced for agentic dispatch.

​
Why It Matters

Each PSA exposes “is this engineer working today” through a different chain of endpoints with non-obvious field names (e.g. ConnectWise’s mondayStartTime / sundayEndTime on schedule/calendars/{id}, Autotask’s InternalLocationWithBusinessHours + per-resource overrides, Halo’s api/Workday). Asking the agent to reconstruct that on the fly is brittle: a misspelled field name or a missing day attribute leads to silent guesses (“probably Mon–Fri 09:00–17:00”) and engineers scheduled outside working hours. Get Technician Context is the canonical answer to working-hours / availability questions. Custom instructions that reference “engineer’s working hours” or “calendar working days” should let the agent reach for this tool, not derive it from primitives.
Set your technicians’ timezones so appointments schedule in local time. Working hours are reported in each technician’s own timezone. On HaloPSA, Neo resolves that timezone in order — the technician’s agent-level Timezone, then their assigned Workday’s timezone, then your tenant’s default timezone. Setting a Timezone on the technician’s agent record (or their Workday) keeps dispatched appointments inside their real working hours; a technician with no timezone anywhere falls back to your tenant default rather than UTC.

​
How to Use

  1. Build a dispatch workflow (or start from a dispatch recipe)
  2. The tool is auto-enabled when your PSA scheduling perm is on — no extra toggle needed
  3. In custom instructions, describe your routing rules — preferred boards, escalation thresholds, who handles what. Reference “engineer’s working hours” / “calendar working days” naturally; the agent will fetch them via this tool
  4. Review assignments in Event History before turning off technician approval
The richer your PSA data — skills on technician records, accurate schedules, configuration items on tickets — the better the agent’s dispatch decisions. This tool only surfaces what your PSA (and connected calendars) already know.