Late-stageCybersecurity

Draining a daily data-quality dashboard by fixing what was creating the exceptions

All four exception reports moved from hand-fixed to automated

SalesforceMarketoLeanDataClayZoomInfoOutreach
Play leadEduardoSystems Consultant · LeanScale

The problem

Marketing ops ran a daily dashboard of exception reports in the CRM, saved filters that surface records the marketing-automation-to-CRM plumbing had left in a known-bad state.

The play

  1. 1
    Separate remediation from diagnosis, explicitly

    Every record on an exception report is two things at once: a record to fix, and evidence of an upstream automation gap. We split those jobs. The fix recipes were written down so the daily pass became deterministic instead of investigative, and the recurring patterns in what showed up became the root-cause backlog.

  2. 2
    Write down the field model, because conflating it is how records get mis-fixed

    Source and tier were tracked in three parallel field families: an original/first-touch set, a most-recent/latest-touch set, and a current-value tier field with a ratchet rule, it only ever increases, so it holds the highest tier the record has ever legitimately reached.

  3. 3
    Diagnose blank-source records by which side has data

    Open the record and check which family is populated. Most-recent populated and original blank means the first-touch stamp never fired, the common case, fixed by copying the correct first-touch value into the original-side fields. Neither populated means source was never stamped at all, which almost always means a human created the record.

  4. 4
    Read the 'created by' field correctly, it lies in both directions

    A human name in the created-by field does not reliably mean a person typed the record into the CRM. Records created through a data-provider integration carry the human's name rather than the integration user; records built inside the sales-engagement tool push through as that tool even though a human built them.

  5. 5
    Diagnose the tier-mismatch report as a race condition, not as bad data

    A lower-tier self-service form sits upstream of the demo request, you cannot request the demo through that path without completing the form first, so being top-tier on the original side is physically impossible there.

  6. 6
    Find the steps missing from the client's own documentation

    The internal runbook these fixes were supposed to follow had gone stale. Two live steps were missing from it entirely, the test-address pre-step and one of the original-side fields that needs its suffix stripped.

  7. 7
    Automate each report at its root cause

    Created-by user roles were aligned to their sourcing values so human-created records stamp correctly. An overnight flow now auto-corrects the tier race condition, because the fix was purely mechanical. A real-time flow corrects the tier chain when the last-response-date and most-recent-campaign-response fields misfire.

What it moved

All four exception reports moved from hand-fixed to automated

Overnight and real-time flows shipped for each.

A documented, testable field model. Original versus most-recent versus current tier written down with the ratchet rule and the created-by exceptions, so the next ops hire does not rediscover them by breaking records.

From a LeanScale case studyRead the full case study →

More from Eduardo