Configure specific fields in correlations to influence issue grouping.
When custom detections (such as correlation rules) generate issues, those issues might not group automatically into related cases—even when they appear related from a user perspective.
Case grouping is determined by Cortex Cloud’s broader grouping and machine learning logic, which evaluates relationships, context, and shared artifacts across issues.
To optimize how Cortex Cloud groups issues triggered by correlations, you can map specific fields that influence grouping and prioritization.
Why field mapping matters in issue grouping
Cortex Cloud’s grouping and machine learning models use specific fields to construct grouping artifacts. These artifacts are then used to evaluate whether issues are related to each other or to an ongoing activity.
Not all fields influence grouping. To contribute effectively to grouping and prioritization, your correlation rules must supply one or more of the relevant fields in a supported format that Cortex Cloud can interpret. In addition, ensure that the mapped fields adhere to the correct field structure, and expected formatting requirements.
If these fields are missing, incorrectly mapped, or improperly formatted, Cortex Cloud may be unable to correlate related issues accurately. This can reduce grouping effectiveness and lead to unnecessary issue fragmentation across multiple cases.
Benefits of proper grouping configuration:
Correlate related custom issues into a single investigative workflow
Reduce issue and case fragmentation
Reduce over grouping of issues in cases
Improve investigation efficiency
Strengthen ML-based prioritization and correlation
Align custom detections with organizational context
Note
Field mapping does not guarantee grouping.
Cortex Cloud grouping uses machine learning and platform logic that evaluates confidence, context, relationships, and additional case signals. Field mapping helps influence grouping by contributing relevant artifacts, but final grouping decisions are determined by the platform’s overall grouping logic.
For more information about case grouping behavior, see Case grouping.
Configure field mapping to optimize grouping
To optimize grouping for issues generated by correlation rules, take the following steps:
Create or edit a correlation rule: Define the logic that triggers the issue based on your specific security requirements. For full instructions on creating correlation rules, see Create a correlation rule.
Map fields to influence grouping: Map your data to the fields for which you want to group (e.g., IP Artifact, Actor Artifact, User). The grouping engine uses these fields to identify commonalities across different issues.
For details of the specific fields that influence case grouping and their expected formatting requirements, see the table below.
Best practices
Use stable identifiers that are likely to remain consistent across related detections
Ensure field values match expected Cortex formats
Avoid overly broad mappings that may unintentionally group unrelated issues
Use the same mapping strategy across related custom rules when consistent grouping is desired
Field mapping reference for grouping artifacts
The following table presents the full set of fields that influence case grouping, their descriptions, and the expected formats.
Artifact type | Display name | Description (Purpose) | Field type | Format |
|---|---|---|---|---|
Actor Artifact | Initiator SHA256 | The process hash is a SHA256 identifier of the initiator executable, independent of name or path. | SHA256 |
|
Causality Artifact | CGO SHA256 | The SHA256 hash value of the Causality actor process that initiated the issue. | SHA256 |
|
Process Artifact | Target process SHA256 | The SHA256 hash value of the target process affected by the action, such as the injectee in injection. | SHA256 |
|
File Artifact | File SHA256 | The file hash artifact represents the SHA256 cryptographic hash of a file involved in the issue. This could be a file that was created, modified, or accessed. | SHA256 |
|
IP Artifact | Remote IP | This field represents the IP address associated with the network event. It typically refers to the remote/destination IP address that the endpoint communicated with. | IPv4 string (e.g., 192.168.1.1) |
|
IPv6 Artifact | Remote IPv6 | The IPv6 address artifact represents the 128-bit IP address in the newer Internet Protocol version 6 format. Like IPv4, it identifies network communication endpoints but uses a different addressing scheme. | IPv6 string (e.g., 2001:0db8::1) |
|
Domain Artifact | DNS Query Name | The domain artifact represents the fully qualified domain name (FQDN) or hostname that was accessed during the network event. This can come from DNS queries or HTTP/HTTPS requests. | DNS name string (e.g., example.com) |
|
Cmd Artifact | Initiator CMD Initiator Path Initiated By | The command line artifact captures the full command line used to execute a process, including all arguments and parameters. This is normalized (lowercased, trimmed, spaces standardized) to ensure consistent matching. | Raw string Initiator CMD - Minimum command line length of 5 without spaces and program image name Initiator Path - not empty Initiator By- not empty |
|
HOST | Host Name | The hostname artifact identifies the computer or device where the event occurred. This can be a NetBIOS name, DNS hostname, or in some cases a localn IP address (for firewall alerts without hostname). Hostnames are normalized and length-limited to ensure consistent matching. | String |
|
AGENT_ID | Agent ID | The Agent ID is a unique identifier assigned to each endpoint agent installed in the environment. This ID persists across hostname changes and reinstalls, making it a reliable identifier for tracking a specific device. | String |
|
USER | User name | The username artifact represents the user account that was active during the event. This is normalized to include both the username and domain (if applicable) in the format domain\username or username@domain. The system excludes common system accounts (SYSTEM, LOCAL SERVICE, etc.) and known service accounts to focus on actual user activity. Cloud identities have special handling for IAM users, service accounts, and federated identities. | String |
|
URL | Url | The URL associated with the alert. It typically refers to a web address observed in the activity that triggered the alert — such as a URL accessed by a user, contained in an email, or referenced by a network request. | String |
|
Examples
The correlation rule detects:
Impossible travel login
Multiple failed logins
Privileged login from new location
Map:
User name → (e.g. jsmith@company.com)
Result: Issues that share the same user are more likely to group into a single case.
The correlation rule detects:
Registry persistence
Suspicious scheduled task
New service installation
Map:
Host Name→ (e.g. DESKTOP-ABC123)Agent ID→ <Agent_ID>
Result: Issues on the same endpoint are more likely to group into a shared case for endpoint investigation.
The correlation rule detects:
Suspicious attachment
Spoofed sender
Credential harvesting link
Map:
DNS Query Name→ Domain (e.g malicious-site.com)
Result: Related phishing activity tied to the same domain may group more effectively.