Skip to main content
HaloPSA decides what happens to mail arriving at a monitored mailbox using email rules (Configuration → Email → Email Rules). One rule type — Ignore Email — tells HaloPSA to discard mail from a given sender without raising a ticket. Letting Neo manage these rules turns repeat spam from a recurring chore into a one-off action: instead of an agent closing the same spam ticket every time that sender writes in, it adds an Ignore Email rule for the address and HaloPSA stops raising tickets from it. Those repeat closures also stop consuming credits.
HaloPSA’s built-in treat as spam option can’t be reached from quick actions or workflows, and it’s gated on agent role — so a “close as spam” action can only close the ticket, never stop the next one. Email rules are the way to automate this.

​
Two things to enable

Both are required. Neo can read your email rules as soon as the HaloPSA integration is connected, but creating one needs each of these.
1

Enable the `admin` scope on your HaloPSA API application

In HaloPSA, go to Configuration → Integrations → HaloPSA API → View Applications, open the application you created for Neo Agent, then Permissions → Edit. Set admin to Yes and save.Without it, HaloPSA rejects every configuration write — including email rules — with a 403 Forbidden and an empty response body. Reads are unaffected.
admin is a broad HaloPSA scope. HaloPSA itself flags on that screen that all and admin “should not be used in production as they expose administration level access” — it raises the ceiling across HaloPSA configuration, not just email rules.What Neo can actually touch is still governed by the Email Rules permission group in step 2, which is separate from the Configuration group and read-only until you grant it. The dashboard layer, not the scope, is what keeps this narrow. See Creating an API Application for the full scope list.
2

Grant the Email Rules permission group to your agent

In the Neo Agent dashboard, open the agent that should do the blocking — typically a spam-cleanup or triage agent — and on its Integrations tab set the Email Rules permission group to Read / Write.Turn on Delete as well if the agent should be able to remove rules (that’s how a wrongly-blocked sender is unblocked). To review each block before it applies, turn on technician approval for this group.The group is read-only in the Read Only and Helpdesk profiles, and read/write in IT Admin and Full Automation. Existing agents don’t get it automatically — grant it deliberately, per agent.

​
What Neo does with it

Given the permission, an agent that identifies a message as spam can add a rule that matches that exact sender address and ignores it. Neo reads your existing rules first so it mirrors your tenant’s conventions and doesn’t add a duplicate, and it records the address it blocked on the ticket — an ignore rule is invisible until someone goes looking for it.
A rule that matches too broadly silently drops mail. Ignored email raises no ticket, so nothing appears in HaloPSA for a technician to notice — that’s the whole point of the feature, and also its risk.Neo blocks one exact sender address per rule and won’t ignore a whole customer domain or a free-mail domain (gmail.com, outlook.com) on its own. If you ask it to match more broadly in an agent’s custom instructions, understand that everything matching stops raising tickets until the rule is removed.

​
Unblocking a sender

Delete the rule in HaloPSA (Configuration → Email → Email Rules) and delivery resumes immediately. An agent with Delete enabled on the Email Rules group can also remove it on request.

​
If it isn’t working