Unpacking a Workflow

Unpacking the idiosyncrasies of a lifecycle/workflow can be daunting. Many times a well designed “1.0” workflow will turn into a “2.0” nightmare. I have seen workflows with so many connections between tasks and rules that it looks like all the tasks are connected with no rhyme or reason.

Documentation

Good documentation can provide an excellent resource and general direction of the workflow. However, with large process automation projects, the documentation is usually provide for the initial implementation and left stranded thereafter.  Determine how obsolete the information is before reading it too closely.

Structure            

Worse Case: Over time, workflows can turn into spider webs. Once they are built it becomes easy to make small tweaks and fixes. These work great and the business is happy, but in the long run can get out of control. How do you document “small” changes?

Best Case: A solid naming convention makes easy to traverse through the decision branches.

Look for repeating patterns of rules and actions. These could help minimize what looks complex but is actually a bunch of redundant activities.

Naming Conventions

Hopefully the naming of the lifecycles, work queues, rules, actions, properties, etc., makes some type of logical sense. A lot can be implied in a formal name convention, for example, a lifecycle name of “HIM - Validation” which shows the department (“Health Information Management”) and the objective (“Validation”). Depending on the workflow application prefixing with “smart” hierarchical keywords is best practice, so hopefully they did it!

Search

If your workflow tool has the ability to search for specific component names and presents the results in an actionable way, figuring out workflow specifics just got easier.

Rules and Actions

Rule names can be precise and consistent, or obsolete and sporadic. If you have the former, you are lucky. This goes for actions as well. Both of these may be copied (linked) to other locations, so be careful of making changes in one spot only to be burned by the other part of the workflow that just broke.

Properties and Keywords

Many workflows rely on saving status and regular expression values to the document’s attributes/keywords. It’s important to create a matrix on how these values are set and where they are used in the process. By “properties” I mean the temporary values that are used by the workflow for calculations and routing (and logged) by not saved to the document.

Logs of workflow actions

By viewing logs you may be able to decipher some of the paths that documents take into and around the workflow. Depending on the settings, these traces might show what actions took place, when, and by whom.

Decision Trees

These are made up of combinations of rules and actions. Rules usually have a true or false outcome. Building complex decisions can mean stacking many of these rules together to provide an eventual processing outcome.

Visual representation

Whether in a tree format or a more graphical view, following the progression of a workflow visually can be very useful. With complex workflows this view becomes too chaotic looking. Splitting up the visual representation into meaningful chunks may help figure things out.

Users, Groups, and Roles

Listing out groups and roles, and matching them to activities will show certain expectations of actions. Each group/role will have permissions and privileges which will provide a clue as to how the users interact with the processing of documents.

Document flows

Running documents through a workflow is obviously one of the most practical ways to decipher workflow behavior. As an admin user keep in mind that you will be able to do and see many parts of a workflow that Users won’t be able to see.

Figuring out what a workflow does can be a very frustrating activity. Hopefully, some of the above techniques will make it more tolerable.