BriteData constraints and assumptions

BriteData was designed to enable you to create your own reports or customize existing ones through a web-based interface. BriteData includes smart defaults designed to simplify your choices.

• This tool is designed with a limited scope. You can’t build any type of report possible with BriteData.
  
  
• The BriteData engine relies on prepared data sets only. The prepared data sets are created overnight, this means the BriteData Builder can't use Current Date as a report extraction parameter. The  Current Date information won't show the data and/or changes to any Policies until the nightly jobs have run.
  
  
• Some data points in the Britecore system can't be added to a report via BriteData Builder.
  • For a list of data fields and data sets that can be used on a BriteData Builder Report:
    • Go to the Reports > Data Dictionary. The data points that can be used on the BriteData Builder reports are tagged Available in BriteData.
      
      
• BriteData groups all facts data first, and then adds dimensional columns to the report. If you don’t pick a data point from a facts data set, then Policy State will be the default data set used.
  
  
• Reports are generated based on policy revisions (using Revision Id) to give you a snapshot of a policy at a specific point in time, which impacts the data available. For example, If you wanted to pull a report with a list of all agencies, the resulting report will omit any agencies not directly connected to an instance of a revised policy.
  
  
• This also means you can’t generate reports that aren’t related to policy revisions. For instance, you can’t export a list of possible coverages since the base data set isn’t revision-based.
  
  
• While you can choose your data points and add rules to the results, BriteData makes all the behind-the-scenes decisions, such as which data set to use as the base, how to combine data from different sources into the report, and how to align the rows.
  
  
• You can generate duplicates of the data depending on how many revisions are in the policy. This is where rules become useful to group and present your data logically.
  
  
• You can generate blank records if the data you're pulling isn’t connected to a particular policy revision.
  
  
• You can’t pull item-level details on any quotes. The Quotes data set contains coverage-level details only.
  
  
• You can’t mix facts data from different time frames. There are four main fact data sets: Accounting, Claims, Premiums, and Items. You can’t pull data points from unrelated facts data sets with different time frames. Using multiple facts data sets can cause confusion in the report and/or cause the report to not run/complete or show the correct data. Currently, there is no way for the BriteData Builder tool to determine which set of data you want to pull the information from. Naming conventions are also the same for both DataPoints, which can make it even trickier to determine which one is being used, and also cause the tool to pull the wrong data point.
  
  
• You can’t perform date math or perform complex calculations based on other columns. BriteData can't create quantitative metrics for the future either. It can, however, give the basic data to pull from the system which you can export to Excel or other tools to provide quantitative predictions and metrics.
  
  
• There is no revision history for any report. This means that even the Data Team can't see what changes were previously made on a report if a report is saved with current updates. Therefore, to test or try something on a report before committing to it, it's always best to make a copy of the report being updated to make any necessary changes before removing anything from the original report.