--- title: Incident Correlation slug: neurons-for-itsm/admin-user-help/enu/latest/-UTg-incident-correlation docTags: createdAt: 2026-07-31T17:41:19.706Z --- **Role**: Administrator and Service Desk Analyst roles. **Platform**: SaaS only. **Minimum Version**: Ivanti Neurons for ITSM 2025.2. **Feature Eligibility**: Ivanti's AITSM capabilities are available to customers who have subscribed to Premium or Enterprise Premium license. To know your eligibility, reach out to your Ivanti Account Manager. Ivanti Neurons for ITSM leverages AI to streamline incident management through intelligent grouping of incidents into clusters. The Incident Correlation capability identifies patterns among new, incoming incidents, helping organizations detect major IT service issues quickly. The Incident Correlation Dashboard empowers incident managers to build a dashboard, view cluster severity, and manage incident clusters efficiently. Users can make a dashboard to monitor correlated incidents, link incidents or unlink incidents, and assign parent incidents. This advanced dashboard service enhances visibility and control, making my dashboard a central hub for proactive incident resolution. :::hint{type="info"} The **Incident Correlation Dashboard** is available out-of-the-box for all new customers. However, existing customers upgrading to version 2025.2 should set it up. ::: ## Enable Incident Correlation 1. Log in to Neurons for ITSM as an Administrator. 2. Go to the Configuration console, scroll to **AI Configuration Hub** and select it. 3. Set **Incident Correlation** to **Active** using the toggle button. ::Image[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/KMHCZdWvUNptcS5Wvxp65_incident-correlation-enable.png" position="flex-start" size="49" width="485" height="275" initialPath="images/Incident-Correlation-enable.png" githubPath="Admin-User/Content/AITSM/images/Incident-Correlation-enable.png" darkWidth="485" darkHeight="275" showCaption="false" indent="1"} ## Customize the Incident Correlation Capability 1. Click the **Configure** option beside the toggle button. :::Paragraph{indent="1"} The **Incident Correlation** page is displayed. ::: 2. Optionally, enable the **Enable Boundaries** option using the toggle button. This option allows you to define the criteria for grouping incoming incidents into clusters. :::hint{type="info" indent="1"} By default, this option is disabled, and the system clusters incidents only based on the similarity of the **Summary** fields. ::: 3. From the **Boundary Field** dropdown, select the incident record fields that you prefer to form a cluster. ::Image[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/jMTxuNDEo-iY7VRRwBABV_incident-correlation-boundary-whitelist.png" position="flex-start" size="80" width="920" height="874" initialPath="images/Incident-Correlation-boundary-whitelist.png" githubPath="Admin-User/Content/AITSM/images/Incident-Correlation-boundary-whitelist.png" darkWidth="920" darkHeight="874" showCaption="false" indent="1"} :::hint{type="info" indent="1"} - You can select up to six options from the dropdown. - By default, the system also considers the **Summary** field together with the other fields you select. ::: 4. Optionally, enable the **Enable Whitelist Filtering** option. :::Paragraph{indent="1"} This feature allows you to exclude incidents containing a specific keyword from forming clusters. This is especially useful for skipping less important incidents. For example, in a large organization, employees might frequently raise password reset incidents. Considering the minor priority of the incidents, administrators might not want these to form a cluster or appear in the Incident Correlation dashboard. By using the "password reset" keyword, the administrators can exclude related incidents from forming clusters and can be addressed separately. ::: 5. Enter the keyword in the **Whitelist Keywords** field. The system excludes incidents containing this keyword from forming clusters. - Use :inlineImage[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/cuyv_12fT8XpcbaciFu9J_add-icon-1.png" alt caption size="10" width="18" height="18"} to add additional fields. - Use :inlineImage[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/sIbdRbiWMtWMdnhmISDxM_delete-icon-1.png" alt caption size="10" width="18" height="18"} to delete a field. :::hint{type="info" indent="1"} - You can create maximum up to 10 keywords. - The keywords are not case-sensitive. ::: 6. Under **Correlation Mappings**, configure the field mappings to map the source or user-created field to the target field used by the Machine Learning service to cluster the Incidents. 7. Click **Save** to save the settings. ## Configure Incident Correlation Dashboard The Incident Correlation Dashboard is available to new customers from version 2025.2 by default. Existing customers have to set to it up. 1. From the Configuration console, select **Build** > **Page Layouts**. 2. Select the role you want to set it up for under **Roles** and click **Add Page Layout**. :::Paragraph{indent="1"} *Adding the Page Layout* ::: ::Image[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/K9OP5AzJ_-_ADz83pmaGy_setup-incident-correlation-dashboard.png" position="flex-start" size="80" width="1466" height="647" initialPath="images/Setup-Incident-Correlation-Dashboard.png" githubPath="Admin-User/Content/AITSM/images/Setup-Incident-Correlation-Dashboard.png" darkWidth="1466" darkHeight="647" showCaption="false" indent="1"} 3. Select **Incident Correlation**, provide necessary information and save. :::Paragraph{indent="1"} The **Incident Correlation Dashboard** is setup and the workspace is now available in the Service Desk console. ::: ## Working with Incident Correlation Dashboard To access the Incident Correlation Dashboard: - From the Service Desk console, click **More** > search for **Incident Correlation Dashboard** and open it. :::Paragraph{indent="1"} A list of clusters is displayed. You can open any cluster to view more information and make changes. ::: *Incident Correlation Dashboard* ::Image[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/VCS1JxyO_sGmG9ymACtX5_incident-correlation-dashboard.png" position="flex-start" size="80" width="1429" height="709" initialPath="images/Incident-Correlation-Dashboard.png" githubPath="Admin-User/Content/AITSM/images/Incident-Correlation-Dashboard.png" darkWidth="1429" darkHeight="709" showCaption="false"} **Points to Note:** - Administrator can add Incident Correlation Dashboard to any role such as Service Desk Manager or Service Desk Analyst. To do so, enable object-level permissions for the **Incident Cluster\[nrn\_IncidentCluster]** Business Object. This ensures the dashboard displays and functions correctly. - Also add the Incident Correlation tab in the Incident page to view correlated incidents and to navigate to the Dashboard. Refer to [Configuring Correlated tab](docId\:ASx2_bqaXnadmNI3akn40). ### Dashboard The Incident Correlation Dashboard has the following elements: - **Filter by** - Use this option to narrow down the dashboard by Avg priority, Cluster Status, or Range. - **Cluster Name** - Clickable; opens the **Cluster details** page where all the incidents in the cluster is displayed with options to link/unlink incidents and assign parent incident. - **Trends** - Dynamic graph with a visual representation of incident flow over time. It is updated every time the page is refreshed. The following are the color definitions: - **Green** - When incidents reported are in downward trend, that is if the incidents reported in the last hour is less than the previous hour. - **Red** - When incidents reported are in a rising trend, that is if the incidents reported in the last hour exceeds the previous hour. - **Created On** - Date the cluster is created. - **Avg. Priority** - Average priority of incidents in the cluster, determined from the individual impact of correlated incidents in the cluster. - **Category** - Category of the grouped incidents. - **Region** - Geographical region reporting the incidents. - **Incidents Reported** - Total number of incidents in the cluster. - **Linked Incidents** - Clickable; opens the **Cluster details** page for managing incidents. - **Parent Incident(s)** - Clickable; opens the **Cluster details** page. - **Cluster Status** - Current status of the cluster, with the following states: - **Not Started** - When the cluster created. - **In Progress** - When an action such as linking incidents or assigning parents is taken. - **Terminated** - When the cluster is auto-closed as result of all parent incidents resolved or closed. - **+Add incident** - Use this option to add incidents into a cluster. This option is available in the **Cluster details** page. - **Remove from cluster** - To remove an incident from a cluster, select the incident and click this option. This option is available in the **Cluster details** page. :::hint{type="info" indent="1"} Once you remove an incident from a cluster, you cannot add it back. ::: *Cluster details page* ::Image[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/FIq4mN1_Whm9YbtdTS_Qt_cluster-details-page.png" position="flex-start" size="80" width="1429" height="709" initialPath="images/Cluster-details-page.png" githubPath="Admin-User/Content/AITSM/images/Cluster-details-page.png" darkWidth="1429" darkHeight="709" showCaption="false"} ## Configuring the Correlated Incidents tab The **Correlated Incidents** tab is available in the Incident view page. It helps a Service Desk Analyst view the related incidents for resolving incidents faster. This tab is available for new customers from version 2025.2 by default. However, existing customers have the configure it. To configure the Correlated Incidents tab: 1. From the Configuration console, select **Build** > **Business Object** > **Incident** > **Layouts**. 2. Open the layout used for the role you want configure the tab. 3. From the **View in this layout** section, select **formView**. 4. **Click Add Child Panel with Relation**. 5. Enter `Correlated Incidents` as the tab name. 6. Select **Correlated Incidents** as the **Plugin**. 7. Select **IncidentClusterAssocIncident** in the **Relationship** column. :::Paragraph{indent="1"} *Correlated Incidents tab added in the formView page* ::: ::Image[]{src="https://api.archbee.com/api/optimize/parib0MC3hVoUNdfQdnac/1UM8asWCpXfdnQXiqkiOX_correlated-incidents-tab.png" position="flex-start" size="80" width="1908" height="980" initialPath="images/Correlated-Incidents-Tab.png" githubPath="Admin-User/Content/AITSM/images/Correlated-Incidents-Tab.png" darkWidth="1908" darkHeight="980" showCaption="false" indent="1"} 8. Save the changes. :::Paragraph{indent="1"} **Correlated Incidents** tab is now added to the Incident view page for the selected role. ::: ## Frequently Asked Questions :::ExpandableHeading ## Why is Incident ID available in boundary selection if each Incident ID is unique and may prevent incidents from clustering? Incident ID is available in boundary selection because, when the boundary feature was introduced, all fields used in the correlation process were included as boundary options. This allowed customers to choose which fields to prioritize for clustering. However, because each Incident ID is unique, using it as a boundary field places each incident in a separate group and may prevent meaningful clustering. ::: :::ExpandableHeading ## Why is Description available in boundary selection if it is an HTML field that may contain extensive text and screenshots? Description and other HTML fields are sanitized before the correlation process. During clustering, only the text content in these fields is considered. ::: :::ExpandableHeading ## Why is Incident Status available in boundary selection if incidents with different status values may not be clustered together and status values can change over time? When Incident Status is used as a boundary field, incidents with different status values may not be clustered together. If an incident's status changes, it is re-evaluated during the next correlation run and may move to a different cluster or no longer belong to its current cluster. ::: :::ExpandableHeading ## Are boundary fields used as a similarity check? A boundary field is not a similarity check. It acts as a scoping rule that limits clustering to incidents with the same boundary field value. Incidents with different boundary values are evaluated separately and cannot be grouped into the same cluster, regardless of content similarity. :::