SolarWinds Platform – “All Alerts this Object can trigger” widget shows “An error has occurred”

4/8/2026 3:40 PM

4/8/2026 3:40 PM

When the alerting engine encounters an invalid dynamic condition, it cannot correctly evaluate which alerts apply to a given object. In these situations, the “All alerts this object can trigger” widget may display “An error has occurred” and show no alerts, even though relevant out-of-the-box or custom alerts exist.

By reviewing the Core Business Layer/alerting logs for Dynamic ExprTree errors and then querying the AlertConfigurations table with a targeted SQL query, you can identify misconfigured alerts. Temporarily disabling those alerts and then updating their trigger conditions or scope to use valid, consistent entities restores normal alert evaluation and resolves the widget issue. 

SolarWinds Observability

The issue occurs when a custom alert has a dynamic condition that is not valid. Common patterns include:

• A Node alert that tries to scope or filter using a field from another entity (for example, a SAM ApplicationAlert or ComponentAlert field), or

• A condition that effectively connects Field → Field rather than Field → Constant (or another valid combination).

When the alerting engine evaluates such a condition, it attempts to build and optimize an expression tree. Because the invalid condition joins incompatible fields, the engine fails with the “Field cannot be connected with existing Field” error, and the associated alert cannot be evaluated for matching objects. This also prevents the “All alerts this object can trigger” widget from listing those alerts.

Resolution

1. Review Core Business Layer / alerting logs

1. On the SolarWinds application server, open the Core Business Layer/alerting log:
   C:\ProgramData\SolarWinds\Logs\Orion\Core.BusinessLayer.log

2. Search for errors similar to:

   ExprTreeTransientRemover - (null) Expression <FieldPath> of type Field cannot be connected with existing Field
   

3. Note the exact field path from the error. Example (your environment will have its own value):

   Orion.APM.ApplicationAlert|ApplicationName|Integrations.Application.ApplicationAlert
   

   This string uniquely identifies the problematic part of the alert condition.

2. Use SQL to locate the misconfigured alerts

Important: Always back up the database and follow your change management procedures before running queries against the SolarWinds Platform database. The examples below are read‑only (SELECT only).

Run a query similar to the following against the SolarWindsOrion database:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT 
    AlertID,
    Name,
    ObjectType,
    Enabled
FROM AlertConfigurations
WHERE [Trigger] LIKE '%Orion.APM.ApplicationAlert|ApplicationName|Integrations.Application.ApplicationAlert%'
   OR [Reset]   LIKE '%Orion.APM.ApplicationAlert|ApplicationName|Integrations.Application.ApplicationAlert%';

 

Adjust the string inside LIKE to match the FieldPath observed in your log.

This query returns the alert IDs and names of any alerts whose Trigger or Reset conditions contain the problematic expression.

If you need more detail, you can run:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT 
    AlertID,
    Name,
    ObjectType,
    Enabled,
    [Trigger],
    [Reset]
FROM AlertConfigurations
WHERE AlertID IN (<results from previous query>);

Use this information to build a list of suspect alerts that need to be reviewed.

3. Disable or correct the identified alerts in the web console

1. In the SolarWinds web console, go to Settings → All Settings → Manage Alerts.

2. Search for each alert returned by the SQL query.

3. For each alert:

   • Either disable it if it is no longer required, or

   • Edit the alert and modify the trigger/scope conditions so they:

     • Use fields that are valid for the alert’s selected object type (for example, Node, Application, Component), and

     • Avoid invalid Field‑to‑Field combinations across different entities.

4. Save the changes and allow a few minutes for the next evaluation cycle.

5. Re‑check the “All alerts this object can trigger” widget and confirm that it populates correctly and that the Dynamic ExprTree error no longer appears in the Core Business Layer logs.

Once the misconfigured alerts are either disabled or corrected, the alerting service should function normally and the widget should show the alerts that each object can trigger.