You are viewing limited content. For full access, please sign in.

Question

Question

Feature Request: Activity to return to previous spot in Workflow

Workflow Ideas
Updated September 12, 2014
asked on June 15, 2014 • Show version history

I have a workflow with about 200 activities and many branches. Depending on actions that can be taken throughout the Workflow, there is a chance that the Business Process may need to be returned to a previous stage.

 

In the past I have used Repeat to do this, but in this particular Workflow I am running in to an issue where that will not work. I will present the problem in a simple logic puzzle:

 

Let's say a Workflow has 5 steps: A, B, C, D and E.

 

Choice made on step E can return the workflow to step C

 

Choice made on step D can return the workflow to step A

 

Therein lies the problem - you can't get the first repeat inside the second repeat without making the first repeat wait to happen until the end of the second repeat's contained activities. If anyone knows another way, please advise.

 

The only idea I can think of is to do a conditional sequence that allows the Workflow to bypass unneeded parts to get to the end of the second repeat condition. This seems cumbersome.

1 0

Answer

SELECTED ANSWER
replied on June 16, 2014

That's where you would have the parent workflow wait for the child workflow to complete, and then have the child return all of it's results back to the parent through parameters. The parent would maintain continuity, and use the information that comes to populate business process information.

 

This is a bit clunky, but it should work. I think that Business Processes ought to give you the option of pulling the history of child processes into the current process. Maybe a future version.

0 0

Replies

replied on June 16, 2014

First, I would try to split your workflow functionality into smaller pieces. Make A, B, C, D, and E all separate workflows.

 

For each workflow that might return to the parent, have the parent start it using the Invoke Workflow activity and check the box to make it wait for it to finish. If the child workflow needs to return to the parent, it can do so. Or, you can use the End Workflow activity to terminate the parent, and the child can continue on it's way. You can glue them together a little tighter by passing parameters back and forth along the way.

 

Depending on what you are doing, and how modular you get, you might not need to ever go back. Instead, you can end each workflow right after it runs the next one. Then your decisions are always pointing forward instead of needing to backtrack.

3 0
replied on June 16, 2014

I ended up using this approach for this module, however, it ends up meaning that your Business Process history is split in to two on the document. I'd rather have the entire history appear as a seamless process.

0 0
View 2 previous replies
SELECTED ANSWER
replied on June 16, 2014

That's where you would have the parent workflow wait for the child workflow to complete, and then have the child return all of it's results back to the parent through parameters. The parent would maintain continuity, and use the information that comes to populate business process information.

 

This is a bit clunky, but it should work. I think that Business Processes ought to give you the option of pulling the history of child processes into the current process. Maybe a future version.

0 0
replied on June 16, 2014

Not a bad idea -- have a summary history step that prints to the parent Workflow, describing everything that happened in the child workflow. But yes, would still like to see a feature to pull it in automatically.

0 0
replied on June 16, 2014

Thank you for the suggestion, I have added it to the product backlog. If you wish to give us more details about the specific use cases for the feature it will help us with future development.

0 0
replied on June 17, 2014

Say you have a vacation request process. A standard vacation request gets routed to the supervisor for approval. A medical leave request might need to go from the supervisor to HR for additional steps. A family leave request might have yet another approval process. Standard employees might have one process, and union employees might have something different.

 

Each of these might have data validation checks, QA, approval/rejection/correction cycles, etc. To keep everything understandable, you might split it up into multiple workflows in order to make the various parts composable. There might be an orchestrator BP that invokes each of these and does work based on the result. OR you could have a scenario where each of these independently passes data to the next workflow in the chain depending on various criteria.

 

In the end you only want a document to have a single BP history called "Leave Request". So, you for the orchestrator scenario, you'd want the parent workflow to be able to pull the BP history out of a workflow that it calls. For the chained process, you want each workflow to pass it's BP history on to the next.

 

Obviously this wouldn't be needed for every case, so it would need to be configurable. Perhaps it could be done through the existing BP activities, or through a new one. It might work to allow a workflow to "publish" it's BP history in a way that allows workflows to retrieve it when they call it, or are called by it. Ok, maybe too much design here. I'll shut up.

0 0
replied on September 12, 2014

I have heard rumours of something along this line being considered for upcoming versions, and would like to add that I think it would be so valuable for clients. I hope to 'flesh out' the requirements as I experience them, in this post.

 

It's not an elegant design to require many disjointed business processes, and equally awkward to always rely upon delayed/waiting business processes, so any option to permit completing each pass of a business process, yet record the KPI's or metrics for each pass, such that on a subsequent pass, the business process can effectively almost be 'continued' (or inherited, or updated, etc.), then you can permit users via Workflow Web to see meaningful end-to-end reports (for individual process runs, or aggregate reports), even if the individual business process took a long time to complete.

 

Using 'storable' KPI's or metrics also means that potentially more than one business process can use the same valuable data.

 

For example: CEO wants to see reports on aggregate movements from Departments A to B. But for the same process, the Managers of Departments A and B each want to see only the more granular details of what occurs in their respective departments, both at the individual process level and the aggregate level.

 

I realize we can kluge this all outside of LF Business Processes using external databases, but the LF BP environment is so close to delivering this already, it would be a perfect incremental addition. I hope that made sense.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...