cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Not applicable

Best Practice Question : Breaking a Complex workflow

Jump to solution

Requirement to build a multi-team business process. The process starts with a initiation request capturing basic information and then tasks are created for other teams to capture their own data points from the requester.

Not all teams participation is required , based on the initiation request we can decide whether to involve any team. Following the best practices "Separation of concerns" I think the workflow has be divided into sub workflows.

Design :

A main initiation list will be created to receive the initiation request, and each team will get their own list. Lets take Team-A, Team-B and Team-C. Each list content type will have common fields like Main Request ID ( lookup to the main initiation list) Status and Outcome column for tracking purpose. Each team has other fields that they have to enter as part of their process.

Workflows:

Master Workflow :  The master workflow kicks starts when initiation request is submitted and based on the data it will create list items on the team lists which kick starts the team workflows configures on each team list ( A, B and C) and stores the item IDs in workflow variables. There are two ways to ensure that the sub workflows ( team workflows ) are completed so that the master workflow marks itself as completed.

1) Loops : Query the team lists items every 2 hours using the workflow variables and end loop when all are done.

2) Status for each Team in Main list : Each team will get a column in the initiation list ( Team-A Status, Team-B Status ), and Main workflow will wait until these columns are changed to Completed then completes itself.

Also, in terms of performance I know that loop run on timer job and wondering if the same goes "wait for item change action" ??

I can also use Site Workflows too

Please let me know your thoughts on this. Thanks for taking time to read this

Product Version : SharePoint 2010 and Nintex 2010 Enterprise

Reply
8 Replies
tbeduneau
Nintex Newbie

Re: Best Practice Question : Breaking a Complex workflow

Jump to solution

Second solution seems better to me :

- offers "real time" validation view : no need to wait for 1 or 2 hours to validate the full proces if every team work is done

- reporting aspect : this solution offers a way to manage the process, because you can have a vision of

     * Which processes are almost complete

     * Which team are we waiting for in each process

You could even add 3 other columns saving date and time of each team validation....and so get a full report of team velocity for example.

Reply
Not applicable

Re: Best Practice Question :  Breaking a Complex workflow

Jump to solution

Thanks Thomas for the reply

Agree on the ease but I feel that we are duplicating the information and worried about data integrity. I have to add more logic to make sure no one can change these columns and add/delete these columns as the teams change.

Also, in terms of performance I know that loop run on timer job and wondering if the same goes "wait for item change action" ??

Reply
tbeduneau
Nintex Newbie

Re: Best Practice Question : Breaking a Complex workflow

Jump to solution

Considering data integrity, Site workflow should be the solution

Considering avoiding loop, schedule workflow.

So you could have a specific workflow, scheduled to check initiated request and verify corresponding teams work status from time to time.

Reply
andrewg
Nintex Newbie

Re: Best Practice Question : Breaking a Complex workflow

Jump to solution

Vamsi, Great job in thinking through the design of the solution. You considered the correct items and I'm even more excited you shared it with the community to help in a conversation. I hope we continue to see more of this kind of interaction!

When designing solutions to like these, there are times that the most simple approach can be the best approach. As an application developer, we try to write code for objects so that one object isn't dependent on the other. They definitely interact, and can affect the other when appropriate, but their life cycle doesn't have to rely on the performance of the other. In looking at your question and Thomas's feedback you guys have it figured out well.

It appears in your working solution that you have an initial form to start the process and a list to store the requests. A master workflow is started that updates initial status fields and create's items in the related lists. This in turn starts specific workflows for that content type.

There are many advantages to this approach. The master list can determine which is the appropriate party to notify and create items in the right list, and this is scaleable. If you need to add a new list and additional controller in the master workflow, this would be easy to modify and the other child workflows are unaffected. You could even save one of the child workflows as a template for the others to create new ones or use UDAs. Oh, and I'd recommend using a Site Content Type that is the parent type for each content type used in the team lists. This enforces that the fields match.

**About the "Wait for Item Update", this option may not be necessary. I wouldn't say that necessarily it is the best practice, but it is a very important practice to consider is long running workflows. In your case, you could have the master workflow start on initiation, create the appropriate sub list items, and then END. The child workflows will then do their duty and when the time is right after a task completion, it can then edit the primary list and change the status for that group. A second workflow, (or even the first!), on the primary list can start on modified and then check the status of each field. If it is equal to "TeamA-Phase2" then a state machine says to run the following process and subsequently update the status to "TeamA-Phase3" so that if the workflow starts again it doesn't re-process. This approach helps with workflow restarts. If there was an error somewhere you can start in the middle of a process and not have to start all over.

Having too many long running instances of workflows will eventually impact performance. All paused workflows are pushed from the "live" application pool memory into the content database and the workflow timer service now owns them. This isn't a performance problem, but in the architecture you have created work for the timer service to poll every running workflow to see if its their turn at bat. Thankfully it is designed this way and can handle the job, but consideration should still occur.

In Summary,

  • consider not having a long running workflow waiting for an update,
  • but continue the process in a state machine workflow controlling all events.
  • Workflows do not necessarily need to know that each other exist, just let the them worry about their objects they control
  • Scheduled and site workflows are awesome, but more used for periodic and reporting style result
  • Sometimes, what's simple works

Hope this helps!

Andrew

Reply
Not applicable

Re: Best Practice Question :  Breaking a Complex workflow

Jump to solution

Andrew, Thanks for talking time to elaborate your response and this is the kind of discussion I was looking for. I understand that long running workflows has performance impact and based on hardware configuration and no of workflows running; on the positive side breaking-down a long running workflow as you have mentioned they are short lived , easy to maintain/troubleshoot and promotes abstraction. I like your approach on the workflow based solution and thanks for summarizing too.

Coming to the workflows on edit, I feel like workflows on edit run on any kind of edit,   having a condition to make sure the workflow execution continues on right condition is not easy and the no of times the workflows would run depends on how many times the item is edited.

Admins have admin-only columns in the master list and they keep editing the item in the master list based on their findings ( offline ) ,I am wondering the no of instances of workflows that are configured to ruin on edit would be too many.

So deciding on whether long running workflows vs no of workflow instances that run on edit is kinda difficult. Are there any best practices to follow in designing workflows that run on edit. I know that its mostly on common-sense but still making sure I have all the info I need before I proceed.

Reply
andrewg
Nintex Newbie

Re: Best Practice Question :  Breaking a Complex workflow

Jump to solution

These are definitely great points and all part of the design process. The best part about it is that you have many options. The best practice will be the scenario that fits your situation best and I applaud you for recognizing the possible issues.

You could still start a workflow on modified and

  • then use a condition to check if modified by was by someone who is not an admin.
  • Or add the filter action in the workflow to stop it if a condition is met
  • use a previous field that is tracking the previous values and compare status fields with their previous values to meet a condition to continue

At least these will be quick start and stop workflows in the case where the appropriate conditions are not met to continue.

You could have the workflow started by the child workflows instead of updating the status on the master list item.

Again, there isn't any given harm to having the wait for item update action in workflows. Just map out how long you expect your workflows to be waiting for the change. Is it 2 days, 2 weeks, or 2 months, or 2 years? If it is the last two, i'd find a way to not use it. If you have several paused workflows, how many will that possibly be? 100, 1000, 100,000 in a month?

As you start working out some of those expectations you can begin to shape the design on what will be acceptable.

Alongside this, if you expect tens of thousands of instances to be created each month, then consider how history is managed. How often it is purged, or moved to another list, or multiple lists are used. See Demystifying Workflow History (Part 1)

Reply
Not applicable

Re: Best Practice Question :  Breaking a Complex workflow

Jump to solution

Thanks Andrew, I feel good after this discussion. I will do more research and go with one option.

Reply
makesense
Nintex Newbie

Re: Best Practice Question : Breaking a Complex workflow

Jump to solution

Interesting discussion, maybe useful, Mark!

0 Kudos
Reply