Skip to main content
Ticket Triage can move tickets to the right queue or board. It also analyzes incoming tickets and fills in important details like priority, type, company, and contact information.

​
Quick start

1

Add to new ticket workflow

Add the action to workflows triggered by “New ticket created” to automatically categorize incoming tickets.
2

Choose fields to fill

Use the Add field to triage button and pick the fields you want completed - priority, type, company, contact, custom fields, and so on. The picker stays open, so you can add several in a row, and it only lists the fields your PSA supports.
3

Add custom instructions (optional)

Open a card’s Advanced settings and turn on Use your own instructions to give Neo specific guidance for that field.Next to the box’s label, Adjust with Neo opens the Neo Support chat for that one field. Say what the field should do and Neo drafts or changes the instructions, shows you the before and after, and applies it once you confirm. It writes that field alone and leaves the other cards untouched. Save the workflow first: Neo reads the saved version, so the button waits while you have unsaved edits.
4

Add update action

Follow with “Update Ticket Fields” to actually apply the suggested changes to your tickets.
Ticket Triage decides the field values; a later action writes them to your PSA. That action is Update Ticket Fields, or — for an Autotask tag — Add Ticket Tag in its default mode (its add tag to all tickets mode writes a fixed tag and applies nothing the triage decided). Leave the writer out and the workflow still reports what it decided. When the run decided at least one change, its result in the Executions message starts with “No change was written to the PSA”, naming the missing action. A run that changed nothing — every field left on its current value — has nothing to apply, so it gets no such line. The ticket note says the same, when an Add Ticket Note action follows Ticket Triage to post it.

​
Configuring the fields

Each field you add becomes its own card. The card names the field and says in one line what Neo does with it, so a whole triage setup reads top to bottom without opening anything.
  • Adding a field: use the Add field to triage button. A field you already added drops out of the list, so you cannot triage the same one twice.
  • Nothing to fill in: most fields work straight away on Neo’s defaults. Priority, Status, Type and the rest ask you nothing when you add them.
  • A custom field asks for two things: its name in your PSA, and where its options come from. Those sit directly on the card, because Neo cannot triage the field without them. If you pick Fixed List, type at least one option — an empty list gives Neo nothing to choose, so the workflow will not enable until you fill it in or pick a different source.
  • Tuning a field: everything optional lives under the card’s Advanced settings. You get only the settings that field actually has - the ones for other fields are not shown.
  • Reading a saved setup: each card shows a small tag for every setting you changed, for example Custom instructions or Limit the options: 3.
  • Changing a field: remove the card and add a new one for the field you want instead.
  • After triage: moving the ticket to a board or queue is a separate step at the bottom, not one of the fields.

​
How it works

The action:
  1. Analyzes ticket content - Reviews title, description, conversation history, and related information. Screenshots are read with a vision model and .eml and .pdf attachments are read as text, so a custom instruction can use what is in them (see Reading Images and Reading Email and PDF Attachments)
  2. Identifies key details - Extracts company, contact, and issue type information
  3. Applies smart categorization - Uses patterns from past tickets and your custom instructions
  4. Sets appropriate priority - Determines urgency based on impact and affected users
  5. Suggests field updates - Provides recommendations for all configured fields
The action processes fields in order: basic information such as company and contact first, then categorization, then priority.

​
Contacts that share a name

Some companies keep several contacts with the same name, for example one “General User” for each site. When Neo matches the contact by name and several contacts share that name, Neo chooses in this order:
  1. The ticket’s current contact, if Neo’s name search returns it as one of them. The search returns at most 100 contacts.
  2. On Halo, the one contact at the ticket’s site.
  3. On Halo, if the ticket’s site has none of them, the one contact at the client’s main site. This rule covers an alert that arrives on a catch-all client and that Neo then moves to the right client: the ticket’s site still belongs to the catch-all client.
On Halo, if none of these rules gives exactly one contact, Neo does not pick one of them, and the triage reasoning says how many contacts share the name. Neo uses rules 2 and 3 only when its name search returns fewer than 100 contacts, because a longer search can leave out contacts with the same name. On ConnectWise, Autotask, ServiceNow and Syncro, contacts have no site that Neo compares. If rule 1 does not apply, Neo takes the first match, and the triage reasoning says how many contacts share the name. To always get one specific contact, give it a unique name in your PSA and use that name in the contact field’s custom instructions.

​
Autotask contract options include exclusions

When triaging the contract field on Autotask, each contract option also tells Neo which work types that contract does not cover, so it can separate covered work from billable work instead of falling back to the company default:
This lets you write instructions like “never pick a contract whose exclusion list contains the ticket’s work type”. Neo reads this from your contracts’ exclusion sets and any per-contract exclusions you have configured in Autotask, and covers both at once. Nothing appears for a contract that has no exclusions configured, including one that points at an exclusion set you have left empty. In that case, Autotask itself holds no exclusion data for Neo to use. If a contract’s exclusions are missing from triage, check that its exclusion set actually lists work types in Autotask. Neo reads exclusions from its regular sync of your Autotask data.

​
Autotask list custom fields

Each option of an Autotask list UDF has a Display Value and a Stored Value. Autotask accepts a value on a ticket only when it matches a Stored Value. With Fixed List, Neo writes the option exactly as you typed it on the card. So type each option’s Stored Value, or give each list option in Autotask the same Stored Value as its Display Value. If Autotask rejects the value and the same ticket update writes other fields, Neo still writes those fields and skips only the rejected value, so the workflows that run after triage still start. Tags and secondary resources go through their own Autotask endpoints rather than the ticket update, so a triage that sets only a tag and a rejected list field leaves nothing in the update to write, and it stops. Neo also sends an Inbox message and an email that name the field and the rejected value.

​
Autotask fields a ticket’s state locks

Autotask refuses some field changes because of the ticket’s state. It keeps the Ticket Type of a ticket linked to a Problem or to other tickets, and it refuses a change of an existing ticket’s Ticket Category to RMA, because only a new ticket can get that category. It also refuses a Sub-Issue Type that is not one of the Issue Type’s sub-issue types in Autotask. When that happens, Neo writes the other fields of the update, leaves that one field as it was, and adds a warning to your Inbox that names the field and Autotask’s reason. If the ticket’s current Sub-Issue Type does not fit the new Issue Type either, Neo clears it, and the warning says so. When the locked field is the only change in the update, nothing is written.

​
Halo Email CC List

By default, triaging the Email CC List only adds addresses. Neo keeps every address that is already on the ticket. Turn on Let Neo clear this field to let Neo remove addresses too. Neo then keeps each address on the list unless your instructions exclude it, adds the ones your instructions ask for, and removes the rest. For example: “Remove our own staff (@contoso-msp.com) and vendor addresses from CC; keep the customer’s people.” If your instructions exclude every address on a ticket, Neo empties the list.
With clearing on, write which addresses to remove. A rule such as “Do not add anyone to CC” does not remove anyone, but a rule that excludes everyone empties the list on every ticket.
To write a removal to Halo, the Update Ticket Fields step also needs Allow Neo to remove field values on when Neo empties the whole list.

​
Syncro fields you can triage

On Syncro, the field picker offers: Neo only picks from the problem types your Syncro account already has. Add one in Syncro and triage can use it straight away: it reads the list from Syncro rather than waiting for a sync.
Syncro itself accepts any text in Problem Type, so it will not reject a value that is not on your list. Neo restricts itself to your list, which is what keeps the field consistent enough to report on.

​
Syncro tags

Syncro has no fixed tag list, so tell Neo what to apply in the field’s custom instructions. This is the same as tags on Autotask. A tag card sets Where the options come from to Free Text for you, which is what sends Neo to your instructions. Switch it to Fixed List and type the tags if you would rather Neo chose from a set list. Leave the list empty and the workflow will not enable, because an empty list gives Neo nothing to choose. Triaging a tag adds it. The ticket’s existing tags are left alone, and re-running the workflow will not add a duplicate. Turning on Let Neo clear this field lets Neo clear the tags instead, which removes all of them. Syncro’s API has no way to remove just one.
Triage Ticket Type before Custom Field in the same workflow. Neo already orders it that way: the type decides which custom fields a ticket can hold, so settling it first is what makes custom-field triage useful.

​
Syncro custom fields

Custom fields in Syncro belong to a ticket type, so a ticket can only hold the fields its type defines. Enter Custom field name on the card exactly as it appears in Syncro. Capitalisation does not have to match, but the name does. If the name matches no field on that ticket’s type, the workflow stops with an error listing the fields the ticket does have. That is deliberate: Syncro accepts an unrecognised field name without complaint and saves nothing, so a silent success would be worse. Updating one custom field leaves the ticket’s others untouched.

​
Setup

Company rules (optional): pin a memory on a company to give this action rules that apply only to that client. Pinned company memories are added to every run; there is nothing to switch on.

​
Common use cases

For the Description field (Autotask), the Summarize description toggle is on by default. Neo rewrites the body into a brief 2-5 sentence summary. Turn it off to use the field for targeted cleanup only: combine it with custom instructions to strip email-security banners, hyperlinks, or signatures while keeping the original wording and length intact. With the toggle off and no custom instructions, Neo leaves the description unchanged.
Write your due-date rules in the Due Date field’s custom instructions, in plain language. Neo reads them and computes the date. Rules you can write:
  • Lead times per priority: “Priority 1 = due in 1 day, Priority 2 = due in 3 days, Priority 3 = due in 5 days, Priority 4 = due in 14 days”.
  • Business days or business hours: “16 business hours”, “14 business days from the ticket creation date”. Business hours count only the open hours you set in Settings. Business days step over your non-working days and keep the time of day the starting point had. Both read the weekday in your Settings timezone.
  • A date the ticket states: “If the client provides a due date, use it” — or an offset from it: “set the due date to the day before the stated deadline”.
  • A clock time: “next business day at 8am”.
  • From the current due date: “move the due date forward 1 day”.
  • Weekend rule: “if the due date falls on a Saturday or Sunday, move it to the following Monday”.
  • Guards: “only when the status is Waiting Kit”, “do not change the due date for spam”.
Neo never invents the date arithmetic: your rule picks the starting point and the offset, and the date is computed in code from them. The same rule, the same starting point, and the same business hours and timezone in Settings always give the same date. Two starting points move on their own. A rule that counts from the current time re-triages to a later date, because the current time has moved. A deadline the ticket states in words — “by next Friday”, “the 2nd” — is read out of the ticket text against the date of the run, so a re-triage on another day can read it as another date; a deadline written as a calendar date does not move.
Add one sentence to the Due Date custom instructions: “if the due date falls on a Saturday or Sunday, move it to the following Monday”. This covers every due date — your own rules, the default priority lead times, and a stated weekend deadline alike. Neo judges the weekday in your Settings timezone and keeps the time of day. It works as your only due-date instruction too; the earlier Move weekend due dates to the following Monday toggle is retired in favor of the written rule.
Write the format in the title field’s custom instructions, for example “start the title with the company name, a colon and a brief description of the issue”. Neo applies it to every ticket, including RMM alerts and titles that already describe the issue well. The same goes for a content rule. Without a format or content rule, Neo leaves an RMM alert title or an already-clear title as it is. A “do not change the title” rule still wins over both.
Find the real company and contact for tickets logged against a generic “Unknown” company, from email signatures and ticket content.
Set the final service category or billing type from the work actually done, on tickets that are marked resolved.

​
Default priority instructions

The following instructions are used by default when determining ticket priority. You can override them in Ticket Triage action settings. Neo reads these instructions alongside your own custom instructions for the priority field, so a run can pick a priority from a line here (for example, Priority 3 for a quote request) on a ticket your rules do not cover. To stop that, turn on Replace Neo’s priority rules on the priority field. Your custom instructions then decide the priority alone, so they should also say what to do on every other ticket, for example: “In every other case, keep the current priority. Do not change it.”

​
Frequently asked questions

For every field it triages, Neo makes one of three decisions, and the triage note on the ticket reports each one:
  • Match found: Neo picked a value and updated the field. The note shows the predicted value and the reasoning.
  • Verified - left unchanged: Neo examined the field and actively confirmed the existing value matches the ticket. Nothing was written, on purpose: the field was already right.
  • No update applied - left unchanged: Neo could not make a decision for this field (for example, no options were available for the ticket’s company), so it left it untouched.
Every outcome is followed by the reasoning behind it, so a field left unchanged tells you why. The most common reason is one of your own custom instructions on that field. If a field consistently comes back unchanged when you expected an update, the reasoning line will name the rule that caused it.A run where many fields come back “verified” is a healthy sign: it means the ticket arrived mostly correct, not that triage stopped working. If a field has no value at all, Neo never reports it as “verified”: it either picks the best matching option or states that none of the available options fit.
This happens in Autotask when a ticket’s contract belongs to a different company than the ticket. Autotask rejects the whole update until the two match, so Neo replaces or clears the contract to let the rest of its updates land. Two situations lead there.Neo changes the company during triage. Here’s what’s happening behind the scenes:
  1. The ticket already has a contract attached from the original company
  2. Neo identifies the correct company during triage and attempts to update it
  3. Autotask prevents the company change because the existing contract belongs to the old company, not the new one
  4. Neo removes the old contract to allow the company change to proceed
  5. Neo applies the default contract for the newly assigned company
  6. If that company has no default contract, or Autotask rejects it too, Neo leaves the contract empty and applies the rest of its updates
A technician changes the company in Autotask while Neo is working on the ticket. Neo is not touching the company field here: its update fails because the contract still on the ticket belongs to the previous company. Neo re-reads the ticket to get its current company, then applies steps 5 and 6 above.This is an Autotask system limitation, not a Neo configuration issue. When a ticket has a contract attached, Autotask requires that any company change must use a contract associated with the new company.
To avoid the first situation, you can exclude the Company field from your Ticket Triage action configuration. However, this means tickets with incorrect company assignments won’t be automatically corrected. The second situation starts with a company change made in Autotask, so no Ticket Triage setting prevents it.