Target records
Reviewed records storing weekly and year-to-date target values.
CASE STUDY · REPORTING + AUTOMATION
Untangling pipeline targets and rollup reporting
Pipeline dashboards depended on target records, workbook assumptions, report filters, and divisional rollups that no longer aligned cleanly. I traced the live logic, separated actual errors from intentional business exceptions, implemented the approved corrections, and verified the final behavior in production.
AreaReporting and automation
PlatformSalesforce Sales Cloud
WorkInvestigation, configuration, Apex, reporting, verification
Engagement typeInherited-system repair
ClientConfidential organization
Project summary
The work was part investigation, part repair, and part proof package.
An organization had pipeline reporting that looked like a dashboard problem on the surface. The real dependency chain was broader: workbook target assumptions fed Salesforce target records; those target records fed parent and child rollups; reports and filters determined actual-side scope; dashboards displayed the final values.
The safe path was to inspect live Salesforce behavior, compare it to source assumptions, identify mismatches that were actual errors, preserve exceptions that were intentional for the current year, and verify runtime behavior after approved changes.
Visual 1
Target and reporting architecture
Recreated from the original implementation with client data removed.
Workbook assumptions→Salesforce target records→Parent / child rollups→Division reports→Pipeline dashboards
The business situation
Leaders needed pipeline dashboards they could trust.
The reporting environment had grown around division, region, and office-level dashboards. Target values were maintained in Salesforce but were influenced by workbook assumptions and current-year business decisions.
The problem
One symptom, several possible causes.
- Target records could contain stale or inconsistent inputs.
- Rollup parents could include the wrong children.
- Reports could filter actuals differently than targets.
- Workbook formulas could contain current-year exceptions.
- Week logic could change calculated values without changing weekly goals.
Visual 2
Diagnostic decision flow
Recreated from the original implementation with client data removed.
Reported mismatch→Inspect Salesforce runtime→Compare source assumptions→Identify true error+Identify intentional exception→Apply approved correction→Verify
Why the problem was difficult
A technically clean hierarchy could have been the wrong answer.
Several parent records looked like they should equal the sum of their children. In some places, that was true. In others, the difference represented an approved current-year exception that should not be erased during cleanup.
That meant the repair needed evidence, not just configuration. Live Salesforce was the authoritative runtime; older workbooks and notes were evidence to reconcile, not instructions to follow blindly.
What I inspected
The investigation covered both the target side and the actual-reporting side.
Rollup relationships
Mapped which parents should roll up and which values needed to stay manual.
Reports and filters
Checked report definitions and runtime behavior supplying actual values.
Workbook assumptions
Compared Salesforce behavior to source assumptions behind the hierarchy.
Automation and formulas
Reviewed week logic, formula outputs, and recalculation automation.
Backups and rollback
Built the package around snapshots, forward files, rollback files, and verification artifacts.
Visual 3
Simplified hierarchy mockup
Recreated from the original implementation with client data removed.
Company
rollup parent
rollup parent
Region A
preserves exception
preserves exception
Region B
strict rollup
strict rollup
Office 1
Office 2
Office 3
Office 4
What I discovered
The mismatches fell into different buckets.
Not every difference was a bug.
- One target-side mismatch was a real error with an approved correction path.
- One scope change needed both target-side and actual-report-side alignment.
- Several lower-level differences were approved current-year exceptions.
- Automation needed hardening so config edits would not accidentally rewrite future target inputs.
Options and tradeoffs
The safest option was a pragmatic repair package.
The approved path was narrower and safer: fix the clear error, include the approved business scope change, use child-driven rollups only where the math tied out, preserve current-year manual exceptions, and leave documentation for the next admin.
What I changed
The implementation separated data repair, reporting repair, and durable automation.
I corrected the approved target-side error without changing unrelated records, week counts, or dashboard bindings. I aligned report scope where target scope changed. I promoted rollup fields, week-exclusion logic, permission support, configuration seeding, Apex automation, and layout visibility in controlled stages.
The implementation preserved approved manual exceptions while enabling clean parent-child automation where the math already tied out.
Visual 4
Verification panel
Recreated from the original implementation with client data removed.
✓Report filters verified
Source reports were checked after target-scope changes.
✓Rollup parents checked
Read-only audits compared parents against included children.
✓Runtime behavior confirmed
Dashboard and report behavior was verified after approved changes.
✓Restore test completed
A controlled bump-and-restore proved the rollup cascade.
✓Documentation delivered
Closeout notes and restart guardrails were left for support.
How I tested and verified it
Verification was built around runtime behavior, not just successful deploys.
I checked org identity before production work, captured backups and rollback files, ran targeted deploys and tests, verified runtime schema and field visibility, compared before/after values, checked week-field behavior, and used controlled bump-and-restore testing.
For reporting, I checked the report filters and runtime behavior that fed dashboard components, then documented which surfaces changed and which did not need updates.
Confirmed outcome
The reporting model was corrected, verified, and documented.
The approved production package corrected the target and reporting scope issues that needed repair, preserved current-year business exceptions that should not have been overwritten, and left the rollup layer in a verified state.
Exact private counts are available in the evidence package, but they are intentionally withheld from this draft until approved for publication.
Public-safe version A
No sensitive counts included
- Approved target-side corrections were implemented.
- Related report filters were checked and corrected where needed.
- Current-year manual exceptions were preserved.
- Rollup automation was verified with reversible runtime testing.
- Documentation and maintenance notes were delivered.
Visual 5
Sanitized rollout checklist excerpt
Recreated from the original implementation with client data removed.
01
Confirm production identity
Verify the org before any live query or write.
02
Snapshot target records
Save restore-oriented backups before changing values or configuration.
03
Separate true rollups from exceptions
Only turn on child-driven rollups where the approved child set ties out.
04
Apply the smallest approved correction
Change only the records, fields, and report filters in scope.
05
Verify runtime behavior
Check parent targets, report scope, dashboard behavior, and week-field stability.
06
Leave restart notes
Document what changed, what stayed manual, and how to verify the next update.
Documentation and maintenance notes
The handoff mattered because the model was intentionally mixed.
The final system had strict rollup parents in some places and manual exception parents in others. I documented that posture so future maintenance would not accidentally convert a preserved current-year exception into a strict child sum.
Maintenance notes emphasized inspecting live Salesforce, simulating rollup math before config changes, verifying report filters after scope changes, and keeping rollback-ready backups.
Lessons learned
The pattern applies to any inherited Salesforce reporting surface.
Related capabilities
This is the kind of Salesforce repair work I’m best suited for.
Final call to action
Have a Salesforce dashboard nobody fully trusts?
I can help inspect the live system, separate symptoms from root causes, repair the smallest safe issue, and leave the verification trail your next admin will need.