Skip to main content
The Microsoft Teams — Technician Mapping integration connects Neo to your own Microsoft 365 tenant (not your clients’ tenants) and does three things:
  • Maps each technician to their Microsoft account — the foundation. This identity link is what lets a chat agent recognise whoever is asking, so it can assign a ticket to them (“assign this to me”) and record what it creates in your PSA under their name rather than Neo’s — their time entries land on their own timesheet. It works in a custom internal bot and in the dashboard chat, and it’s the prerequisite for everything below.
  • Puts real faces on relayed ticket replies — automatic. When a technician answers on a ticket, that reply is relayed into your end-user Teams bot as a card. A mapped technician’s card carries their own Microsoft profile photo instead of coloured initials. There is nothing to switch on: once the integration is connected, map the technician and their photo appears.
  • Feeds live availability into Ticket Dispatch — optional. With Teams availability turned on for a dispatch workflow, Neo won’t assign work starting now to someone who is Away, Offline, or out of office, prefers technicians whose Teams Shifts rota covers the time the work would start, reads each shift’s label (an on-site client name, or an absence marker like Annual Leave), and excludes anyone whose Shifts time off overlaps the work for an absence reason.
Connecting the integration only performs the mapping — it does not change dispatch on its own. Availability is opt-in per dispatch workflow (and Shifts is a further opt-in), so you can connect this purely for chat dispatch without affecting how tickets are routed.
This integration reads your service desk’s own Microsoft tenant. It is separate from the Microsoft 365 integration that lets agents act on your end-clients’ tenants.

​
Set it up

You’ll need an administrator of your own Microsoft 365 tenant for step 2 — someone who can grant admin consent (typically a Global Administrator).
1

Open the integration

Go to Integrations → Directory → Identity & Workspace and click Microsoft Teams — Technician Mapping. The connect panel shows consent, technician mapping, and optional Shifts settings.
2

Grant admin consent

Click Open consent page. Microsoft’s consent screen opens in a new tab and lists what Neo asks for — sign-in basics plus four read-only application permissions:Neo never writes anything in your tenant, and these permissions do not cover chats, files, or mail. After you accept, you land back in the Neo dashboard — click Continue setup to return to the integration.
3

Add technician profiles

Auto-map works on the technicians listed on the Technicians page. Add at least one technician there before you run it. Neo does not create profiles for every PSA account automatically.
4

Auto-map technicians

Click Run auto-map. Neo scans every Team in your tenant, then matches each technician profile by comparing its PSA email against each Microsoft member’s email or sign-in name (UPN). The review shows Matched and Unmatched technicians. Map any unmatched technicians manually — see Mapping technicians.
5

Configure Shifts (optional)

If your rota lives in the Teams Shifts app, turn on Read shift rota from Microsoft Teams Shifts, select the Team(s) that hold the rota, and click Save shift settings. This Team picker affects Shifts only; auto-map always scans every Team.
6

Turn it on per workflow

Enable the Teams availability toggle on a Ticket Dispatch action. A workflow can also override the saved rota Teams in the toggle’s settings.

​
Mapping technicians

The integration runs on one piece of state: a link from each PSA technician to their Microsoft account. Dispatch only sees presence and shifts for mapped technicians.
  • Neo links by name after each technician sync. The sync runs every day and when you add technicians. A technician with no link gets one when exactly one technician and exactly one Microsoft account share the name. The accounts are the people who use Neo in Teams and your dashboard members. A name that two technicians or two accounts share stays for you to map. A name link needs no admin consent, so on its own it brings no presence, shifts or photo: those read Microsoft 365, which needs the integration’s consent.
  • Auto-map matches on email. The technician’s email address in your PSA must equal the Microsoft account’s email or sign-in name (UPN). Technicians whose PSA record uses a different address — an alias, a shared address, a personal email — come back as Unmatched. An email match replaces a name link.
  • Manual mapping. Open Technicians, open the technician’s Microsoft pane, and pick their Microsoft account from the list, or type the Entra object ID. A badge shows how the mapping was set: Auto-mapped, Matched by name or Manual. One Microsoft account belongs to one technician, so an account another technician holds is refused.
  • Re-running auto-map never touches manual work. Auto-map always scans every Team. It never overwrites or clears manual mappings, but it clears an auto-derived mapping when that technician no longer matches any Team member.
  • To remove a mapping by hand, clear both fields in the technician’s Microsoft Teams Mapping section and save. The technician then stays unlinked: neither the name match nor auto-map links them again until you set a mapping by hand.
  • Find the gaps. Open a technician on the Technicians page and select Microsoft to see their mapping and how it was set. A technician whose name matches no account, or matches more than one, stays unmapped until auto-map finds their email or you map them by hand.
  • An unmapped technician cannot be recognised in chat. An internal Chat Agent is told it cannot place the speaker, so it declines a request that needs their PSA technician record, such as showing the tickets assigned to them, assigning or dispatching a ticket to them, or logging their time, and tells them to have their account mapped. It never picks a technician on their behalf. Requests that need no PSA technician still work: the Neo Support Agent opens a support ticket with the Neo team under the person’s verified Teams account.
The integration card shows Connected once at least one technician is mapped by auto-map or by hand. Name links do not count, because they need no consent.

​
Technician photos on relayed replies

Your end-user Teams bot relays a technician’s client-facing ticket note into the employee’s chat as a card showing who replied. Where that card would otherwise show coloured initials, a mapped technician gets their own Microsoft 365 profile photo.
  • No setup and no switch. This follows the mapping. Once a technician is mapped and the integration is connected, their photo appears on their next relayed reply.
  • A technician who is not on the Technicians page can still get a photo. Neo falls back to matching the note author’s PSA email address against your Microsoft directory, so your whole service desk benefits from the integration, not only the profiles you added.
  • Initials whenever there is no photo to show — an unmapped technician, someone whose PSA email matches nobody, or an account with no photo set in Microsoft 365. Nothing is ever left blank.
  • Only your own tenant is read. The photo is embedded in the card that Neo sends, so your client’s Microsoft tenant never reaches into yours to fetch it.
  • Photos follow the channel’s attribution setting. A channel set to Show your own name instead or Don’t label them shows no technician photo, because it names no individual — see Relayed technician messages.
A newly set photo, or a technician mapped after their first relayed reply, appears within a few hours — Neo caches what it finds so a busy ticket doesn’t re-check on every note.

​
What dispatch does with it

Live presence. A technician whose presence is Away, Offline, or who has out-of-office set is treated as on a break and is skipped for work starting now. Busy, In a call, Presenting, Do not disturb, and Be right back all still count as working — being occupied is what workload balancing is for; the presence check only asks “are they at their desk and on the clock?”. Presence is a right-now signal, so it is time-scoped: when the workflow books a schedule entry further in the future, a technician on a break right now can still get that slot — only slots starting within the next ~2 hours are blocked by live presence. Shifts. If you configure the rota team(s) in the dispatch action’s Teams availability settings, Neo reads each mapped technician’s upcoming shifts and prefers technicians whose shift covers the proposed assignment time. A mapped technician with no shift in the planning window is deprioritized as likely off-rota (custom instructions can override). Shifts influence AI dispatch only; Round Robin uses the on-break presence check. Neo reads each shift and time-off entry on the same clock as the technician’s calendar, or in your company’s timezone when it reads no calendar for them, so write shift times in your custom instructions on that clock too. By default Neo reads shifts from the current time onward, so a shift that ended earlier today is not in the window. If your instructions make a technician unavailable once their last shift of the day has ended, turn on Should Neo see today’s earlier calendar entries? in the dispatch action (on a dispatch agent, its technician context needs both include_teams_availability and include_earlier_today). Neo then also reads today’s ended shifts and marks each one as ended. An ended shift does not by itself count as a time clash with a new slot. Neo also reads each shift’s label (the name you give a shift in the Shifts app). Labels carry meaning, so Neo weighs them rather than treating every shift as plain availability: a shift named for a client or site is read as an on-site commitment (pair it with a custom instruction like “Don’t assign to someone who is on-site unless the ticket is for that same company”), and a shift named for absence — Annual Leave, Holiday, Sick, Bank Holiday — is read as time off, not as a reason to prefer that technician. Time off. From the same rota team(s), Neo reads each mapped technician’s Shifts time off, together with the reason you picked for it. The reason decides what happens, because teams use this calendar for more than absence:
  • A reason that means the person is away — Annual Leave, Holiday, Sickness Absence, Bank Holiday, Compassionate Leave — is a hard block. They’re excluded from work overlapping it even when their PSA calendar looks clear, because the commitment lives only in Shifts. This is what lets a rota that records only time off (no shifts at all) still keep people off dispatch while they’re away.
  • A reason that records where or how someone is working — London Office, Working from Home, On Call, Training, Early / Late Shift, a client visit — does not block them. Neo reads it as context, and you can act on it with a custom instruction (e.g. “Don’t assign to someone recorded as on a client visit unless the ticket is for that client”).
So you don’t have to restructure a Shifts calendar that doubles as a location tracker: name your absence reasons plainly and Neo will tell the two apart. Fallbacks. The integration never blocks dispatch. If Teams can’t be reached, consent was revoked, or no technicians are mapped, dispatch falls back to its normal PSA-based logic and the run output notes why presence wasn’t used. Technicians without a mapping are simply judged on the other criteria — they are never penalized for missing presence data.

​
Check that it’s working

Run the dispatch workflow on a test ticket and open the execution’s details:
  • When presence was used, the dispatch reasoning references the technicians’ Teams availability (on a break vs. working).
  • When it wasn’t, the run output says why in plain words — for example, “Teams availability is enabled, but none of the candidate technicians are mapped to a Microsoft user — dispatch used PSA-only availability.” That message points you back to the auto-map step.

​
Custom instructions

The default break rules can be overridden per workflow with dispatch custom instructions, for example:
  • “Treat Do not disturb as unavailable.”
  • “Ignore Teams presence for P1 tickets.”

​
Troubleshooting

Add the technicians you want Neo to map on the Technicians page, then run auto-map again. Auto-map maps those profiles; it does not add every PSA account automatically.
This is expected. Auto-map scans every Team so it can find each technician by email or sign-in name. The Team picker appears only when you turn on the optional Teams Shifts rota.
Neo knows who is speaking, but no technician record matches that Microsoft account. The mapping is missing or points at a different account, or that person has no technician profile yet. Open Technicians and find that person — if they have no row, add them with Add Technician first. Then check their Microsoft Teams Mapping: re-run auto-map, or set the Microsoft Entra object ID by hand (the UPN is optional). The agent declining is the expected behaviour for an unmapped speaker: it never chooses a technician for them.
The match key is the technician’s email address in your PSA versus the Microsoft account’s email/sign-in name. Spot-check a couple of technicians: if your PSA stores a different address (alias, distribution address, personal email), either fix the PSA email or map those technicians manually on the Technicians page.
Two by-design cases: the assignment was a schedule entry starting more than ~2 hours out (live presence only blocks imminent work — the calendar and shifts govern later slots), or the technician shows Do not disturb / Busy / Be right back, which count as working. To change the defaults, use custom instructions (e.g. “Treat Do not disturb as unavailable”).
Check, in order: the Teams availability toggle is on for that workflow; the technician is mapped (Technicians page → Microsoft Teams Mapping); and they actively use Teams — accounts without a Teams license or an active session report an unknown presence, which Neo treats as “no signal” rather than on-break, so those technicians are judged on the other criteria only.
Shift preference requires: the rota Team(s) saved in the integration or selected in the dispatch action’s Teams availability settings, the rota living in the Teams Shifts app of those Teams, and the technicians being mapped. It is also a soft preference for AI dispatch only — Round Robin doesn’t consult shifts.
Shifts time off is read from the same rota team(s) as shifts, so it needs the same setup: the rota team(s) set in the dispatch action’s Teams availability settings, the time off recorded in the Teams Shifts app of those teams, and the technician mapped. It applies to AI dispatch only — Round Robin uses the presence check. If the setup is right and the technician still isn’t excluded, check the reason on the entry: only a reason that reads as absence is a hard block, so someone recorded as Working from Home or On Call stays dispatchable by design. Rename an ambiguous reason (or add a custom instruction naming it) if you want it treated as absence.

​
Security and data

  • Access is read-only and confined to your own tenant — the four application permissions above, granted through Microsoft admin consent and revocable in your Entra admin center at any time.
  • These permissions do not let Neo read your chats, files, mail, or calendars.
  • The only thing Neo stores is the per-technician mapping (the Microsoft account ID and sign-in name on the technician record). Presence and shift data are read at dispatch time and never persisted.

​
Public API

The integration can also be configured programmatically:
  • GET /public-api/teams-availability/consent-url — get the admin-consent URL
  • GET /public-api/teams-availability/teams — list your tenant’s Teams
  • POST /public-api/teams-availability/auto-map — run the technician auto-map
Full request/response schemas are in the public OpenAPI spec at GET /public-api/openapi.json.