Enterprise Software Solutions – On Premise, In the Cloud or Managed

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.