---
title: Prevent duplicate or orphaned records after running Application Vulnerability Response lookup rules
description: Take steps to prevent duplicate or orphan records resulting from matching \(configuration items \(CIs\) within the CMDB.
locale: en-US
canonical_url: https://www.servicenow.com/docs/r/australia/security-management/application-vulnerability-response/avm-ci-lookup-rules-impl-test.html
release: australia
product: Application Vulnerability Response
classification: application-vulnerability-response
topic_type: concept
last_updated: "2026-03-12"
reading_time_minutes: 1
breadcrumb: [Create a CI lookup rule, Identify applications in Application Vulnerability Response automatically, Use, Application Vulnerability Response, Unified Security Exposure Management, Security Operations]
---

# Prevent duplicate or orphaned records after running Application Vulnerability Response lookup rules

Take steps to prevent duplicate or orphan records resulting from matching \(configuration items \(CIs\) within the CMDB.

Importing vulnerability data can be taxing on an instance and performance issues with resources can occur if rules are not carefully constructed. The logic used to iterate through and perform matching within the CMDB can result in lengthy processing times. Thorough testing and debugging of processing scripts in the rules helps alleviate the potential of issues later in the process.

## Preventing duplicate or orphaned records

-   Use small subsets of data that are specific to the CI lookup rule being tested.
    -   Set all **lookup Rules**, other than the one being tested, to **Inactive**.
    -   Analyze the imported applications and configuration items \(CIs\) to ensure that you are observing the expected behavior and matching is occurring properly.
-   Review CI states such as **Retired**.
-   Remove Test Data. Once you begin to observe the correct or expected behavior in CI matching, start over. This can be done by:
    -   Deleting the data used for testing: \(see the **Deleting data from tables** section\)
        -   Scanned applications
        -   Application Vulnerable Items \(AVIs\)
    -   Manually rerun the integrations.

.

## Deleting data from tables

Sometimes you have imported data and realize something is wrong. If this happens in a development or performance environment, you could reclone from a better environment but, that isn’t always an option.

**Note:** Performing these actions requires advanced ServiceNow expertise.

There are four options for deleting data from tables:

-   Using **Delete All Records** on **Table Configuration**.
-   Configure the **Table Cleaner** by navigating to **Auto Flushes** \(sys\_auto\_flush.list\) and creating a new **Auto-flush** record.
-   Truncate the gs.truncateTable using a background script.

    **Note:** Never use **truncateTable** in a production environment. Consult your Support representative before executing large deletions in production or shared environments.

-   Create a request in HI to have the data deleted.