Skip to main content
Filters determine which tickets a workflow will process. You can use either Deterministic filters (i.e Status = New) or AI filters (i.e Ticket content is related to printer issue) to target the right tickets.

​
Deterministic filters

Deterministic filters match explicit criteria like queue, status, priority, and company. They are predictable and fast. Example below when trying to filter for all tickets that are from a company called Autotask Corporation and are in a New status.

​
AI filters

AI filters capture intent across inconsistent fields and text. They reduce noise and catch edge cases. Example below when trying to filter for all tickets that are related to a printer issue.

​
Reorder rules and groups

Every rule and every nested group has a drag handle (⋮⋮) on its left and Move up / Move down arrows on its right.
  • Arrows move the item one slot within its own group. This changes only how the filter reads; it never changes which tickets match, because rules inside one AND or OR group apply regardless of order.
  • Drag a rule or group by its handle and drop it on another rule to take that rule’s slot, or on a group’s header (the AND/OR selector) to move it into that group. Drop it on the top header to move it out of a nested group. Moving an item into or out of a group does change what the filter matches — a short notice confirms the destination, and the warnings under the filter refresh straight away. Click Verify Rules if you want to check the result against live tickets.

​
Where each filter runs

Filters are applied in two places, and the split affects how fast a scheduled workflow runs and how many credits it uses.
  • Your PSA applies most deterministic filters. Status, queue or team, ticket type, priority, company, and date rules are sent to the PSA as part of the search, so only matching tickets are ever fetched.
  • Neo applies the rest after fetching. Rules prefixed with [Extra] (such as # Time Entries count or Hours since ticket was created) and [AI] are calculated by Neo, because the PSA has no equivalent field. A few PSA fields also fall into this group where the PSA’s search API cannot express the comparison.
Both groups always run, so your results are correct either way. The difference is volume: a filter made only of [Extra] and [AI] rules fetches every ticket the PSA-side rules allow, then narrows.
For scheduled workflows, add at least one narrow PSA-side rule — a status, a team, or a date range such as # Days since Ticket was Created. This keeps the fetch small before the [Extra] and [AI] rules run.
The ticket count shown when you verify a workflow is measured before the [Extra] and [AI] rules are applied. If your filter relies on them, expect the workflow to process fewer tickets than the verification count suggests.

​
When a name appears more than once in your PSA

Some PSA fields let the same name exist several times. Autotask sub-issue types are the common case: each one belongs to a parent issue type, so a name like Problem can exist once under every issue type you have. Company and contact names repeat too, usually when an old record was archived and a new one created beside it. The dropdown shows one entry per name, so you cannot tell them apart there. A filter naming that value matches every entry that carries the name. If your PSA has eleven sub-issue types called Problem, a rule for Problem selects tickets under all eleven.
This is the same for is not and is not in list rules: the filter excludes every entry carrying the name, not just one of them.
To narrow it to a single entry, add a rule for its parent field next to it. Filtering on both Issue Type and Sub-Issue Type selects only the sub-issue type that sits under that issue type:
  • Issue Type is Hosting and Sub-Issue Type is Problem matches only the Problem that belongs to Hosting.
If a workflow selects more tickets than you expect on a field like sub-issue type, check your PSA for repeated names before changing the rest of the filter. Pairing the field with its parent is usually the fix.

​
Filter by who created or assigned a ticket (ConnectWise)

On ConnectWise you can scope a workflow by the person behind a ticket with two rules. Both show a member dropdown, so you can select one or more people with is in list or is not in list.
  • [Extra] Entered By — who created the ticket.
  • [Extra] Assigned By — who last set the ticket’s owner. Use this to pick up only the tickets a named dispatcher assigned. A ticket that was never assigned has no value, so it never matches an is in list rule.
Both are [Extra] rules, so Neo applies them after fetching. Pair them with a PSA-side rule (a board, a status, or a date range) on scheduled workflows to keep the fetch small. Assigned By also reads each ticket’s audit trail, which is one more ConnectWise request per ticket.
The dropdown lists your active ConnectWise members. That usually includes the accounts your integrations run as, so you can also select (or exclude) a connector or an automation user. If a name is missing — a deactivated member, or a label with no member record — match it with a contains rule instead.

​
Filter by priority (Halo)

Halo defines priorities per SLA, and each SLA numbers its own levels 1, 2, 3 and so on. The Priority ID dropdown lists every level of every SLA under the name Halo shows for it, so pick the name you see on the ticket in Halo.
  • A rule matches tickets whose own SLA calls their level by that name. Two SLAs that use the same name for a level match together, as in Halo’s own filters.
  • To narrow to one SLA, add an SLA ID rule next to the priority rule.
  • Ticket details and agent instructions show the priority under the ticket’s own SLA name too.

​
Filter by the end user’s email (Halo)

On Halo you can target tickets by the email address of the end user on the ticket. The rule is called End User Email, and it takes any text operator — is, is not, contains.
  • Use contains with a domain (@contoso.com) to select every ticket from one customer’s users.
  • Halo cannot filter on the address itself, so Neo applies this rule after fetching. Pair it with a PSA-side rule — a status, a team, or a date range — on scheduled workflows.
  • A ticket whose end user has no email address on record never matches an is or contains rule.

​
Run Now and your filters

When you click Run Now on a workflow and give it a ticket, Neo does not do PSA event matching — it starts that workflow directly on the ticket you chose. It does still evaluate that same workflow’s own Filter Ticket conditions first, through a read-only pass. If the ticket does not match the filter, the run is recorded as SKIPPED in Executions and no actions are taken. The Run Now dialog has a Bypass ‘Filter Ticket’ conditions switch. Turn it on to run the workflow on the chosen ticket even when the ticket does not match the filter — useful for testing a workflow against a specific ticket without changing the filter.
Run Now checks the filter of the workflow you are running. It is separate from how another agent hands off to a target with the Trigger or Schedule Workflow tool, which skips the target’s filter — see that tool’s page for the difference.

​
Building your filters using AI

We get that building filters can sometimes be a bit tricky. So to make this easier, you can get Neo to build your filters for you using the Generate Rules button. You’d specify, in natural language, what you want to filter for and Neo will build the filters for you.