> For the complete documentation index, see [llms.txt](https://docs.dropzone.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dropzone.ai/platform/settings/global-alert-project/creating-and-managing-rules.md). # Creating and Managing Rules Rules are the building block of Global Alert Filters. Each rule pairs a CEL expression (the condition an alert must meet) with an action that decides what happens to matching alerts. ## Creating a Rule From the Global Alert Filters page, click "New Rule" (or "Create your first rule" if you have not created one yet). Input the following details: * Name: a short, recognizable label for the rule * Description (optional): a note explaining what the rule is for. This will help in future analysis and troubleshooting * Sources: the list of alert sources this rule should apply to, e.g. Splunk, Crowdstrike, or QRadar. By default, rules apply to alerts from all sources * Tenants: the tenants you want to apply this rule to. Only available if your Dropzone environment has Multi-Tenancy. By default, rules apply to alerts from all tenants {% hint style="info" %} If a tenant is removed from your Multi-Tenant Map, any rule that was scoped only to that tenant is automatically disabled. Review and re-scope those rules before re-enabling them. {% endhint %} * Evaluation stage: whether to apply this rule pre- or post- enrichment * Filter Expression: a CEL expression to determine the alerts this rule should match. See [Writing CEL expressions](/platform/settings/global-alert-project/writing-cel-expressions.md) for more information * If rule matches: select the action to perform when the expression matches * "Include Alert" keeps the alert and pushes it to the investigation queue * "Skip Alert" suppresses the alert so it never reaches the investigation queue * Skip reason (optional): a short explanation to display whenever this rule skips an alert. These appear in the [Global Alert Filters Usage page](/platform/settings/global-alert-project/reviewing-filter-activity.md) and on the events attached to skipped alerts to improve review and analysis. Depending on your Global Default Rule settings, this may be required for all *Skip Alert* rules. You can test the expression against a sample alert directly in the editor before saving.

Example New Rule

## Filtering by Stage Between arriving and reaching your queue, an alert is enriched using context from your existing data sources and threat intelligence integrations. This allows Dropzone to fully build the picture an investigation needs. You may choose to run rules at both the pre- and post- enrichment stage. {% hint style="info" %} Pre-enrichment rules bypass enrichment entirely, potentially skipping the process. Enrichment is the most expensive part of processing an alert, in both time and cost. As such, this is one of the most direct controls you have on alert-processing cost. {% endhint %} ### Post-Enrichment The default is to filter at the post-enrichment stage. If the alert has been fully enriched, your rule can apply to alerts based on enrichment data, extracted entities, related alerts, and the normalized alert fields. Use this when the decision to investigate or drop depends on contextual information that Dropzone will need to fetch. {% hint style="info" %} Alerts that are deduplicated into an existing alert are not subject to post-enrichment filtering. Filtering applies to alerts heading for a new or re-opened investigation. {% endhint %} ### Pre-Enrichment Filtering at the pre-enrichment stage allows rules to apply based only on the alert source and raw payload. Use this when the raw alert information indicates that an alert can be dropped (e.g. if it includes a known-benign detection name, a scanner's own source IP, phishing-simulation traffic, etc). Pre-enrichment rule filtering has three constraints: * Rules can only skip alerts, not include them. The Global Default Rule's action does not apply at this stage * Tenant scoping is unavailable, because an alert's tenant is not resolved until enrichment runs * Before an alert is enriched, only the fields `alert.schema_key` and `alert.raw` exist ## Ordering Rules Rules are evaluated from top to bottom on the Global Alert Filters page. The first matching rule will be applied, and no rules below it are considered. As such, the order of your rules matters significantly. The Global Default Rule sits permanently at the bottom of the list and is always evaluated last. It cannot be reordered. You may reorder the rule list using arrow controls on the left of each rule. The new order will take effect immediately. Tips: * Put more specific rules above broader ones * Put "Include Alert" rules that carve out exceptions above the "Skip Alert" rules they should override * Group rules with similar sources and tenant scopes together, to make ordering easier * Group rules with pre- and post- enrichment stages together, to make ordering easier {% hint style="info" %} Reordering is disabled while you have filters applied to the rule list, as the list you see would not reflect true evaluation order. Clear your filters to re-enable the move controls. {% endhint %} ## Manage Existing Rules You may change or modify existing rules on the Global Alert Filters page. To do so, first locate the rule in question, then click the kebab on the right of the rule row. This will allow you to perform the following actions: * Edit: change any part of the rule, including its expression, action, stage, and scope * Enable/Disable: activate or deactivate a rule without deleting it. Disabled rules will stay in the "Configured" tab and keep their position, but are ignored during evaluation * Duplicate: create a duplicate of the rule, which you may use as a starting point to create a similar one * Archive: retire a rule you no longer need. The rule will stop being applied and move into the `Archived tab`. Archiving is reversible. You may return it to the `Configured tab` at any time in the `Archived tab` by clicking the "Restore" option