Skip to main content
It compares a new ticket with tickets from the configured history window and determines whether they are related.

​
How it works

When a new ticket arrives, this action:
  1. Searches recent history - looks back through tickets from the specified timeframe
  2. Compares similarities - analyzes ticket content, affected users, and company context
  3. Identifies patterns - determines if the new ticket matches recent issues
  4. Provides reasoning - explains why tickets are considered related or unique
The action can detect recurring issues across different scenarios: same company/same user, same company/different users, or similar technical problems across multiple companies.

​
Setup

Ticket to analyze: The action works with new tickets from your workflow trigger to check for recurring patterns. Comparison scope: Choose how broadly to search for similar tickets:
  • Same user only: Only compare with tickets from the same user at the same company
  • Company-wide: Compare with all tickets from the same company
  • All companies: Compare across all companies (useful for widespread technical issues)
Be careful with the all_companies comparison scope as it can consume more credits and may identify false positives across unrelated organizations. Start with company-specific scopes and expand gradually.
Search parameters:
  • Set how many days of ticket history to search (10 days by default)
  • Choose maximum number of recent tickets to analyze (10 by default - higher numbers provide more thorough analysis but consume more credits)
Neo compares the tickets in one call and splits a fixed token budget across them, so a long conversation or a long configuration list on any one ticket is trimmed to fit. That budget holds at most 49 tickets, so when the search finds more than 49 candidates, Neo analyzes the most recently updated 49. It names that number in its reasoning only when it drops candidates this way and it reports a recurring issue. Below 49 candidates the reasoning carries no such count, and a negative result shows only No reoccurring issue detected. Tuning by issue type:
  • Infrastructure outages: 3-5 day lookback, company-wide scope, higher comparison limits
  • User behavior patterns: 30-60 day lookback, same-user scope
  • Vendor or product issues: 10-14 day lookback, cross-company scope
Use 7 days for urgent issues and 30 days when you look for patterns. After testing, raise the maximum tickets to compare to 15-20 if you need more thorough analysis. Custom instructions (optional): Provide specific guidance on how to identify recurring issues in your environment. For example: “Consider backup jobs failing at the same step within a week as recurring issues, even if error messages vary slightly.” Auto-tagging (optional): Automatically add a tag to tickets identified as recurring issues for easy filtering and reporting.

​
Quick start

1

Add to intake workflow

Add this action right after ticket creation to catch recurring issues immediately.
2

Configure comparison scope

Choose how broadly to look for similar tickets:
  • Same user only: same_company_same_contact
  • Company-wide: same_company_all_contacts
  • Across all clients: all_companies
3

Set search parameters

Start with conservative settings: 10 days back, 10 tickets maximum.
4

Enable auto-tagging (optional)

Turn on add_tag_if_recurring to automatically tag repeat issues.
5

Add follow-up actions

Use the analysis results with a follow-up action:
  • “Assign Ticket to Technician” - route the ticket to the engineer who handled the original issue
  • “Notify Internal Team” - alert that technician or the team lead about the related tickets
  • “Add Ticket Note” - cross-reference the related tickets and document the pattern
  • “Update Ticket Fields” - apply consistent tags for reporting and filtering
6

Test and refine

Review results in Executions and adjust settings based on your environment.

​
Example scenarios

​
Printer outage detection

​
User training identification

​
Vendor issue tracking