Overview

A Triage Policy decides how incoming tickets are classified, routed and titled. It is made of steps. Each step sets one field (or one related pair of fields) on the ticket, using AI, your own rules, or the text and history already in your helpdesk.

Where to find it: Admin Panel → Components → Triage → Policies

Prerequisites

• An active helpdesk integration (ConnectWise, Autotask, etc.) with synced ticket fields and picklist values.
• An AI integration configured under Admin Panel → Integrations → AI. This is only needed for the AI step types (Field, Field Pair and Text Generation).

How a Triage Run Works

Steps always run in the order below, no matter how they are listed on the policy. Steps of the same type run side by side.

Later steps see what earlier steps decided in the same run. For example, a security alert arrives filed under your own company:

1. Extract & Match reads "Contoso Corp" from the title and sets the company.
2. A Field step classifies the issue type as Security.
3. A Ticket Filter Rules step sees Security and routes the ticket to the SOC queue.
4. A Time Estimate step sees the SOC queue and writes a 2 hour estimate.
5. A Text Generation step builds the title "[Security] Contoso Corp - Suspicious login detected".

Each step's result is checked against its Minimum Confidence before it is written. A result below the threshold is not written, unless the step has a fallback value. The rule-based steps always report a confidence of 1.0.

Choosing a Step Type

Create the Policy

1. Navigate to Admin Panel → Components → Triage → Policies.
2. Click Create Policy (or click an existing policy to edit it).
3. Enter a Name for the policy. A unique key will be auto-generated.
4. Select a Prompt Strategy. This only affects the AI step types.
   • Baseline: No prompt enhancements. Uses default AI prompts only.
   • Keyword: Adds software detection and picklist value hints from ticket con
   • RAG: Learns from historical triage patterns to improve accuracy over time.
5. Toggle Active to enable the policy.
6. Save the policy.

Adding a Step

Every step type starts the same way:

1. On the policy view page, scroll to the Triage Steps section.
2. Click Create Step.
3. Choose a Step Type.
4. Choose the Target Field. These are your provider's field names (e.g., priority, issueType or companyID in Autotask).
5. Fill in the settings for that step type, described in the sections below.
6. Click Save.

AI Step Types

Field and Field Pair

These steps ask the AI to choose a picklist value for the ticket. Use Field for a single field such as Priority, and Field Pair for two related fields such as Issue Type and Sub-Issue Type.

• Minimum Confidence: The AI must meet this threshold for its choice to be written. For example, 0.70 means 70% confidence is required. Set it to 0 to always write.
• Fallback Value (Field only): A value to write when the step cannot classify the t-all you watch instead of being left alone.
• Fallback Fires On: When the fallback is used.
  • Below confidence threshold: only when the AI answered but did not meet Minimum Confidence.
  • Any time the step cannot classify: for any reason the step writes nothing.

A fallback value that is later deactivated or excluded is not written. The triage log records the reason.

Text Generation

Text Generation steps write or assemble a text field such as the ticket title. They run last, so they cther step.

• Minimum Confidence: As above.
• Additional Instructions: Extra context or formatting rules for the AI. Ticket content and available options are always included automatically.
• Formula: A template that controls exactly how the output is assembled. See Title

Title Formulas

Formulas let you define a template for the output instead of relying entirely on AI. A formula uses {{namespace:key}} tokens that are replaced with real values at triage time.

Note: Field names within each namespace use your helpdesk provider's native naming. Th field names. ConnectWise, HaloPSA, and other providers will have different field names.

A {{result:...}} token for a field set by a rule-based step shows:

• Ticket Filter Rules: the name of the ticket filter that matched, not the value written.
• Time Estimate: the duration in a readable form, such as "1h 30m".

Fallback Chains

Use the pipe character (|) to define fallbacks. If the first value is empty, the next one is tried. Segments without a colon are treated as literal text.

• {{result:priority|field:priority}}: Use the triage result, or fall back to the ticket's current priority if triage skipped it.
• {{result:priority|N/A}}: Use the triage result, or show "N/A" if empty.
• {{result:priority|field:priority|Unclassified}}: Try the result, then the field, then the literal "Unclassified".
• {{contact:firstName|Unknown}}: Use the contact's name, or "Unknown" if no contact is

Formula Examples

When the AI Runs

• If a formula contains {{ai:text}}, the AI runs first, then the formula wraps the AI o/li>
• If a formula does not contain {{ai:text}}, the AI is skipped entirely. This is faster and costs nothing.
• If no formula is set, the step is pure AI text generation (the default).
• A token that cannot be resolved (e.g., no contact linked to the ticket) renders as an empty string unless a fallback is defined.

Improving AI Accuracy with Hints

Hints give the AI additional context when it classifies tickets. They are added to the AI's instructions when triage runs, and only affect the AI step types. There are three levels of hints, each layering on top of the previous.

Account-Level Customer Context

Where to find it: Admin Panel → Components → Triage → Customer Context

These hints apply to every ticket triaged under your account. Use them to tell the AI about your busineassification preferences that apply across all customers.

Each hint has a Label (the category, e.g., "Industry", "Naming Convention") and a Body (the instruction). Examples:

Company-Level Context Overrides

Company hints apply to one customer company. When a ticket is linked to that company, its hints are used instead of any account-level hint with the same label. Account-level hints with other labels still apply.

For example, if you have an account-level hint labelled "Priority Rules" and a company-level hint for Ame label, the company version is used for ABLE Manufacturing tickets. All other customers still get theaccount-level version.

Picklist Field Hints

Account-level: Admin Panel → Components → Triage → Field Hints

Policy-level: Open a policy → Field Hints tab

These hints apply to individual picklist values. For each value in your helpdesk (e.g., each Priority option, each Issue Type), you can configure:

• AI Label: An alternate name the AI should use for this value, such as a descriptive name for a cryptic code. Account-level only.
• Hint: Additional context to help the AI understand when to choose this value (e.g involving servers, switches, or routers"). Account-level only.
• Excluded: Removes this value from the options entirely. Useful for deprecated or rarely used values. Available at both account level and policy level. Exclusions also apply to Inferred Field steps.

Account-level settings apply to all policies. Policy-level exclusions are added on top, so different policies can offer different picklist options.

Rule-Based Step Types (No AI)

These steps make no AI call and give the same answer every time for the same ticket. They do not use Mibe left at 0.

Extract & Match

An Extract & Match step reads a company name written in the ticket's title or description and sets the ticket's company to the company with that name.

The typical case is alert tickets from tools such as Blumira or ThreatLocker. These arrive filed under eal customer's name is in the title or description.

If you can say "when the text contains X, set the field to Y", use a Ticket Filter Rules step instead. Use Extract & Match when the value itself is in the text and there are too many possible values to write a rule for each one.

Note: Extract & Match currently supports company fields only.

Setup

1. Set the Target Field to the company field (e.g., companyID in Autotask).
2. Optionally, choose a saved ticket filter under Run Only When. The step then runs filter. For example, a filter of "Company is your own company" limits the step to misfiled alerttickets. Leave it empty to run the step on every ticket.
3. Under Patterns, add one or more patterns. For each pattern:
   • Look In: Title or Description.
   • Mode: Template (recommended) or Regex.
   • Template: The text that surrounds the company name, with {value} where the name appears.
   • Use the last occurrence on the line: Turn this on when the text before thnce on the line, such as an @ in an email address that comes before the one you want.
4. Optionally, add words to Also Ignore. These are dropped from the end of company names before matching. Inc, LLC, Ltd, Corp, Co and similar suffixes are always ignored.

Template Examples

A space next to {value} is optional, so @ {value} matches both "@Contoso" and "@ Contoso". Any other space in the template must be present in the ticket. That is why the hyphen inside "Wi-Fi" is not mistaken for the separator in the third example.

How Matching Works

• Patterns are tried in order. The first pattern that finds exactly one matching company wins.
• Names are compared after normalizing: letter case is ignored, "&" is treated as "and", a leadiling suffixes such as Inc or LLC are dropped. "The Contoso Corp" and "contoso" match the same company.
• Inactive companies can match. Companies deleted in your helpdesk cannot.
• If no company matches, or more than one does, nothing is written. The step never guesses.

Testing

The Test section in the step panel runs your current, unsaved settings without writing anything to your helpdesk. Under Test With, paste a sample title and description, or enter a ticket number, then click Run Test.

The test also shows the pattern that hit, the captured text, and the text as it was compared after normalizing. With a ticket number, it also shows the ticket's current company and whether the ticket passes Run Only When.

Ticket Filter Rules

A Ticket Filter Rules step is a lookup table. Each rule pairs a saved ticket filter with a value. Rulesom, and the first rule whose filter matches the ticket sets the field.

Use it for rules you can state in a sentence, such as "anything due within a day goes to Help Desk, everything else goes by territory".

Setup

1. Set the Target Field. It can be a picklist, text, number or yes/no field. Date fi
2. Under Ticket Filter Rules, click Add rule for each rule, an

   • Choose the Ticket Filter the rule matches on. You can create a new filter
   • Set the value to write when it matches.
3. Drag the rules into the order they should be checked.
4. Choose what happens When No Rule Matches:
   • Skip the field: nothing is written.
   • Write a value: the No-Match Value is written.
   • Fail the triage run: nothing is written and the run is marked failed. Use this when every li>

Example rules for a Queue field:

What a Rule Can and Cannot See

• A rule sees the values earlier steps decided in this run, including fallback values. If a Field step just changed the priority to Critical, a filter on priority sees Critical.
• A rule cannot see what another Ticket Filter Rules step in the same policy decided, because they r
• A rule cannot check the value the ticket arrived with.
• A filter condition on a linked record, such as the company's name, reads the company already on thp; Match picked in this run.

Each rule needs its own saved ticket filter. A filter that a rule uses cannot be deleted or deactivatedp>

Inferred Field

An Inferred Field step looks at how similar past tickets were set and picks the most common value. For example, to set the Contract field, it looks at past tickets for the same company and picks the contract used most often.

Setup

1. Set the Target Field. It can be a picklist field or a reference field such as a c
2. Choose the Filter Dimensions: the fields a past ticket must share with this ticket to be counted. For fields that are specific to a company, such as Contract, include company as a dimension. Otherwise the results are averaged across all customers and confidence will be low.
3. Set Min Sample Size: the step skips the ticket if fewer than this many past tickets match. The default is 20.
4. Set Lookback (days): only tickets from the last this-many days are counted. The de all history.
5. Set Minimum Confidence. Confidence here is the share of matching past tickets that had the winning value. For example, 0.70 means at least 70% of them did.
6. Optionally, set a Fallback Value and Fallback Fires On, as descrir.

How It Decides

• A dimension uses the value an earlier step decided in this run when there is one, such as the compset. Otherwise it uses the ticket's current value.
• Picklist values excluded in Field Hints are not counted.
• When two values are tied, the same one is always chosen.

Time Estimate

A Time Estimate step writes a duration from one of your time estimate policies to a number field on theurs.

The step checks your policy's rules against the values triage just decided for the ticket, not the values the ticket arrived with. A ticket that arrived with no type, and was then classified as a printer issue and routed to Service Desk, gets the printer estimate.

Note: Time Estimate steps are available for Autotask and ConnectWise only, and only on accounts with a single active helpdesk integration.

Setup

1. Set the Target Field. This is usually estimatedHours in Autotask or onnectWise.
2. If you chose any other number field, set the Unit to minutes or hours, whichever that field stores. A whole-number field can only take minutes. The unit is set automatically for Estimated Hours and Budget Hours.
3. Choose the Time Estimate Policy to read durations from.
4. Set Overwrite Existing Estimate (see below).

Which Duration Is Written

• If a rule in the time estimate policy matches the ticket, that rule's duration is written.
• If no rule matches, the policy's default duration is written.
• Rules are checked against the type, category and queue decided earlier in this run, including a queue set by a Ticket Filter Rules step.

Overwrite Existing Estimate

With Overwrite Existing Estimate off, the first estimate written to a ticket stays, even if the ticket ifferent duration would now apply.

A time estimate policy that a triage step uses cannot be deleted. Point the step at a different policy, or delete the step, first.

Checking the Results

Each triage run creates a triage log entry for the ticket. Open it to see what happened to each field:<

• Changes Applied lists each field that was written, with its value before and after. On a run that s heading reads Proposed Changes.
• Not Changed lists each field triage left alone, with its current value and the reason, such as low confidence, no rule matched or no company found.

Each change carries a source badge showing which kind of step set it:

Changes from rule-based steps and fallbacks are not counted in AI accuracy metrics.

Related Articles

• Triage Overview
• Configuring Triage Customer Context Hints