Documentation Drift and Audit

Respond to a drift finding

Assess a drift finding and choose whether to investigate, accept runtime, or restore desired state.

Respond to drift as a change review, not as a race to remove an alert. First establish what changed, who owns the workflow, and whether the runtime behavior creates risk.

1. Preserve context

Record the finding ID, workflow, environment, expected version, observed time, and any related deployment or audit-event IDs. Avoid taking screenshots that expose customer data or credential material.

2. Assess impact

  • Is the workflow active or business critical?
  • Did triggers, destinations, data transformations, or credential references change?
  • Was the change expected and authorized?
  • Are executions failing or producing unexpected results?

3. Compare both states

Review the semantic comparison first, then the raw representation when necessary. Confirm that environment-specific metadata is not being mistaken for a logic change.

4. Choose the authoritative state

If the runtime change is correct, route it through review before making it the new desired state. If the approved version remains correct, use the authorized restore path. Escalate when ownership or impact is uncertain.

5. Validate and document

Confirm the expected version, connection status, workflow behavior, and audit result. Record the reason for the decision and any follow-up work.

Emergency changes

Follow your organization’s emergency-change procedure. An emergency can justify a faster decision, but it should not eliminate evidence capture, review, or later reconciliation.