Troubleshooting (Insights Dashboards)

This page provides a consolidated view of known issues and fixes for the Insights Dashboards, covering configuration, data model, hierarchies, metrics, deployment, and platform dependencies.

Model Selection & Advanced Configuration

Issue

  • Dashboards open with the following Groovy errors or show no data at all.

  • Customers Overview / Customer Trends / Customer Performance dashboards fail right after changing the configuration model.

Error Messages

  • Cannot get property … on null object
    Missing tables
    

Likely Causes

  • The Advanced Configuration Option (InsightsDashboards_Model):

    • Is not configured.

    • Points to the Insights Configuration model that is not in a Ready status.

    • The Advanced Configuration Option file was missing in the package.

  • The Insights Configuration model chosen is still in the Draft workflow status, so aggregation tables are not created.

Resolution

  • Configure the Advanced Configuration Option (InsightsDashboards_Model)

  • Use the Insights Configuration model that is in the Ready status.
    info For more information see Set Advanced Configuration Option (Insights Dashboards).

  • If the Advanced Configuration Option (InsightsDashboards_Model) is empty, dashboards will auto‑pick the model object in this order:

    • Configured Model

    • Latest Approved

    • Latest Ready

  • Verify that at least one such model object exists.

  • If the Advanced Configuration Option is missing, redeploy/upgrade so the empty key is created.
    info For more information see Deploy Accelerator in PlatformManager (Insights Dashboards).

Additional Information

The model information portlet at the bottom of each dashboard shows the name and link of the model object currently used, to help confirm you are looking at the right data source.

Time Period & L12M / Over‑Time Charts

Issue

  • Over‑Time charts and YoY metrics do not match the Review Period or Time Period selected.

  • Customer Trends displays more than L12M or always uses a default 12‑month window regardless of filter.

Root Causes & Design Decisions

Resolution

  • For unexpected periods in Over‑Time charts or YoY metrics, verify:

    • The Review Period and Time Period inputs.

  • Educate users that L12M‑based tiles and YoY always work on a rolling 12‑month logic and can differ from arbitrary custom ranges.

Filters & Hierarchies (General Filter, Customer/Product Hierarchy)

Issue

  • General Filter has no effect in Revenue & Profit and Customer Overview dashboards.

  • Choosing null / empty value in the Customer Hierarchy causes errors like:

    SelectableExpression.equal(): Cannot invoke "Object.getClass()" because "" is null
    
  • Hierarchy pickers appear unsorted or confusing to users.

Resolution

  • The Insights Configuration model, combined Product hierarchy and Customer hierarchy must contain at least one non‑ID level. If only ID fields are used, saving configuration will fail so dashboards always have at least one meaningful hierarchy.

Errors from Library / API Changes & “Safe” Methods

Issue

  • Errors like No signature of method: ...generateResultMatrix() (ResultMatrixUtils), fillInEmptyMonths not found (DataUtils), or new “safe” methods causing dashboard failures.

  • Errors when calling ranking methods after method or library renames (e.g. ConfigManager rank methods).

Root Cause

  • Underlying shared libraries (Dashboards Library, ConfigManager, QueryAPI) evolved. Method names changed or new “safe” wrappers were introduced – while some dashboards still called old methods.

Resolution

  • Update dashboards to use the new method names and “safe” variants everywhere and remove references to deprecated utils (e.g. ConfiguratorMessageUtils remnants in Dashboard Selection tab).

  • Ensure your environment is on a version that includes these fixes. For custom forks, align with the current accelerator Git repo functions.

Data Model & Datamart Tables Configuration Pitfalls

Issue

  • Validation errors when Product/Customer hierarchy levels are mis‑configured or only ID fields are used.

  • Errors when attribute / hierarchy labels in the model reuse reserved names like “Customer Segment” or “Product Category”.

  • Quantity input too restrictive (only FieldType.QUANTITY allowed) rather than also accepting integer/number.

  • Waterfall configuration step fields not used by dashboards (Percent field), leading to confusion.

Key Model Features

  • Recalculation schedule for the configuration model allows regular updates (e.g. monthly) without manual runs. This uses a dedicated logic as a schedule target.
    info For more information see Set Up a Recalculation Schedule (Insights Dashboards).

  • Model now returns base currency from the transaction source so dashboards can format measures consistently.

  • Additional structure and labelling improvements to Datamart Tables (e.g. distinguishing Supporting versus Main Datamart Tables, adding fields to Customer Rolling Period, enforcing RollingPeriod = L12M).

Deployment, Dependencies & PlatformManager

Common Deployment Issues

Reference Documentation

Performance & QueryAPI (QAPI)

Issue

  • Heavy queries from Insights Dashboards impact cluster performance; need to compare QueryAPI versus DatamartContext approaches.

  • Some dashboard queries require UNION / UNION ALL, which historically were not supported by the QueryAPI yet.

Current State

  • QueryAPI has been extended to support UNION / UNION ALL operators, specifically to allow full migration of the Insights Dashboards queries to QueryAPI.

Migration & Co‑existence with Sales / Customer Insights (Legacy)

Question

Can I reuse my existing Sales/Customer Insights configuration when deploying Insights Dashboards?

Answer

No. Insights Dashboards is a standalone accelerator with its own configuration model and runtime. Insights Dashboards does not directly reuse or depend on existing Sales Insights (SI) or Customer Insights (CI) configuration.

Question

Why do L12M-based breakdowns in Customer Insights require L24M of aggregated data, and how is this handled in Insights Dashboards?

Answer

L12M metrics rarely use only the current 12 months. They typically compare the current L12M with the previous L12M to calculate trends, deltas, and year-over-year changes. To compute these correctly, the system must therefore have at least 24 months of aggregated data available, even if the application only displays “Last 12 Months.”

Customer Insights

The L12M breakdown in the Customer Insights is a single chart reading a generic aggregated table. To compute “current versus previous L12M” it needs L24M pre-aggregated and available.

Insights Dashboards

In the Insights Dashboards responsibilities are split. The Aggregated Transactions Datamart Table still follows the model’s configurable date range for general aggregation.
The Rolling Period Datamart Table are dedicated structures that internally compute L12M and prior-L12M metrics and expose them as fields. Dashboards read those fields directly. So the principle is the same, you always need information about both the current L12M and the previous L12M for YoY and trend calculations but:

  • In the Customer Insights, you must make sure your aggregated data covers L24M so the breakdown can do the math.

  • In Insights Dashboards, this requirement is encoded in the model design and Rolling Period Datamart Tables, so users interact with L12M-based dashboards while the underlying model handles the “previous period” metrics for them.