Connected tools / GUIDE + WORKSHEET
Why your automations keep breaking
Trace a failed workflow from trigger to destination using a practical diagnostic, event log example, and recovery worksheet.
THE STARTING POINT
Follow one known business event from its trigger to the final record. Compare the expected result with what actually happened at each step. Check access, input data, mapping, timing, and destination responses before replaying anything. A successful run can still produce the wrong business outcome.
Write down the expected outcome
Choose a specific event rather than investigating 'the integration' as a whole. Record the source ID, time, expected destination record, and responsible owner. Establish whether the event never started, stopped visibly, or completed with incorrect data. Those cases point to different evidence and keep the investigation from becoming a tour of every settings screen.
Find the first point where reality differs
Compare the received input with the mapped output at each boundary. Check missing fields, changed option values, expired permissions, and date or currency transformations. Inspect the destination itself when a write times out: the write may have happened even though its response was lost. Keep sensitive customer data out of shared troubleshooting notes.
Recover safely, then stop the recurrence
Decide whether the event should be corrected, replayed, or handled manually. Before replaying, establish how the destination handles repeated writes. Repeated failures caused by invalid input need a correction, not endless retries. After the repair, test a normal event and the original failure case, then give ongoing monitoring a named owner.
WORKED EXAMPLE / ILLUSTRATIVE
A fictional lead-to-CRM trace
The failure appears at the destination write. Because no response arrived, the operator checks the CRM for the source ID before attempting another creation. This is an investigation example, not a tested recipe for a particular platform.
| Step | Observed result | Next check |
|---|---|---|
| Form trigger F-108 | Received | Required fields present |
| Field mapping | Service option translated | Destination accepts that option |
| Create contact | Response timed out | Search destination for F-108 |
| Owner notification | Not reached | Resume only after record is verified |
MAKE IT USEFUL
One-event diagnostic
Keep a trace small enough for another person to follow.
Your notes stay in this page and are not sent to Smithers. Download or copy them before leaving; refreshing clears them.
Before you put it to work
- Separate no-run, failed-run, and wrong-result cases.
- Check the destination before replaying writes.
- Avoid sharing credentials or customer records.
- Retest the cause, not just the happy path.
Retry behavior depends on the operation. Microsoft's retry guidance explains why repeated operations require care; a generic replay button is not a recovery plan.
Source notes
These references support the specific product or technical points discussed above. Checked September 24, 2026.
IF THIS LOOKS FAMILIAR
Your tools. Your particular mess.
The worksheet is yours to use. If the difficult part is making it work with the systems you already have, that's the kind of thing we help with.