> 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/xsoar-6-administrator-guide/6.14/customize-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/pre-process-rules/create-pre-process-rules-for-incidents.md).
# Create Pre-Process Rules for Incidents
Create Cortex XSOAR 6.14 pre-process rules for incidents.
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.
{% hint style="info" %}
### Note
Rules are applied in descending order, and only one rule is applied per incident.
{% endhint %}
1. Select Settings → OBJECTS 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. 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](/xsoar-6-administrator-guide/6.14/customize-cortex-xsoar/customize-and-configure-cortex-xsoar/playbooks/filters-and-transformers.md#UUID-3e99fa07-8af3-15bb-6f28-08f294320a8b).
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](/xsoar-6-administrator-guide/6.14/customize-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/pre-process-rules/create-pre-process-rules-for-incidents/rule-actions-for-pre-process-rules.md).
6. (Multi-tenant) From the dropdown list, select the [propagation label](/cortex-xsoar-6-multi-tenant-guides/6.14/configure-multi-tenant/manage-content/add-propagation-labels-to-content.md). When syncing from the main account to the tenant, the pre-processing rule is sent to the 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) To check that the rules are effective and efficient, 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.
9. Click **Save**.
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.
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.
2. (Optional) Go to an incident and check the Context Data.
You can see that 43,222 duplicate incidents have been dropped, as seen in the original incident.
In the incident table, you can also see the number of dropped incidents.
In the dashboard:
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.14/customize-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/pre-process-rules/create-pre-process-rules-for-incidents.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.