# Power BI ## Research Publication and Metrics Dashboard This guide describes the relationship between the **Research Publication and Metrics Reporting Pipeline** and the University of Kent **Research Publication and Metrics Dashboard** in Microsoft Power BI. The Python pipeline creates the data used by the dashboard. It does **not** automatically recreate the complete Power BI report, its visual layout, slicers or publishing configuration. The Power BI implementation should therefore be treated as a separate presentation layer built on top of the reproducible data-processing workflow. ## Data source The final Python stage: ```text build_university_report_dates.py ``` creates the Power BI-ready dataset: ```text output/university_report/powerbi_dataset.csv ``` This file is the hand-off point between the Python pipeline and Power BI. During validation of this release, the Power BI dataset contained: ```text 10,403 rows 83 columns ``` These figures describe the validation dataset and are not fixed expectations for future refreshes. ## Date fields prepared for Power BI Repository records can contain dates at different levels of precision and may not always contain a publication date. To support consistent reporting, the final Python stage creates a standard set of date fields: ```text Best_Date_Source Best_Date_Raw Best_Date Best_Month_Start Best_Year Best_Month Best_Date_Precision ``` The date-selection priority is: 1. Date Published 2. Date Published Online 3. Date Accepted 4. Date Submitted These fields are intended to give Power BI a consistent reporting date while preserving information about the original source and precision of the date. Users adapting the dashboard should use the generated date fields rather than assuming that every repository record contains a complete `Date Published` value. ## Dashboard structure The University of Kent Power BI implementation contains nine report pages: 1. Overview 2. Citations 3. External Collaboration 4. School View 5. UoA View 6. Internal Collaboration 7. Publishing Landscape 8. SDGs 9. Research Themes These pages reflect the University of Kent reporting implementation. Institutions adapting the workflow may choose different pages, visualisations or reporting structures. ## Filtering and slicers The dashboard uses interactive slicers to allow users to filter the reporting data. Important organisational views include: - School - REF Unit of Assessment (UoA) The School and UoA reporting structures are not necessarily mutually exclusive. An output associated with multiple organisational groups can therefore appear in more than one reporting view. Users should avoid interpreting summed School or UoA totals as an institutional total without accounting for this non-exclusive structure. ## School slicer labels The University of Kent dashboard uses compact School slicers positioned on the left-hand side of report pages. Full institutional School names were too long to display effectively within the available slicer width. Shortened School labels were therefore introduced for the Power BI presentation layer. The purpose of the shortened labels is usability and presentation. They should not be interpreted as replacements for the underlying institutional organisational information. Institutions adapting the dashboard may wish to create their own short display labels appropriate to their organisational structure. ## Power BI setup A new Power BI implementation can use `powerbi_dataset.csv` as its primary data source. A typical setup is: 1. Open Microsoft Power BI Desktop. 2. Import `powerbi_dataset.csv`. 3. Review the detected data types. 4. Confirm that the generated date fields have appropriate date/date-time types. 5. Configure any institution-specific display fields required for slicers. 6. Create the required report pages and visualisations. 7. Add School, UoA and other slicers as required. 8. Review visual interactions between slicers and charts. 9. Save the Power BI report. 10. Publish or share the report using the institution's approved Power BI environment. The exact visual design is intentionally not prescribed by the Python package. ## Refreshing the dashboard After completing a new run of the Python pipeline, the final refreshed dataset is: ```text output/university_report/powerbi_dataset.csv ``` The existing Power BI report can then be refreshed against the newly generated data. Before refreshing, confirm that: - the Python pipeline completed successfully - the Power BI dataset exists - its row count is plausible for the reporting period - the expected fields are present - the `Best_Date...` fields are present - no unexpected duplicate columns have appeared During validation of the KDR release, the final dataset contained no redundant `.1` duplicate columns. ## Schema stability Power BI reports can depend directly on column names. Changing or renaming fields in the Python outputs can therefore break: - visualisations - slicers - measures - transformations - report filters For this reason, changes to pipeline column names should be treated as potentially breaking changes and tested against the Power BI report before deployment. The KDR clean-up deliberately retained the meaningful reporting schema while removing six redundant `.1` duplicate columns that were verified to contain identical values to their corresponding primary columns. ## Organisational fields The dashboard uses organisational information derived from the repository and institutional lookup data. The University of Kent implementation includes School and UoA views, but these structures are institution-specific. Other institutions will need to map their own: - organisational units - School/Faculty structures - REF or other assessment groupings - display labels to the fields expected by their Power BI implementation. ## Metrics displayed in Power BI The final dataset can include information derived from: ### Institutional repository data Examples include: - publication information - output type - creators - organisational unit - journal/publisher information - DOI - funder and grant information - repository open access information - repository record links ### OpenAlex Examples include: - citation counts - FWCI - citation percentiles - top 1% and top 10% indicators - citations by year - subject information - collaboration information - SDG information - cited and citing journals - OpenAlex record links ### Scopus Examples include: - citation counts - document type - Scopus identifiers - CiteScore - SNIP - SJR - Scopus record links External-source coverage is not complete and differs between OpenAlex and Scopus. Blank external metric fields should not automatically be interpreted as repository metadata errors. ## Open access interpretation The reporting data contain repository open access information and may also contain derived or externally sourced fields. The University of Kent dashboard should be interpreted according to the definitions used by the reporting project rather than assuming that all forms of open access are interchangeable. Institutions adapting the workflow should review which open access field is appropriate for each visualisation. ## Visual interactions Power BI slicers and charts can be configured to interact with one another. When adapting or modifying the dashboard, check visual interactions after: - adding a slicer - replacing a field - changing a School/UoA field - renaming a column - duplicating a report page - changing the underlying dataset A visual can appear correct in isolation while responding incorrectly to a slicer if its interaction settings have changed. ## Publishing and sharing Publishing the Power BI report is separate from running the Python pipeline. The University of Kent implementation can be published through the institution's Power BI environment and made available through an appropriate institutional access route, including SharePoint where permitted. Publishing options, permissions, workspace availability and embedding behaviour depend on the institution's Microsoft 365 and Power BI configuration. The KDR package does not configure these services automatically. ## SharePoint embedding A published Power BI report can be embedded or linked from SharePoint where the institution's configuration permits it. The available width of a SharePoint page or web part can affect the presentation of an embedded dashboard. Full-screen/open-in-report options may provide a better experience where the embedded frame is constrained. SharePoint embedding should therefore be treated as a publishing/presentation choice rather than part of the reproducible Python pipeline. ## Reference PBIX files Power BI `.pbix` files used during development represent snapshots of the University of Kent dashboard at particular points in time. The dashboard evolved during development, including changes to School slicers and subsequent data refreshes. A PBIX file should therefore be treated as an **example/reference implementation**, not as the authoritative reproducible component of the KDR package unless a specific version is explicitly deposited and documented as such. The reproducible hand-off from the software pipeline is: ```text powerbi_dataset.csv ``` ## Adapting the dashboard Institutions adapting the workflow should expect to modify the Power BI layer. Likely adaptations include: - changing organisational slicers - changing short display labels - modifying page names - adding/removing visuals - changing report-level filters - adapting date presentation - modifying institutional branding - changing publishing and access arrangements These changes do not necessarily require changes to the underlying Python pipeline. ## Validation The Power BI data-generation stage was included in the end-to-end validation of this KDR release. The validation run confirmed that: - `powerbi_dataset.csv` was created successfully - the dataset retained all 10,403 final reporting rows - all seven expected `Best_Date...` fields were present - no redundant `.1` duplicate columns were present - the University-level summary workbook and visual outputs were generated The visual Power BI report remains an institution-specific implementation built on the validated dataset. ## Relationship to other documentation For installation and environment setup, see: ```text INSTALLATION.md ``` For the full eight-stage data-processing workflow, see: ```text PIPELINE_WORKFLOW.md ``` For methodological and technical caveats, see: ```text KNOWN_LIMITATIONS.md ```