Skip to main content

Known Limitations

The implementation team must consider these limitations before delivery.

The current implementation has the following important limitations:

  • The XML Build and XML Parse flows depend heavily on configuration quality. Incomplete or inconsistent mappings directly impact processing results.
  • When new risks, coverages, or related hierarchical entities are added, the parsing configuration must be updated manually. This requires an understanding of the overall product structure, parent-child relationships, and mapping dependencies.
  • As product structures grow, manual configuration maintenance becomes more time-consuming and more prone to missed updates or inconsistent mappings.
  • Automated configuration generation from product mapping definitions is not part of the current implementation. This can be considered a future enhancement to reduce manual effort and improve change management.
  • The reporting mart currently contains placeholder dimensions such as Dim_Customer, Dim_Agent, and Dim_Agency with unknown members only, unless a source integration is implemented.
  • Fact_PolicyPremium currently defaults some foreign keys, such as customer, agent, agency, and geography, to unknown when no upstream source resolution is available.
  • Dim_Policy is not configuration-driven. Structural changes to policy-level reporting attributes require engineering changes.
  • Dim_PremiumChangeBand is static and should be reviewed for each implementation because winner and loser thresholds may vary based on business context.
  • New risk and coverage reporting attributes require upstream availability in the extension or reporting source layer before they can flow correctly through views and into the semantic model.
  • The semantic model uses Import mode; therefore, refresh orchestration and schema-drift handling must be operationally reliable before go-live.