Someone leaves the business. The mailbox is closed, the Halo user is deactivated, and offboarding is signed off. Six weeks later a weekly report is still going to that address, because it was typed into a report schedule two years ago and nothing on the user record mentioned it. With thirty scheduled reports, one joiner, leaver or team move can mean opening thirty schedules to find where that address appears.
Version 2.236, the 2026 Second Release, lets a report schedule take its recipients from a Distribution List instead of typed addresses. Set the schedule's new "Recipient Type" field to "Distribution List" and the To, Cc and Bcc fields are replaced by a single Distribution List drop-down. Both the HaloITSM and HaloPSA release notes carry it, and HaloCRM has the same feature under the name Segments. Scheduling still sits on the report's "Scheduled Emails" tab. The full detail is in the Halo release note.
Until now the schedule's "To" field was the only documented recipient mechanism, holding semi colon separated addresses. Every schedule therefore carried its own private copy of a mailing list, and nothing on a user record told you which reports that person received. Halo's own wording is that the change removes the need to maintain individual email addresses on each report as team membership changes.
Leavers are the sharper case. An address left in a schedule keeps receiving operational data, with nothing prompting anyone to remove it. Moving recipients onto a list changes that: they are managed in one place rather than per schedule, and each user's memberships and past communications become visible on their own record, with an optional entry in their activity feed.
The version worth designing for is a dynamic list. Membership can be driven by a filter on user fields, on clients and sites, and from v2.244 on customer type and customer custom fields, with SQL available in place of filters. Point that filter at the fields your Entra or user import keeps current and report distribution follows the same source of truth as your user records. You build the filter yourself though. Halo does not sync Entra or Active Directory groups to Distribution Lists.
The audit trail helps too. Each list has a History tab of what has been sent to it, and member count snapshots can be scheduled and reported on.
End users Receive the reports relevant to their current role, because membership sits on the list rather than inside each schedule, and is visible on their user record.
Service desk agents Can be given "Read and Send" so they send to a list without being able to change its membership.
Team leaders Change recipients once, centrally, instead of editing every affected schedule.
Management One auditable place showing who receives which reports, with member count snapshots to trend.
Turning it on takes minutes. Three prerequisites:
The real effort is list design. Budget half a day to a day for a first set of lists in a mid sized instance. Dynamic lists need a defensible filter set or SQL. Static lists are populated by hand, in bulk from any user list, or by spreadsheet import matched on UserID, so you need user IDs rather than just addresses. One decision is irreversible: the dynamic flag is fixed once the list is saved. No release note or guide states an edition or module requirement, so check your Halo edition.
Worth restating, because it catches teams out. Halo does not map an Active Directory or Entra ID group straight onto a Distribution List. The Entra integration guide maps Azure groups to Halo user roles, agent roles, sites, teams and CABs, and allows Azure distribution groups as ticket followers, but not to Distribution Lists. Do not plan for that sync. The route that works is indirect: let the directory import populate the user fields, then filter a dynamic list on them.
A static list solves nothing long term. It is the same manual maintenance on a different screen, and the joiner, leaver and mover benefit only holds if the list is dynamic or fed by a process someone owns. On a dynamic list, the "Include inactive Users when sending Emails to this List" option only appears when dynamic membership is switched off, so excluding leavers has to come from your filter criteria.
Choosing Distribution List replaces To, Cc and Bcc, so one schedule cannot mix a list with an ad hoc address. Nothing documents more than one list per schedule.
Test delivery before you rely on it. The documentation does not say whether a report goes out per member or as one BCC, how a partial failure is surfaced, or whether an unsubscribe opt out suppresses scheduled report delivery. And since a scheduled email is one rendered output sent to everyone, widening a list widens who sees the data.
Report distribution is one of the quietest data exposures in a service desk, because an address typed into a schedule is invisible to everyone, including the person receiving the reports. As a Halo partner working across the UK and Israel, Hikon does the design work the feature does not: deciding which lists should exist, making them dynamic against attributes the business actually maintains, wiring those attributes to your identity source at import, and auditing the schedules that still hold hardcoded addresses.
The full release detail is in the Halo release note. If you want to talk through which lists your instance should have, get in touch with Hikon.
Talk it through with the people who wrote it — a free 20-minute call, no pitch.
Let's talk →Book a free 20-minute call about your platform and your plans — no pitch, no obligation.
Start the conversation