> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsoar-8-on-prem/8.14/configure-cortex-xsoar/incident-configuration/pre-process-rules.md). # Pre-process rules Pre-process rules enable you to perform certain actions on incidents as soon as they are ingested (after classification and mapping) but before the incident is created in Cortex XSOAR. These rules enable you to drop, deduplicate, link, or close incoming incidents based on specific criteria. For example link the incoming incident to an existing incident, or under preconfigured conditions, drop the incoming incident altogether. When creating pre-process rules you can test them on existing incidents to see how they perform. Creating a pre-process rule consists of a three-part process using the preprocess wizard. 1. Select the incident field and value you want the rule to apply. 2. Select the action to perform on the incident, such as link and drop. 3. Add the criteria to compare existing incidents with the new incident, including the time range and oldest and newest incidents. After you create a rule in the **Pre-Process Rules** tab, you can do the following: * View, edit, copy, or delete the pre-process rule. * Enable/disable the pre-process rule. {% hint style="info" %} ### Note Rules are executed in the order they appear (from top to bottom). You can drag and drop rules as required. Only one rule is applied per incident. {% endhint %}
Rule actions for pre-process rules The following table describes the rule action for pre-process rules. | Option | Description | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Link and close | Creates an entry in the Linked Incidents table of the existing incident to which you link, and closes the incoming incident. If an existing incident matching the defined criteria is not found, an incident is created for the incoming event. | | Close | Closes the incoming incident. The incident will be created, but the associated playbook doesn't run. | | Drop | Drops the incoming incident and no incident is created. Used for incidents that have low severity, no severity, or they have no value and don't need to be investigated. | | Drop and update | Drops the incoming event, and updates the Dropped Duplicate Incidents table of the existing incident that you define. In addition, a War Room entry is created. If an existing incident matching the defined criteria is not found, an incident is created for the incoming event. | | Link | Creates an entry in the Linked Incidents table of the existing incident to which you link. | | Run a script |

Select a script to run on the incoming incident.

Note

Pre-Process rules that use system-based scripts such as GetIncidentsByQuery, by default, are run according to the defined role (Limited User). For example, if the GetIncidentsByQuery script runs with the Limited User role, it also runs with the Limited User role in the Pre-Process rule. You can change the default by either detaching the script and updating the RunAs field such as DbotRole, or create a wrapper script with the required role set in the RunAs field. The wrapper script calls the system-based script. The system-based when called by the wrapper script runs with the role assigned to the wrapper script.

Pre-processing scripts can access sensitive incident data. As best practice, we recommend assigning a Role for the pre-processing script to allow only trusted users to edit it.

|
Create a pre-process rule Pre-processing rules enable you to perform certain actions on incidents as they are ingested into Cortex XSOAR. You can, for example, link an incoming incident to an existing incident, or under certain conditions, drop the incoming incident altogether. Before you begin, search for incidents that you want the pre-process rule to apply and click **Investigate**, so that those incidents are available for testing. 1. Select Settings & Info → Settings → Object Setup → Incidents → Pre-Process Rules → **New Rule**. 2. In the **Rule Name** field, type a name for the rule. Give a meaningful name that helps you identify what the rule does. This will be useful when viewing the list of rules. 3. In step 1 **Conditions for Incoming incident** to apply the rule for incidents, do the following: 1. Select a field and value. For example, if you want to apply the rule to a phishing incident type: | Field | Filter | Value | | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | | Type |

Equals (String)

Note

For more information about filters, see Filter considerations, categories, and built-in filters.

| Phishing | 2. Add an **AND** statement to your filter, if required. For example, if you are running a phishing awareness campaign, add **Email Subject** and in the value field, type the relevant text. 3. If you want an **OR** statement, click the **+** sign. For example, you may want the rule to apply to blocked or spam alerts.

Note

If you want to remove an ADD or OR statement, click the - sign.

4. In step 2 **Action**, select the action to take if the incoming incident matches the rule. 5. If relevant, complete section **3**. This section enables you to link or update an incoming event and drop or update the incident depending on the selected criteria. \[TABLE] 6. (*Optional*) In a remote repository environment, you can view the relevant dependencies to ensure that all necessary dependencies are propagated or pushed to the remote repository. 7. (*Optional*) To check that the rules, click **Test**. Testing is useful to check that you are receiving the desired results before putting a rule into production. We recommend you fetch data from an existing incident as a sample incident against which the rule can run. You can also manually enter JSON to use as a test sample or edit the JSON from an existing incident using the **Edit** button. 8. **Save** the rule.
Pre-process rules examples **Drop incidents** When you run a phishing awareness campaign and send training emails to your employees, you want your employees to report the emails but you don't want to investigate. In this example, we create a condition for incoming incidents with the email subject You've Won the Best Employee Award, and drop those incidents without linking them to another incident. ![](/files/BPeoyB8hEqQ8xHngJ8Cb) **Drop and update incidents** In this example, you want a pre-process rule to do the following: * Apply to incidents that are ingested from the Sample Incident Generator. * Drop incoming events and update the incident, if the name of the existing incident is identical to the incoming incident. You can add multiple conditionals to check for duplicates (not just the incident name) such as a Threat ID, incident ID, email, and host. 1. Create a pre-process rule. ![](/files/j8sJ3CdlIQ34AsbJ3IPV) 2. (Optional) Test the rule to ensure that it is working correctly. ![](/files/3A0iIMwuezqT3NnWel8W) 3. (Optional) Go to an incident and check the Context Data (Side panels). Review the `droppedCount` key (line 52). ![](/files/LQsxGf5wY1DICxScbxSC) **Drop incidents and drop and update existing incidents** Watch the following video to see how to drop blocked or spam incidents and drop and update existing incidents: [Preprocessing](https://www.youtube.com/watch?v=XC4M9oxN5AE).
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xsoar-8-on-prem/8.14/configure-cortex-xsoar/incident-configuration/pre-process-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.