Skip to main content

Find Similar Tickets

Finds tickets that are similar to the input ticket based on specified criteria. This helps in identifying related issues, potential duplicates, or recurring problems.

Why is it useful?

This action is valuable for quickly understanding the context of a new ticket by finding historically similar ones. It can aid in faster resolution by surfacing previous solutions, identifying if an issue is widespread for a company or contact, and preventing redundant work on duplicate tickets.

What It Does​

  • Searches for tickets based on predefined similarity types:
    • Open tickets for the same company.
    • Open tickets for the same contact.
    • Tickets with similar content for the same company (uses semantic search).
  • Filters the found tickets by how far back to look (days_to_look_back).
  • Optionally filters the results by specific PSA boards or queues.
  • Limits the number of returned similar tickets.
  • Provides a list of found similar tickets and a summary message.

How It Works​

  1. Input Data: The action takes a PsaTicket object as its primary input.
  2. Similarity Search:
    • For "Open tickets for same company" and "Open tickets for same contact" types, it queries the PSA for tickets matching the respective company ID or contact ID, along with a status indicating they are open (e.g., completedDate is null in Autotask, closedFlag is false in ConnectWise).
    • For "Tickets with similar content of the same company," it first generates an AI summary of the input ticket. Then, it performs a semantic vector search against a database of existing ticket summaries for the same company, looking for tickets with closely matching content based on the relevancy_threshold.
  3. Filtering:
    • Date Range: Filters out tickets created before the days_to_look_back period.
    • Board/Queue: If filter_by_board is true and board_or_queues are specified, it only keeps tickets belonging to those boards/queues.
  4. Post-processing:
    • Removes the input ticket itself from the search results.
    • Sorts the remaining tickets by their last updated date in descending order.
    • Limits the results to the similar_tickets_count.
  5. Output Structure: The action outputs a FindSimilarTicketsOutput object containing the list of found PsaTicket objects and messages for both MSP internal use and the Neo Dashboard.

Configuration Fields​

When you add the "Find Similar Tickets" action to a workflow, you'll configure the following:

ticket_similarity_type​

The type of similarity to look for. This determines the primary criteria for finding related tickets. Available options:

  • "Open tickets for same company"
  • "Open tickets for same contact"
  • "Tickets with similar content of the same company"

similar_tickets_count​

The maximum number of similar tickets to find and return. (default: 10)

relevancy_threshold​

The minimum similarity score (between 0 and 1) for a ticket to be considered relevant when ticket_similarity_type is "Tickets with similar content of the same company". A higher value means stricter similarity. (default: 0.40). This field is only applicable when ticket_similarity_type is "Tickets with similar content of the same company".

filter_by_board​

Set to True if you want to filter the similar tickets by specific PSA boards or queues. (default: False)

days_to_look_back​

The number of past days to consider when searching for similar tickets. For example, a value of 90 means Neo will only look at tickets created in the last 90 days. (default: 90)

board_or_queues​

(optional) If filter_by_board is True, specify the list of board or queue names to include in the search for similar tickets.

Output Fields​

This action makes the following information available to subsequent actions in the workflow:

similar_tickets​

A list of PsaTicket objects that were found to be similar to the input ticket, based on the configured criteria.

default_messages_for_msp​

A list of messages intended for MSP internal use (e.g., to be added as an internal ticket note). This usually contains a summary of the similar tickets found, including their PSA links, summaries, and last updated dates.

default_messages_for_dashboard​

A list of messages for display on the Neo Dashboard Event History, typically mirroring default_messages_for_msp.

Use Cases​

Identify Potential Duplicates​

  • Trigger: New ticket created.
  • Action: Find Similar Tickets
    • ticket_similarity_type: "Open tickets for same contact"
    • days_to_look_back: 7
  • Action: Add Ticket Note (using default_messages_for_msp from the previous action)
    • This helps technicians quickly see if the contact recently submitted a similar issue.
  • Trigger: New ticket created.
  • Action: Find Similar Tickets
    • ticket_similarity_type: "Tickets with similar content of the same company"
    • relevancy_threshold: 0.5
    • days_to_look_back: 180
  • Action: Add Ticket Note
    • Provides technicians with context from previously resolved similar issues within the same company, potentially speeding up diagnosis and resolution.

Check for Open Issues Before Escalation​

  • Workflow Step: Before an escalation action.
  • Action: Find Similar Tickets
    • ticket_similarity_type: "Open tickets for same company"
  • Action: Conditional Logic (e.g., If similar_tickets list is not empty and contains high-priority unresolved issues, route differently or add specific notes).

Best Practices​

  • Adjust relevancy_threshold carefully: When using "Tickets with similar content of the same company", a very low threshold might return too many irrelevant tickets, while a very high one might miss genuinely similar but slightly differently worded issues. Test and adjust based on your needs.
  • Use days_to_look_back appropriately: For rapidly changing environments or very common issues, a shorter period might be better. For less frequent, complex issues, a longer period could be beneficial.
  • Combine with other actions: Use the output (similar_tickets, default_messages_for_msp) in subsequent actions like Add Ticket Note, Notify Internal Team.
  • Review Event History: Check the Event History to see the messages generated and ensure the action is behaving as expected.