What I have done is used snagit to take screenshots and then paste it into a word document. With snag it you can crop and add call outs or arrows to the screenshot using the snag it tools.  Next to the screen shot you could possibly add a few bullet points on what the actions are doing. I attached a sample screenshot of what I have in my workflow document. I hope it helps.

You can just change the text in the actions. That has been good enough for me.

Great suggestions so far, and I would say that the documentation that I've had to write depends greatly on the complexity of the workflow, as well as what would help the customer best understand the workflow/business process at hand.   This often includes a mixture of text with screen shots captured of the most important parts of the workflow (or sometimes the parts least likely to be understood).  You really can't go wrong as long as your documentation tells the story that is required to be told.

Thanks,

Mike

Hey Fernado,

do you know the print functionality of Nintex Workflow.

There are 2 options. One is only print and one is called "print with notes".

When you configure an item, take the tab "labels" and in the section: "Notes to display", choose User defined and write your comment in this field.

When you print it, you can see your comments below the workflow.

With big workflows, you should split in Main- and subworkflows not only for readability.

Further information: Breaking up a large workflow, to split or not to split?​ Approach to splitting a Nintex Workflow  Defensive Workflow Design Part 3 - Separation of Concerns 

Cheers Christof

That's a great idea too and I have tried that as well!

That's nice to hear..

When my audience is less technical I almost always use visio to document the process of the workflow.

Visio also helps when designing a workflow before build with technical teams as well. Then once it is built we can review using the screen captures or print outs of the workflow itself from the Nintex Designer with notes.

Many times I use Excel to supplement some areas that need to be documented. Such as notifications and tasks. With Excel we will map out the different components of the notifications. Like Subject, Body, and assigned to. This is very useful when building a workflow that has many notifications. But may not be necessary for a simpler workflow.

Aaron Labiosa 's tool named "Workflow Analyzer" has some useful features that could be used for documentation.

Take a look at >>> Workflow Analyzer - Initial Beta Release

Pairing up the opensource tool Greenshot with Workflow Analyzer is what I like to use for documentation/annotation of workflows.

I'm similar to Andrew Glasser in that I use a combination of Visio and Excel with Action Labels to document workflows.

I work with clients to document the "business process" side of the workflows with Visio.  This allows the client map out the entire process to better understand and document how everything currently works.  This also helps to distinguish between automated and manual (non-workflow) processes.  A key component of this diagram is providing a numbering system for each task that corresponds to an automated action in the workflow.

Documenting the task and notifications in an Excel spreadsheet is a huge help.  The spreadsheet includes components like task name, task details, task assignees, email subject, email body, and email recipients.  This allows clients to really think about and plan out how tasks and notifications are laid out.  These details are often overlooked and cause headaches down the line.  The spreadsheet also serves as a good future reference point and easy way for users to make changes.  I also use the numbering system from the Visio diagram to link actions together.

Lastly, I suggest using the action labels in the workflow designer to document workflows.  I typically use a descriptive title in the Action Title label, the corresponding number from the numbering system in the Left or Right Text label, and the action assignee or recipient in the Bottom text label.  This systems helps workflow users or designers quickly understand details about each action.

The nice thing about the user notes is that they will also display when you hover over an action.  So if you're going through a workflow trying to figure out what it's doing, that extra information can be very helpful. 

‌, can you please mark the answer that helped you?

Th OP links nicely from a discussion that was had on the January mission. This was the sort of functionality I was talking about being useful from within the designer so there was no need for a separate document.

I've documented workflows with screenshots and annotations similar to this in the past, it works but from a developers background, comments in the code rather than a separate document are far handier. Why look at a document and the designer when you could see it all in the designer?

Labels in actions, for me personally, are not sufficient when you are trying to explain an approach that has been taken to an entire section of a workflow. They are good for explaining the configuration of the action so a developer doesn't have to open every action to understand what the individual action is doing.

This is useful, but again, I think it falls short of helping us visually explain an approach taken the includes a group of actions, or color coding actions so you can see that they are related even if they are at opposite ends of the workflow.

I think this is more of an open ended discussion, rather than a question that needs an answer.  Different strokes for different folks.

‌ that link to the Workflow Analyzer is broken. Can it be updated?

look at  

Discovered minor limitation.  User comments is limited to 200 characters.    I guess that's better that 140.