Silent Integration Failure Triage Playbook

An integration that fails loudly is easy. The hard case fails quietly: records skipped with no error, or a connection that keeps switching itself off. Two causes dominate. Either the upstream provider silently renamed its payload fields and your parser now reads keys that no longer exist, or the credential lacks the scope the provider requires and the connection auto-disables. This playbook reads the live executions to compare what the provider actually returned against what your parser expects, checks token scope, and gives you a mitigation menu from least to most invasive.

Use this playbook when a working integration goes silent — processing fewer records than it should, or repeatedly disabling itself — without surfacing a clear error.

Typical triggers:

• An automation that used to process every record now skips some, and nothing in the run reports a failure. [1172]
• Output values arrive empty or null where the source clearly has data.
• A connection keeps turning itself off and has to be manually re-enabled. [851]
• The provider changed its API and your flow quietly stopped matching the new shape.

Classify before you touch anything. Silent data loss and a self-disabling connection have different blast radii.

The dividing line is whether records are being lost. A connection that disables itself is visible eventually; records dropped without an error stay invisible until someone audits the counts.

Name roles up front so escalation is not improvised.

• Integration on-call: runs this triage, owns the decision to pause the affected workflow.
• Credential owner: holds provider account access; can reissue a token with the required scope.
• Comms lead: owns messaging to the business owner whose data or forwarding is affected.

[ ] 1. Read the LIVE executions, not the workflow config. Open a
       real run and inspect the raw payload the provider returned
       against what the parser expects. [1172]
[ ] 2. Compare field NAMES key by key. If the parser reads keys
       that are absent from the live payload, the provider renamed
       them and you are getting nulls. [1172]
[ ] 3. Confirm the nulls become dropped records. Trace one skipped
       record end to end and confirm it was silently discarded, not
       errored. [1172]
[ ] 4. For a self-disabling connection, read the auth/error detail
       on the last disable event. [851]
[ ] 5. Check token SCOPE against the provider's requirement. A
       personal token often will not function without administrator-
       level access on the provider account. [851]
[ ] 6. Note whether the same rule or mapping runs in more than one
       workflow, so a fix stays consistent across all of them. [1172]

Match the symptom to the cause. Each branch points to one mitigation.

Apply the least invasive fix that resolves the diagnosed branch. Do not stack fixes you have not diagnosed.

1. Update the parser to the new field names. Read the live payload, map the parser to the current keys (for example, the renamed competitor_stock / competitor_price in place of the old in_stock / price), and revalidate processing so records stop dropping. [1172]
2. Reissue the credential with the required scope. Grant administrator-level access on the provider account, revalidate the connection, then review the mapping on live data and watch several runs to confirm it stays on and forwards reliably. [851]
3. Drive volatile business rules from a spreadsheet. Move exclusion lists out of the flow into a Google Sheet so the business edits them with no redeploy, and apply the same exclusion rule across every related workflow so they cannot diverge. [1172]
4. Add monitoring so silent drops surface. Instrument the skip path so dropped records raise a visible signal, turning the next silent failure into an alert. [1172]

Escalate to the credential owner or provider when:

• The required scope cannot be granted with the access you hold, and the connection keeps disabling. [851]
• The provider changed the payload with no notice and you need confirmation of the new contract. [1172]
• Dropped records have already fed a downstream decision.

Verify against live executions, never the config alone.

• Re-run a previously skipped record and confirm the parser now reads the correct fields and processes it. [1172]
• For a reissued credential, monitor several live runs and confirm the connection stays enabled and forwards reliably. [851]
• Confirm the same fix landed on every related workflow that shares the rule or mapping. [1172]

Capture, in the incident record:

• The raw live payload beside the parser's expected keys, showing the renamed fields. [1172]
• The auth/error detail from the disable event and the scope that fixed it. [851]
• The count of records skipped during the silent window, and the backfill result.

Business owner comms template:

We found that a connected service changed how it sends data, which caused some records to be skipped without an error. We have corrected the connection and are reprocessing the affected records. No action is needed on your side; we will confirm once the backfill is complete.

Run a retro and link it from the incident record. Lock in prevention:

• Monitoring on the skip path so silent drops become alerts. [1172]
• Volatile business rules driven from a spreadsheet, applied consistently across related workflows. [1172]
• Credentials issued with the scope the provider requires, so connections stop auto-disabling. [851]
• Verification against live executions, not config, after every provider change. [1172]