Understanding Run Results and Proof Packs
Use Recent Runs to audit what TEDI did, read step messages, retry failures, and open proof packs. This article covers the statuses operators see every day.
Open Recent Runs
- In the left sidebar, select Recent Runs.
- Or from Command Center, select View all under Recent automation runs, or Review runs when runs need attention.
Expected outcome: A list of runs with playbook name, goal text, and a status pill. Use Refresh if the list looks stale.
Status meanings
- In Progress — TEDI is actively driving Vista. Do not use the same forms manually.
- Completed — The playbook finished successfully. Check a proof pack if available.
- Failed — A step hit a technical or unexpected error. Read the step message, fix the environment, then retry.
- Blocked — TEDI stopped for an expected business or validation reason (for example a close check that did not pass). Fix the Vista/data condition, then run again.
- Pending / Skipped — Waiting to start, or a step was skipped as part of the playbook path.
Read a run in detail
- Select a run row.
- Review Current step, Progress, started/updated times.
- Scroll Step progress — each step shows a title, status, and message (pending steps may show Waiting to start.).
- Use Refresh if the run is still updating (In Progress auto-refreshes).
Proof packs
Some completed (and sometimes other) runs offer a proof pack — an HTML evidence summary generated for that run.
- On the run detail, select View proof pack (also available from list icons when a pack exists).
- Review the in-app Proof Pack view.
- Optionally select Open in browser for a full-page view.
- Use Back to run when finished.
Operators should use proof packs from the UI first. Raw folders under C:\ProgramData\TEDI\artifacts\runs\ are for deeper support investigation.
Retry a failed run
- Open a run with status Failed.
- Read the failed step’s message and fix the underlying issue in Vista, folders, or connectivity.
- Select Retry from failed step.
- Watch Step progress as the run continues.
Retry from failed step appears for failed runs. For Blocked outcomes, fix the business condition, then queue a new run (or use Run Now on the schedule) rather than expecting a blind retry to clear a validation stop.
Delete a run
Select Delete run only when you intend to remove history. Confirm: Delete this playbook run permanently? Step history for this run will be removed.
When to fix Vista vs when to escalate
- Fix in Vista / data first: wrong company, missing vendors, close-check blockers, empty source folders, batch already posted, permission prompts left open on screen.
- Fix on the TEDI machine: service stopped, license inactive, catalog not loaded, ODBC/SQL failures, missing folders on disk.
- Escalate with evidence: repeated Failed steps with unclear messages after environment checks—include playbook name, run time, step title/message, and proof pack or log snippet.
Common mistakes
- Treating Blocked like a crash — Read the step message; it often tells you exactly what Vista condition to fix.
- Retrying without fixing the cause — The same failure will repeat.
- Ignoring Command Center attention alerts — Failed/blocked runs also surface as playbook runs that need attention.
Next steps
- Monitoring and Troubleshooting TEDI — Service, license, catalog, and log paths.
- Scheduling TEDI Automations — Reduce manual queue work for stable jobs.
- Running a TEDI Automation — Happy-path manual launch.