Leave an automation that someone else can understand.

Fictional example: a workflow receives a request, checks its fields and prepares a draft for the support team. It does not send the reply to the customer. That last sentence marks a boundary someone might otherwise assume away.

Record the purpose, trigger, minimum input, expected output and excluded actions. Name the person who uses the output and the person who maintains the workflow. Record both roles if they belong to different people.

Save a valid fictional request and describe each step: receive it, validate fields, assign a category and create a draft. Record where to inspect the status and which identifier connects the input to the output.

Include classification rules and exceptions. If the workflow uses model instructions, identify where the active version lives. For connections, document required access and who can renew it, without copying passwords or keys into the note.

Rehearse an incomplete input, an unavailable connection and an output needing review. For each, describe how it is detected, where the work is left and who decides what happens next.

Do not make “run it again” a universal answer. First check whether a draft was already created or a record changed. Document which steps can be repeated and how to recognise earlier results to avoid duplicates.

Fields: workflow name; purpose; owner; actual last review date; trigger; example input; rules; expected output; status location; required connections; known errors; how to stop it; how to continue manually; checks before retrying.

Fill each field with a locatable instruction. “Check the error” does not say where. “Open the workflow history and find the request identifier” describes a usable path. Replace generic names with the names used in your environment.

Ask someone else to use the note with a valid fictional input and an incomplete one. Observe whether they find the output, identify the missing information and know whom to contact. Use the questions that force them to ask you for help to improve the document.

Repeat after changing a connection, rule or output. Keep a short record of what changed and why. For this exercise, a small note that reflects the current process is more useful than a long manual nobody has checked.