Building a cleanup dashboard for stale ownership

The useful work was not just updating records. It was making the cleanup trustworthy.

An organization had open CRM records connected to inactive ownership, inactive related managers, and blank assignment fields. The reporting surface was supposed to help administrators find those exceptions, but some reports that looked valid in metadata failed when Salesforce Analytics tried to run them.

I treated the dashboard as both a reporting problem and a production-data-change problem: first repair the runtime logic, then add clearer exception visibility, then update only the safe subsets with backups, rollback files, and readback verification.

A dashboard existed, but the admin team could not rely on it as a cleanup front door.

The organization needed a practical way to find open records still connected to inactive users or missing key assignments. Those records affected ownership clarity, follow-up accountability, and the ability to separate “ready to fix” records from records that needed human review.

The initial dashboard had the right intent: make stale ownership visible. The problem was that intent alone did not make the source reports safe to run or safe to use for bulk updates.

The report definitions looked plausible, but Analytics runtime told a different story.

Several source reports behind the dashboard could be represented in metadata, but failed when run through the live reporting engine. That created a dangerous false sense of completion: a deployable report definition was not the same thing as a working admin surface.

For cleanup work, that distinction mattered. A broken report does not just create a bad chart; it can produce the wrong candidate list, hide blockers, or make admins distrust the entire dashboard.

The failure came from report-type and filter-field availability.

The strongest root-cause finding was that a helper-field or filter pattern could survive metadata handling and still disappear or become invalid at Analytics runtime if the field was not actually available on the live report type.

The fix was to stop relying on brittle helper-field assumptions. Where a standard runtime-safe field was available, I used it directly. Where related-user inactive checks needed a different shape, I moved to report structures that exposed the needed user fields at runtime.

The dashboard was rebuilt around exception counts that an admin could act on.

After the runtime repair, the dashboard presentation was redesigned from dense report components into metric-style surfaces. The goal was not to make a prettier chart; it was to make the next admin decision obvious: click into the exception bucket, review the underlying rows, and decide whether a safe rule existed.

Additional missing-assignment exception views were added so blank roles and routing fields stayed visible. When a flagged field was blank, the drill-through still needed a useful grouping strategy so the opened report remained triage-friendly.

A record was not considered safe just because it appeared on the dashboard.

Each cleanup pass needed a narrow rule. For example, a stale owner could be replaced only when a related active manager was present and the intended copy operation matched the rule. A missing manager could be filled only when the counterpart manager field was populated and active.

Rows without a valid replacement, rows connected to inactive related users, and rows that failed unrelated validation were preserved as review items. That is the part of the story I would rather emphasize publicly: unsafe candidates stayed visible.

The production updates only targeted rows that matched the safety rule.

The update files were scoped from preflight results, not from a broad dashboard total. Candidate rows were backed up, update payloads were prepared separately, and rollback files were preserved where the change type required them.

That meant the dashboard could still show unresolved issues after the safe updates. In this kind of work, a remaining exception count is not automatically a failure. Sometimes it is proof that the cleanup did not overreach.

The result was a safer cleanup surface, not a claim that every stale record disappeared.

The confirmed outcome was that broken runtime logic was repaired, exception visibility improved, safe candidates were separated from unsafe ones, controlled update files were used, and unresolved blockers remained visible.

That is the repeatable consulting pattern: make the system inspectable, make the safe work reversible, verify the live result, and document what still needs a human decision.

Some records were intentionally left out of the update path.

Records stayed out of the safe update set when they lacked a valid replacement user, depended on another inactive assignment, or failed unrelated validation. Those remaining rows were not hidden in the write path; they stayed visible as review items.

Metadata success is not enough for Salesforce reporting work.

• Report and dashboard changes need runtime checks, not just metadata validation.
• Cleanup dashboards should separate visibility from write-path approval.
• Safe subsets are more defensible than broad “fix everything” updates.
• Rollback and readback artifacts matter as much as the update payload.
• Remaining blockers should be documented, not buried.