Hi, there!

Here at Questetra(Questetra), we receive many inquiries regarding business improvement from our customers.

Throughout those consultations, I saw a lot of Workflows (Business flow, Business Processes), and some of them almost made me cry out “I hate this workflow!”

In this post, I would like to discuss problems and ideas of improvement regarding one of those kinds of Workflows that would make me cry; a “Workflow that is unable to send work back”.

Workflow that is unable to send back

As an example, we will consider an operation of creating a “Web page for job recruitment”. For example, a company that operates a Web site that posts job information such as part-time jobs, and is receiving recruitment information from clients such as taverns and creating a Web page post from that information.

  1. The creator creates the Web page
  2. The proofreader checks the design of the page (layout, typos, wording, etc.)
  3. Legal checker checks from a legal perspective (whether there is any inappropriate expression)

In the Workflow diagram above, it is not possible for the proofreader to send the flow back to the creator, even if they find errors such as typos. All that the proofreader who finds a mistake can do is to reluctantly revise by themselves, or ignore the error.

Nobody would like a Workflow like this…

Just make it capable of sending work back!

Now, let’s make the Workflow capable of sending issues back.

The following options can be considered two such Workflow improvement ideas.

  • Type A: To draw an arrow back to the upstream Task
  • Type B: To add another Task icon and draw an arrow to it

The former is a common idea, whereas the latter might be a bit hard to understand. Let’s dig into the details respectively.

Type A: Draw an arrow back to the upstream Task

It is a simple idea which everybody first thinks of. Take an Issue that comes flowing down from “Create”to“Proofread”and send it back on a flow from“Proofread” to“Create”.

By creating such a flow, the proofreader becomes able to send back an Issue with instructions when they find an error at the “Proofread” Step. The creator confirms the points instructed by the proofreader, revises their production, and finishes the “Create” Step.

This method of sending back allows the creator to be informed that something has been improved in their work (the Web page). Depending on the content of the instruction, it would be rather educational to the creator.

Type B: Add another Task icon and draw an arrow to it

The other option is to flow an Issue that has come from “Create” to “Proofread” to the new Step of “Rework”, which has been prepared separately, instead of sending back to the “Create” Step.

Just as in the previous section, the proofreader can inform what they have found out to the creator. However, here in Type B, there is an advantage over Type A.

That is, the state of “being sent back for reworking” becomes obvious. While token (a circular indicator to show which Step in the Workflow is the currently active one) is on the “Rework” Step, the creator is reworking an existing page and definitely not creating a new one.

You may say ‘it’s as a matter of course,’ but in the case of Type A, when the token is on the “Create” Step, you can’t tell if it is being created for the first time or it has been sent back from the “Proofread” Step.

This difference may not seem to be very meaningful during the drawing of a Workflow diagram. However, when workers do their job along the path drawn in the Workflow diagram and it reaches a level of operation where many Issues are active, it will be obvious which ones are being created afresh or being reworked at a particular moment.

Based on the situation that business activity has increased you will be able to take measures to achieve greater results, such as to change the placement of people or change the priority of the work to which they respond.


I started writing this post with a topic that I hate Workflows in which I cannot send back a Task. And I explained there are two types of ways to send back.

  • Type A: To draw an arrow back to the upstream Task
  • Type B: To add another Task icon and draw an arrow to it

Type A is a method that anybody can think up normally, while Type B is a method which many of our customers are using. I will be happy if you keep this in mind and let it help you with the improvement of your Workflows in the future.

Incidentally, though it is an introduction to our service, we offer a service(Cloud-based workflow “Questetra BPM Suite”) which allows you to draw Workflow diagrams. As you can draw Workflow diagrams for free, if you are interested, please apply from here

Thank you for reading!


About The Author

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Nach oben scrollen