How to use the Troubleshooting Decision Tree Generator.
Troubleshooting trees need observable conditions and safe recovery actions. Include a stop or escalation point when the evidence is insufficient.
Make the workflow fit your task.
Start with a visible symptom and branch on checks the user can actually perform. Each branch should lead to a bounded next action or an escalation with required evidence. Avoid loops and test the tree against a few known cases.
- What you provide
- Known symptoms, causes and approved fixes.
- What you get
- Branching diagnostic steps with escalation points.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Known import checks: error MISSING_HEADER identifies a required column; error INVALID_VALUE identifies a record and field. No other causes confirmed.
Completed example
Import failed ├─ MISSING_HEADER → inspect the named required column in the header; correct the file and retry. ├─ INVALID_VALUE → inspect the named record and field; correct according to the schema and retry. └─ Other or no code → stop guessing; escalate with the error text, time and a sanitized sample. If a corrected file still fails, capture the new error and escalate rather than repeating the same action indefinitely.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Should a troubleshooting tree ask users to guess the root cause?
No. Ask for observable errors, states or results so different users can follow the same path consistently.
Why does the tree keep sending the user back to the first step?
A branch may lack a resolution or escalation condition. Trace each path and add a clear stopping point.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑