User Roles in a Human Workflow

In my previous post "Main Considerations for a human workflow",  we briefly touched upon the the need to create a list of roles (and users) who will participate in a business process. In this post, let's consider the topic in a bit more detail.


Usually, there are three categories of roles - Submitter, Approvers and Workers. 


Approver is the most easily understood of the three roles. If we generalize this role a bit more, the main responsibility for a user in this role is to make a decision. Typically, the decision is whether to approve something or not, but some decisions may be more involved. E.g. in case of approving a project, the approver may approve a smaller budget or add conditions to his approval or may request to seek more approvals.  The decisions that the user is expected to make in this role usually drive the actions that are available to this user in the interface that is presented. 
Generally speaking, approvers are either people in specific business roles in specific departments like "Purchasing Coordinator" or  in a management hierarchy within a business department like Manager, Sr. Manager, Director etc. 


A user in the "worker" role is typically responsible for completing a task or an activity. If we consider "New Hire" workflow, there are several tasks that will fall under this role: 

• Add the new hire to Active Directory and include username and email address to the next steps.
• Set up a cube and telephone for the new hire and provide details to the manager step.

Users in this role are typically the ones who own the job function. E.g. System Administrator or Telephone Technician etc.

Submitter is usually the customer of the business process. This is the person that wants something done. However, submissions may be done on behalf of someone else - An order entry clerk is submitting an order to the system, but is doing it on behalf of the actual customer. Similarly, a service technician may log a service ticket on behalf of the business user who is facing the issue. 

In some business processes, there may not be any need to limit who can submit a request. Also, it is usually difficult to group users in this role as the user base may be diverse. As long as there is a rigorous approval process in place, the need to limit "submitter" access may be marginal. 

Main Considerations for a human workflow

Main Considerations for a human workflow

In this “Knowledge” centric economy, people are often involved in business processes in order to provide decisions, judgments and other inputs that a system on its own can’t produce.

When “people” are involved, there are special considerations that are extremely important. I am listing these considerations at a high level below. I plan to blog about these in more details in the near future.

•  You need to create a list of roles and users who will participate in the process. Usually, there are three categories of roles - Submitters, Approvers and Workers.
• You need to detail out what information each person will be able to view and what he/she will need to input.
• You will need to eliminate repetitive or unnecessary data entry. If there is a way to retrieve the information from backend system, it is annoying to ask a user to enter that information manually.
• You will need to provide users ways to track status of their requests as well as view their past requests.
• You will need to provide for escalations when people don’t “behave”. You can find more details around escalations in my earlier blog post.
• You need to consider how people will be notified of their tasks – email, text alerts, and mobile notifications.
• You will need to define what tasks are individual and what tasks are performed by teams
• You will need to handle delegation and out of office situations.
• You will need to factor in strategies for when a person leaves and has pending tasks.
• You will need to define governance especially around process ownership and administration.

You need to answer these questions for any/all “Enterprise-grade” BPM/Workflow projects. While this seems like a lot of work, a good BPM solution/Platform (likes of K2 BlackPearl) has features and functionality to navigate you through them.

Escalations in Business Processes

A business process, most often, is a commitment to the stakeholders of a "timely" outcome of a request that serves a higher business purpose. In order to ensure the timliness of the outcome, a process needs to build in checks and balances to encourage process participants to perform their duties within expected timeframes. It is important to quantify these timeframes when the process is designed and enforce them via the implementation. Often, the enforcement is performed via "Escalations".

There are typically three types of escalations in any business process - Reminders, Escalations up the management chain and Expiration. While there are many other nuanced escalations possible, these are by and large the most understood and often used.

With email reminders, users are notified (again) of any pending actions after a period of time. These are soft escalations or friendly calls to action. Reminders can also be cc'ed to higher ups to coax a user into action.

Escalations up the chain usually mean taking a task from a user after a period of time and assigning it to his or her manager. These are effective when a user fails to perform the task in a timely manner either because he or she is out of office or just missing in action.

Expiration is usually the last resort where the workflow continues to the next step. Under this scenario, the task is usually optional or not completely "mandatory" and can be marked as incomplete as the process moves on to the next step.

Other important consideration in escalations is the working calendar. If a certain task is expected to take a day and it was assigned to a user on Friday evening, escalations should factor in the weekend and escalate only on Monday evening assuming Saturday and Sunday are not part of the working calendar.