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:
-
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.
-
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?
-
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:
- 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.
- 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:
- New Computer Request
- Access Request
- 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!