Create Pre-Process Rules for Incidents - Administrator Guide - 8 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Administrator Guide

Cortex XSOAR
Creation date
Last date published
Administrator Guide

Create pre-process rules to perform actions as incidents are ingested, such as linking new incidents to existing incidents, dropping duplicates, etc.

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.


Rules are applied in descending order, and only one rule is applied per incident.

  1. Select Settings & InfoSettingsObject SetupIncidentsPre-Process RulesNew 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. If you want the rule to apply to a specific incident, in the Conditions for Incoming incident section, click Add filter and set the incident field and value.

    For example, if you are running a phishing awareness campaign, you can create a rule for the email subject.

    You can add multiple conditions within a filter and add multiple filters. For more information about filters, see Filter Operators.

  4. In the Action section, from the drop-down list determine which action to take if the incoming incident matches the rule.

  5. Depending on the Action field, complete section 3.

    For example, in the Action field, if you select Drop and update, in section 3, complete the Update field.

    Section 3 enables you to link to an incoming event and update the incident depending on the selected filter. For information about the Action section and the fields in section 3, see Rule Actions for Pre-Process Rules.

  6. (Multi-Tenant) From the dropdown list, select the propagation label.

    When syncing from the Main Account to the tenant, the pre-processing rule is sent to the child tenant based on the propagation label.

  7. (Optional) In a remote repository or in a multi-tenant environment, you can view the relevant dependencies to ensure that all necessary dependencies are propagated or pushed to the remote repository.

  8. (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.

  9. (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.

  10. Save the rule.


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.