Close the fleet gap on the Data Quality dashboard, and record why the reports are unbounded - #4
Merged
Conversation
… reports are unbounded The Orphans column watched the stationary side only: Orphaned Carbon Footprints and Orphaned Stationary Energy Uses were on the dashboard, while Orphaned Fleet Footprints and Orphaned Vehicle Energy Uses existed as reports and appeared nowhere. Both are now components, so the column covers what the left and middle columns already do for gaps. Fleet data quality was going unwatched. The rest of this is a decision written down rather than a change. Fifteen of the 21 reports have no filter and all 21 leave the standard date filter unbounded, so each reads its whole object on every run. That looks like an oversight and is not one. The only date column these objects offer is CreatedDate, and the business axis is ReportingYear: a footprint *for* 2024 is routinely entered in 2026 during the disclosure cycle. Bounding on CreatedDate would drop records that belong in the answer — faster and wrong, which is the worse failure for anything feeding a disclosure. Bounding on ReportingYear is the right fix and the choice of years is a disclosure question, so the README now says so and leaves it to whoever deploys this. Two related shapes are deliberate for the same reason, and are documented rather than "corrected": the six tabular reports have no row limit because they are worklists meant to be worked through, and the summary reports keep details on because the same report is read as a dashboard chart and as the list of assets to go and fix. Considered and rejected: three report types are referenced by no report (Vehicle_Assets_with_Carbon_Footprints, Footprints_with_Energy_Uses, Vehicle_Footprints_with_Energy_Uses). In a repository people fork to build their own reports, a report type with no report is a starting point, not an orphan. XML well-formedness (53 files) and `sf project convert source` both pass.
…rtable Found by doing it. A retrieve stamps every dashboard with <owner> and <runningUser> carrying the retrieving user's address, whatever the source said, and even for a LoggedInUser dashboard where the running user decides nothing. Committing that breaks the package for everyone else — the username does not exist in their org, so the deploy fails on a user it cannot resolve — and puts a personal email address into a public repository, twice per dashboard. The committed dashboards carry dashboardType and neither of those elements; that omission is the portable form and it is load-bearing. The note gives the grep to run before committing any dashboard retrieve, and says plainly that throwing the retrieve away is usually the right move. Also recorded, since the same round trip produced them: the reports come back with <params>co=1</params>, <showGrandTotal> and <showSubTotals> added, which change nothing; and the dashboards come back with <expandOthers> flipped to false and <showTotal> dropped. Those two do nothing on a Bar component, which is worth knowing when writing a new one — but not worth a two-hundred-line reformat to discover.
mshresponse
marked this pull request as ready for review
September 8, 2026 11:03
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while running an org-health scan against the
nzcorg and then checking the findings against this repository's source.One real gap
The Data Quality dashboard watched the stationary side only. Its Orphans column carried
Orphaned_Carbon_FootprintsandOrphaned_Stationary_Energy_Uses.Orphaned_Fleet_FootprintsandOrphaned_Vehicle_Energy_Usesexisted as reports and appeared on no dashboard at all — so fleet data quality was going unwatched while the stationary equivalent was monitored.Both are now components in that column, which brings it in line with what the left and middle columns already do for gaps.
The rest is a decision written down, not a change
Fifteen of the 21 reports carry no filter, and all 21 leave the standard date filter unbounded, so each reads its whole object on every run. That reads like an oversight and isn't one:
The only date column these objects offer is
CreatedDate, and the business axis isReportingYear. The two do not agree — a footprint for 2024 is routinely entered in 2026, during the disclosure cycle. Bounding onCreatedDatewould drop records that belong in the answer: faster and wrong, which is the worse of the two failures for anything feeding a disclosure.Bounding on
ReportingYearis the right fix, and which years to keep is a question about disclosure obligations rather than about Salesforce. The README now explains the trade-off and leaves the choice to whoever deploys it.Two related shapes are documented for the same reason rather than "corrected":
Considered and rejected
Three report types are referenced by no report —
Vehicle_Assets_with_Carbon_Footprints,Footprints_with_Energy_Uses,Vehicle_Footprints_with_Energy_Uses. In a repository people fork to build their own reports, a report type with no report is a starting point rather than an orphan.Verification
sf project convert source— passes.Not deployed to an org from this branch.
🤖 Generated with Claude Code
https://claude.ai/code/session_01XsipTUqX7dcQDkvUkaFCuC
Generated by Claude Code