In the Alerts Grouping screen, you can configure how alerts will be grouped into cases.


In this part of the screen, you can set the following cross platform configurations for the grouping mechanism.

  • Max. alerts grouped into a Case: Define the maximum number of alerts to group together into one Case. Maximum number is 30.
  • Timeframe for grouping alerts (in hours): Choose the number of hours with which to group the alerts for the Case (0.5-24 hours with half hour increments supported). Note that this does NOT apply to the rules below which are grouped by Source Grouping Identifier.
  • Group entities and source grouping identifiers in the same case: When enabled, and there is a rule with “group by: source grouping identifier”, then if it doesn’t find other alerts with the same source grouping identifier, it will look for all cases in the system with common entities, and group alerts accordingly within the time frame.
    Note: Whether disabled / enabled, if there is a rule with group by: entity, it will look for all cases in the system with common entities (even if they were originally grouped by source grouping identifier)


In every Siemplify platform there is a fallback rule. This rule is there to ensure that even if there are no defined rules – or even if the rules defined don’t apply to an alert, there will always be a basic grouping mechanism used.
The rules will be checked in the following hierarchical order:

  1. Alert Type. For example, Phishing Alert
  2. Product. For example, Cyberreason EDR
  3. Data Source. For example, a SIEM such as Arcsight
  4. And if none of the above are matched – then the fallback rule will be used.

Create a rule

  1. Click on the Plus sign.
  2. In the Category section, choose between Alert Type, Data Source and Product.
    Note that the drop-down in each of the following fields will only be populated by alerts that have been ingested into the system already.
  3. In the Sub-category (or Alert Type) section, select the required options. Note that you can choose several options (multiple select).
  4. In the Group by section, select either Entities or Source Grouping Identifier. Note that if you group by Source Grouping Identifier (for use with Qradar for example) then there is no need to define grouping entities direction as it’s not meaningful.

  1. If you choose to use entities, then you will need to select a direction as well.

Edit the fallback Rule

The fallback rule can not be deleted but it can have two of its fields edited:

  • Group by (Choose between Entities or SourceGroupingIdentifier (relevant for alerts coming from QRadar Connector – identifier called “offense”.)
  • Grouping Entities (by directions) – relevant for entities only

For more information on Alert Grouping Rules, click here.


This screen also allows you to define the Alerts Overflow configuration. The default configuration is more than 50 alerts in 10 minutes. If you want to increase the default configuration, navigate to opt/siemplify/siemplify-server/bin/Scripting/Python SDK and edit the ConnectorsOverflow.config file.

Alerts Overflow mechanism was designed to prevent system overflow, when lots of alerts from the same environment, product and rule are occurring in a short period of time. For example, making sure repetitive attacks such as bruteforce or DDoS don’t flood the UI and db and the SOC can continue functioning as it should.
Once triggered, an Overflow case will be added to the case queue, with one alert indicating the environment, product and rule of the overflowing alert, and an Overflow tag.

  • Timeframe for grouping alerts (in hours) : Choose the number of preceding hours with which to group the overflow alerts for the Case. Note that is only applied to rules which contain entities only. |
  • Max. alerts grouped into a Case : Define the maximum number of overflow alerts to group together into one Case.  |

Need more help with this?
Click here to open a Support ticket

Thanks for your feedback.