We are often asked during the sales process and in subsequent implementations “Can Integrify handle a really big process?” The answer, of course, is “yes”. If you can dream it up, 99% of the time, Integrify can implement the process.

But, just because Integrify can handle a large process, it doesn’t necessarily mean that that a single, all encompassing process to handle everything in your organization is a good idea. More often than not, what occurs in these types of situations is that while something outwardly is seen as one massive process in reality it often is two or three (or more) distinct processes all rolled up into one end-to-end process.

So, if Integrify can handle it, why shouldn’t you do it? Here are some common pitfalls that often occur when building that huge process:

1. Overwhelmed users: the task history of a given process becomes so large user gets lost trying to figure what has occurred, what they need to do based on previous tasks that occurred, or what comes next.
   
   
2. Simultaneous Task Assignment: Like the first item above, if a user is assigned two tasks within a process. It can be confusing for that task recipient. Do they know which task to complete first? Is there an order of precedence they should follow?
   
   
3. Process Administration headaches: it can be difficult to maintain a huge process. Many times the transition condition logic and looping become so complex that one change inadvertently impacts the entire flow of the process.

So how do you handle this? The first thing you should do is evaluate the process and determine if there are two (or three or more) distinct streams of work in the process. For instance, take the following flow into consideration:

In this particular scenario, a user would submit the initial request (Initial Form Request) which in turn starts three additional, yet completely distinct tasks that are assigned to different individuals. Once those three tasks (Work Stream A, Work Stream B, Work Stream C) are complete, then the Approval task starts.

Where things begin to get tricky is when the approver rejects a task and needs to loop back from the Approval task to Work Stream A and Work Stream C but not Work Stream B. Since each task is independent of one another, it may make sense to also create separate approval task for each work stream:


While it may seem redundant adding the additional approval tasks in the process, it actually provides you with a more streamlined way of handling loop backs and varying conditions that can arise with loop backs in your transitions. Likewise, you will often find that those three distinct streams of work are often approved by different individuals and/or require additional task to execute after they are complete anyway.

Another common issue that is often encountered when a large process is built is inclusion or exclusions of tasks at different points in the process based on user interactions. Take the following example:

After the Initial Form Request task is submitted there are a series of OR conditions on the Transitions so only one of the following tasks (Work Stream A, Work Stream B, or Work Stream c) will execute. Once one of those tasks is executed, then the first Approval Task will start. After that Approval is complete, the Secondary Approval Task is started. At this point, the Secondary Approval task has the option to loop back to either Work Stream A, Work Stream B, or Work Stream C. All of this is fine until the user completes the task on the loop back from Secondary Approval. Here is what you can often run into:

1. Depending on the Transition conditions you have defined from Work Stream A, Work Stream B, or Work Stream C tasks to the first Approval task it may not start again. Suppose in those Transition conditions it states the Approval task will begin when any of the Work Stream tasks completes. The problem is, one of the Work Stream tasks already completed before the loop back.
   
   
2. You only want the Approval task to be fired the first time but not after the loop back from the Secondary Approval Task.

Like in the first example, it often is just a restructuring of the process. It may be best to have three Approval tasks rather than one. Or, rather than looping back to Work Stream tasks again, you can just add more form tasks:

While it may seem cumbersome when initially building your process, in the long run it will most likely save you time. Processes change over time and more complex rules are often added. This structure would be able to handle these changes.

Note: Integrify can handle looping back through multiple tasks and evaluating rules differently with each loop back. In the Advanced Settings for any task, there is an option called “Only triggering task state in start rules will evaluate to true”. This will instruct Integrify only to evaluate the rules based on the last iteration of the tasks that start it.

While we have focused on altering a process to simplify loop backs and conditions, one other alterative is to simply create multiple processes.

The first thing to do is evaluate that initial form in the process. Suppose it was an IT request and on that form it has options for the end user to request a new computer, request access to a server, and change an email account. While each of those requests may go through the same IT department, they may follow very different approval paths, one may require an invoice to be created, another may require a security review, etc. In this scenario, it would best to break that process into three distinct processes:

1. New Computer Request
2. Access Request
3. Email Account Request

In addition to the simplification of building those processes and avoiding some of the common pitfalls discussed above, the added benefit is the end user has very distinct processes to select from when they start a new request too.

Good luck!