What to Include in a Workflow Diagnosis: Code, Logs, and Diagrams

“The automation stopped working” is how many real support tickets begin. It is also not enough to diagnose the problem.

Which automation? What should it have produced? Did it fail to start, stop halfway through, or finish with the wrong result? Those answers determine which evidence matters and which explanations are still possible.

You do not need a perfectly documented system before asking for help. A short description, one concrete example, and a few relevant supporting items are usually a much better starting point than a folder full of unrelated files.

Start with expected and actual behavior

Write two sentences before collecting anything.

First, describe the expected result: “When an approved invoice enters the finance queue, the workflow should assign it to the payment owner.”

Then describe what actually happened: “The invoice appeared in the queue, but no owner was assigned.”

This is an illustrative example, not a customer incident. Notice that it identifies a visible difference without pretending to know the cause. Saying “the assignment integration is broken” would jump ahead of the evidence.

Add the approximate time, whether the problem repeats, and the last step you know completed. If you do not know, say so. An honest “we do not know” is better than a guess that quietly becomes accepted as fact.

Choose evidence that answers a question

Different materials tell you different things:

• Workflow diagram: Which steps, decisions, and handoffs are intended?
• Relevant code or configuration: What condition or mapping is actually implemented?
• Execution log: What did the system record during this run?
• Screenshot: What setting, error, or visible result was present?
• SOP or instruction excerpt: What was the person or agent told to do?
• Input and output example: How did the result differ from what you expected?

For the invoice example, the assignment rule and a trace from the affected case may tell you more than screenshots of every finance dashboard. Relevance beats attachment count.

Label each item with what it shows. If a diagram is old or the code may not match the deployed version, say that too.

Include one case people can follow

A collection of unrelated screenshots makes it hard to connect one step to the next. When you can, use evidence from the same incident.

Give the case a consistent, anonymous label. Keep useful timestamps, step names, and exact error wording. If you also have a successful example, label it separately and note any differences you already know about.

The comparison gives you somewhere to investigate. A difference between two runs does not prove why one failed.

The same idea applies to manual work. A short record of when a request was handed over, which role received it, and what happened next may be the most relevant evidence. Not every workflow has source code.

Keep enough context around each excerpt

For code, include the condition or mapping in question and enough nearby context to understand it. One isolated line can hide the branch that decides whether it runs.

For logs, include the lead-up and outcome when available. For screenshots, leave the setting label or step name visible. For diagrams, make sure the arrows, branch labels, and exception paths can be read without zooming into a blur.

You do not need to upload an entire repository. If a file is too large, choose a focused excerpt and explain what you left out. That missing context is part of the evidence boundary.

Review what will actually be submitted

TryPromptFlow's live-failure intake accepts optional evidence alongside your description. Before you run the diagnosis, you can review the selected text excerpt, inspect the processed image preview, and replace or remove an item.

Use that review step. A diagram that looked clear on a large monitor may be unreadable after image preparation. If the text or connections are hard to see, provide a clearer supported image or describe that part in text.

The intake shows the supported formats and limits. If an SOP is stored in an unsupported document format, paste the relevant section instead of assuming the whole file can be uploaded.

Remove passwords, API keys, and personal or customer information that the diagnosis does not need. Keep the structure understandable, but anonymize names and identifiers where possible.

Expect a diagnosis with boundaries

More evidence gives the diagnosis more to examine. It does not make every conclusion certain.

A solid report separates what the submitted material shows, what you reported, and what still needs to be checked. It should help your team decide what to investigate next and how to test a proposed change.

TryPromptFlow works from the information you submit. It does not connect to your live systems or apply repairs. Your team reviews the findings, makes any changes, and verifies the result.