The direct answer is to reconstruct the last known good run, list every change made since then, and test one plausible change at a time while recording expected and actual results. A useful change log turns “it stopped working” into a timeline of evidence: version, setting, owner, approval, test, outcome, and rollback.
Freeze the current state
Pause the affected automation if it can send messages, create records, move money, delete files, or repeat customer actions. Capture the error, timestamps, job or record identifiers, input count, account used, destination, and recent logs. Export configuration where supported, but do not copy passwords or tokens into the log.
Write the last known good run and the first known bad run. That interval defines the initial investigation window. If no one knows the last good state, choose a representative historical transaction and verify it against the destination record.
Build a complete change timeline
Include application updates, operating-system patches, permission changes, credential rotation, staff changes, schema or column edits, renamed folders, new filters, prompt or template revisions, vendor policy changes, and altered schedules. For each entry, record who requested it, why, when it was applied, the systems touched, approval, validation, and rollback reference.
NIST SP 800-128, security-focused configuration management guidance, describes configuration change control as formally requesting, recording, analyzing, testing, approving, implementing, and verifying changes. Even a small office workflow benefits from that sequence because hidden changes are easier to isolate when the baseline is documented.
Reproduce with safe data
Create a harmless test record that represents the failing case without using live customer, payroll, or financial data. Run it through the current configuration and record the failure point. Then compare a normal case, an edge case, and the smallest possible input. This separates a general outage from a data-specific defect.
Change only one factor at a time. If the credential was rotated and the destination folder was renamed on the same day, test them separately. Mark each hypothesis as confirmed, disproved, or not testable. A chronological coincidence is a lead, not proof.
Use the log to choose the repair
Prefer the smallest reversible correction: restore a permission, update one field mapping, renew a connector, or revert a documented setting. Record the repair as a new change rather than editing the old entry. Include the before value, after value, responsible person, and evidence.
NIST SP 800-128 states that change control is not complete until implementation is verified. After the repair, rerun the failed sample and at least one normal sample. Check the source, destination, notifications, logs, duplicate protections, and cleanup. Do not treat a green “run completed” badge as proof if the destination record is missing or wrong.
Close and improve
Document root cause, contributing changes, customer or business impact, records requiring correction, and prevention. Add a monitor for the failure signal and update the rollback instructions. If the problem was caused by an undocumented change, tighten who can change the workflow and require a short pre-change test.
A compact change log needs these fields: change ID, date, requester, implementer, reason, components, prior state, new state, approval, test case, result, rollback, and follow-up. Keep it with the workflow documentation, not in one person's private notes.
The goal is not bureaucracy. It is a reliable chain from symptom to change, from change to test, and from repair to verified outcome.
Sources
- SP 800-128: Guide for Security-Focused Configuration Management of Information Systems — National Institute of Standards and Technology, Oct. 10, 2019
- Configuration Change — National Institute of Standards and Technology