> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Letting Neo Manage Email Rules

> Enable Neo Agent to block repeat spam senders at source by managing HaloPSA inbound email rules

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.

<Info>
  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.
</Info>

## 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.

<Steps>
  <Step title="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.

    <Warning>
      `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](/integrations/psa/halopsa/creating-api-application) for the full scope list.
    </Warning>
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.

<Warning>
  **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.
</Warning>

## 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

| What you see                                                                                    | What it means                                                                                                                                                        |
| ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The agent says email rules aren't a supported area, or names the permission groups it does have | The **Email Rules** permission group isn't granted on that agent — step 2 above.                                                                                     |
| The agent reports a **403** from HaloPSA with no further detail                                 | The `admin` scope is missing from the HaloPSA API application — step 1 above. Reading rules will still work, which is why this shows up only on the first create.    |
| Neo can list rules but you expected it to add one unprompted                                    | Blocking is driven by the agent's instructions. Tell the agent when to block — for example, only for senders it has already classified as spam with high confidence. |

## Related

* [Creating an API Application](/integrations/psa/halopsa/creating-api-application) — full OAuth scope list for the HaloPSA integration
* [PSA API tool](/agents/tools/psa/psa-api) — how permission groups gate everything Neo does in your PSA
* [Technician-in-the-Loop](/core/technician-in-the-loop) — requiring approval before a write