Overview
Ticket Grouping controls when multiple finding instances are combined onto a single external ticket and when they are split across separate tickets. Nucleus uses the grouping you configure to determine the boundaries between tickets. Every instance that shares the same grouping values ends up on the same ticket. The grouping options available vary by connector.
This article explains:
How grouping works
The grouping options available and what enables them
How grouping behaves in ticketing automation rules vs. manual ticket creation
Differences between connectors
Common scenarios and ticket-count guidance
Connector Support
Custom grouping configuration is currently a Jira-only capability. On all other connectors (Azure DevOps, ServiceNow, and others), ticketing is always performed using Unique Finding grouping. The Group By picker on these connectors is displayed in read-only mode for transparency.
How Ticket Grouping Works
Ticket grouping is separate from the criteria that determine which findings match a rule. The rule's Vulnerability Criteria and Asset Criteria determine which finding instances are eligible to be ticketed. Group By does not filter or match findings; it only controls how the matched instances are distributed across tickets.
Once the set of matched instances is determined, Nucleus uses the Group By selections to partition them:
Instances that share the same value across every selected grouping are combined onto one ticket.
Instances that differ on any of the selected groupings are split onto separate tickets.
The number of tickets a rule produces depends on how many distinct values exist in the matched findings for the selected groupings. Grouping by Severity alone, for example, results in at most one ticket per severity level regardless of how many findings the rule matches. Adding additional groupings further subdivides the matched instances and can only maintain or increase the total ticket count, never reduce it.
Available Groupings
Grouping | Availability | Required Configuration |
|---|---|---|
Unique Finding | All connectors | None. Always available and enabled by default. |
Finding Instance | Jira only | Jira Instance-Level Ticketing organization setting |
Severity | Jira only | Dynamic Ticket Assignments organization setting |
CVSS | Jira only | Dynamic Ticket Assignments organization setting |
Instance Assignee | Jira only | Dynamic Ticket Assignments organization setting |
Source Scan Type | Jira only | Dynamic Ticket Assignments organization setting |
Organization Settings
Jira Instance-Level Ticketing and Dynamic Ticket Assignments are opt-in organization settings. To enable either setting, contact Nucleus Support or your Customer Service Representative.
Unique Finding
Groups all instances of the same vulnerability onto a single ticket.
This is the default grouping on every ticketing rule and the only grouping used for manual ticket creation.
When used alone, a ticketing automation rule will produce one ticket per unique vulnerability that matches the rule's criteria.
Finding Instance
Creates one ticket per finding instance, meaning one ticket per unique combination of vulnerability, asset, and, where applicable, port or protocol.
Finding Instance grouping is useful when each instance must be tracked, assigned, and remediated independently.
Dynamic Field Groupings
Severity, CVSS, Instance Assignee, and Source Scan Type are instance-level attributes. Their values can differ across instances of the same vulnerability.
Selecting any of these as a Group By tells Nucleus to split tickets by the distinct value of that field.
For a complete list of Dynamic Fields supported in ticket field mappings, see Ticketing Rules (Jira connector only).
Compound Grouping
Multiple groupings can be combined on a single rule.
When more than one Group By value is selected, Nucleus will split tickets on any distinct combination of the selected values.
For example, selecting both Instance Assignee and Severity will produce a separate ticket for each unique assignee-and-severity pair that matches the rule's criteria.
Grouping Broadens, Not Narrows
Adding additional groupings always produces the same number of tickets or more, never fewer. Each new grouping can only further divide the findings that would otherwise have shared a ticket.
Where Grouping Applies
Context | Group By Behavior |
|---|---|
Manual ticket creation from Vulnerabilities | Always grouped by Unique Finding. Tickets will split automatically by distinct value when an instance-level Dynamic Field is used in a ticket field, per |
Ticketing automation rules | Group By is required on creation. On Jira rules, any combination of supported groupings can be selected. On non-Jira rules, Group By |
Ticket Grouping in Automation Rules
Configuring Group By
Group By is configured on the Rule Details tab of the ticketing automation rule modal.
At least one grouping is required, and Unique Finding is selected by default.
Additional groupings can be added using the multi-select picker.
For step-by-step rule creation, see Creating Tickets Using Automation Rules.
Dynamic Fields Require a Matching Group By
If a rule populates any ticket field with an instance-level Dynamic Field such as:
{{finding.severity}}{{finding.cvss}}{{finding.instance.assignee}}{{finding.scan_type}}
the corresponding grouping must also be selected on the Rule Details tab.
Rules that use an instance-level Dynamic Field without the matching Group By cannot be saved.
Group By on Existing Rules
Group By is read-only on existing automation rules and cannot be changed after the rule is created.
To use a different grouping, create a new ticketing automation rule with the desired Group By configuration.
Ticket Grouping in Manual Ticket Creation
Manual ticket creation from the Vulnerabilities page always groups by Unique Finding.
There is no Group By picker presented when creating a ticket manually. All selected instances of a unique finding are combined onto the same ticket.
Instance-level Dynamic Fields used in ticket fields still split tickets automatically.
For example, manually creating a ticket with {{finding.severity}} mapped to the Jira Priority field will produce one ticket per distinct severity value across the selected instances within the finding, even though no Group By was chosen explicitly.
For an overview of manual ticket creation, see the Manual Ticket Creation article.
Ticket Count Guidance
The grouping you choose has a direct effect on the number of tickets a rule produces.
Examples
Group By | Effect on a Project with 1,000 Unique Findings |
|---|---|
Unique Finding | Up to 1,000 tickets, one per vulnerability |
Severity | Up to 4 tickets, one per severity (Critical, High, Medium, Low) |
Unique Finding and Instance Assignee | One ticket per vulnerability-and-assignee pair |
Instance Assignee and Severity | One ticket per assignee-and-severity pair |
When planning a rule, start with the broadest grouping that still gives each ticket to the right owner.
Narrower groupings increase ticket volume and administrative overhead in the downstream system.
Frequently Asked Questions
Why don't I see Finding Instance as a Group By option?
Finding Instance grouping is only available on Jira ticketing rules and requires the Jira Instance-Level Ticketing organization setting.
Contact Nucleus Support or your Customer Service Representative to have it enabled.
Why don't I see Severity, CVSS, Instance Assignee, or Source Scan Type as Group By options?
Dynamic Field grouping options are only available on Jira ticketing rules and require the Dynamic Ticket Assignments organization setting.
This is the same setting that enables Dynamic Fields in ticket field mappings.
Contact Nucleus Support or your Customer Service Representative to have it enabled.
Why is Group By read-only on my rule?
Group By is read-only in two cases:
The rule already exists. Group By cannot be modified after rule creation. To use a different grouping, create a new rule.
The rule uses a non-Jira connector. Non-Jira connectors currently support only Unique Finding grouping. Group By is displayed for transparency but cannot be modified.
Why can't I group by Asset?
Asset-level grouping is not currently supported as a Group By option. Note that Asset and Finding Instance are different:
An Asset is the system, service, or application being scanned (for example, a specific host, container image, or application).
A Finding Instance is a specific occurrence of a vulnerability on a single asset. A single asset can have many finding instances. Grouping by Finding Instance produces a separate ticket for each vulnerability on each asset, not a single ticket covering all vulnerabilities on one asset.
What happens when a grouping field has no value for some instances?
Instances with no value for a grouping field are grouped together into a single ticket. For example, if a rule groups by Instance Assignee and some matched findings have no assignee set, those unassigned findings are consolidated onto one ticket, separate from any tickets grouped by an assigned user.
Does Group By apply to manual ticket creation?
No.
Manual ticket creation always uses Unique Finding grouping and does not present a Group By picker.
Tickets created manually with an instance-level Dynamic Field in a ticket field will still split automatically by distinct value of that field.
How do connector defaults interact with Group By?
Group By is configured per automation rule, not on the connector. Connector defaults can include Dynamic Fields that prepopulate rule fields, but the rule author must still select the matching grouping on the Rule Details tab. For example, if the connector default sets the Assignee field to {{finding.instance.assignee}}, any new rule using that connector starts with that value populated but requires Instance Assignee to be added to Group By before the rule can be saved. Manual tickets are not affected because they always group by Unique Finding and split automatically by distinct Dynamic Field value.