In a three-tier organization (department-division-section), the workflow from application to approval is as follows: application → section manager approval → division manager approval → department manager approval. However, if organizations with different levels are included, or if the applicant belongs to a different organization, the approval steps may be different, such as application → division manager approval → department manager approval.
To handle these differences in steps in a Workflow app for the application-approval flow, you will need to devise settings that allow you to skip Steps so that the processing of an already-installed approval Step is not carried out.
This article introduces specific app definitions that utilize the processing person settings with [Job Title] and [Error Boundary Event].
Cases Where the Number of Approval Steps Varies Depending on the Applicant
In some cases where the depth of the organizational hierarchy varies, the approval steps may differ depending on the organizational level to which the applicant belongs.
For example, in the organizational chart below, if Tim Wheeler submits an application, the approval steps are
- Application → Team Leader approval → Section Head approval → Department Head approval
However, when Charlotte Hatherley applies, there is no supervisor who can approve the application as a Team Leader, so Team Leader approval is not performed.
- Application → Section Head approval → Department Head approval
The number of approval steps will be different.
With paper applications, the system can be flexible. For example, if Charlotte Hatherley, who is required to go through a different approval process, the application form can be submitted to the Section Head with the Team Leader approval confirmation field left blank.
On the other hand, in a Workflow App each task, such as application or approval, is defined as a human task. The person in charge of each task is determined based on the rules defined in the Operator settings. When a process is executed, if there is no user to become the Operator for a specific human task, that step will result in an error, and normally the process will not proceed to the next step.
Let’s consider a setting where a specific step in an app with a set of approval rules defined can proceed even if the applicant’s manager is not present to approve the step.
Processor Settings With Job Title
In Setting the Operator Using Position we described the setting using the (With Position) option. With the (With Position) option, you can flexibly identify the organization’s title holders as candidates for underwriting, depending on the target organization. On the other hand, if there are multiple target organizations, all of the positions in each organization will be candidates. For example, if the Operator is set to “Members belonging to a higher-level organization”, all users with positions in higher-level organizations, such as section chiefs, department heads, and general managers, will be candidates for underwriting in the (With Position) option.
If you specify a specific job title instead of (With Position), the target will be narrowed down to users with the specified job title and users with other job titles will not be targeted. In the example of [Members of a higher organization], if the specified job title is, for example, “Manager”, only users with managerial positions will be identified as underwriting candidates.
For the applicant, the supervisor who executes the approval process may belong to the same organization as the applicant or to a higher organization. For Tim Wheeler in the organizational chart above, the Team Leader belongs to the same organization, while the Section Head and the Department Head belong to higher organizations, but for Charlotte Hatherley, the Section Head is a supervisor who belongs to the same organization.
In a Workflow App, to handle both of these situations, two types of rules (conditions) are set in the Operator settings for the approval task. For example, the following two rules are set in the Swimlane for the “Section Head Approval” Task.
- Supports applications from lower-level organizations
- Swimlane: Applicant, Member of the Upper organization of the user who processed the task in this swimlane, Position: Section Head
- Accepts applications from general employees of the same organization
- Swimlane: Applicant, a member of the Same organization as the user who processed the task in this swimlane, Position: Section Head
The two types of rules assign Operator separately. However, if a position name is specified and narrowed down, the unintended rule will result in no candidates for assignment. For example, the Section Head approval step will look like this:
- Application from Team: No Section Head is available in the same organization for the conditions described in 2. above, so there is no one in charge of processing the application.
- Application from Section: In contrast to condition 1 above, there is no Section Head in the organization above the Section, so there is no person in charge of processing.
As a result, even if two types of rules are set in the processor setting, one processor will be identified.
If you set [Position: (With Position)] without specifying the role name, the Section Head and higher-ranking personnel will also become candidates for approval under condition 1 above. Also, in the case of Tim Wheeler, even though the Step is “Section Head Approval”, the Team Leader will also become the person in charge of processing due to condition 2. As a result, due to the two rules for setting the task operator, multiple people, including unintended users, will become candidates at the approval Step.
Setting to Skip a Process
In a workflow, when a process is executed the process proceeds as defined in the workflow diagram. When the process reaches a human task, if there is no one to process that task it becomes an error task and the flow does not proceed. This section explains how to skip the step that causes an error so that the process can proceed even in such cases.
- Application → Team Leader approval → Section Head approval → Department Head approval
In this flow, if there is no Team Leaser, the “Team Leader Approval” step, which has nobody to process the task, will be skipped to achieve the following flow
- Application → Section Head approval → Department Head approval
When the applicant differs in the hierarchical structure as in this case, there may be a case where there are no operators according to the setting of the operator who specifies the position. For example, if the applicant is set as a Team Leader in the same organization as the organization to which he or she belongs, and the application is made from an organization where there is no Team Leader, there will be no person to whom the process can be assigned.
With no applicable person, the human task will result in an error. However, if the Error Boundary Event option is enabled, the process will skip to the next step without being processed. As soon as a process is executed and a token reaches the human task, the Operator is identified according to the rules of the Operator settings. If the attempt to assign the Operator is unsuccessful, the token will move to the Error Boundary Event. The token will continue on to the next step connected from the Error Boundary Event, so the step will not be processed and will be skipped.
- Setting up Human Tasks ‘Team Leader Approval’
- Enable error boundary events and connect the route to the next step
Summary
This time, assuming that continuous approval is performed in an organization where the organizational hierarchy is not uniform, we explained the application settings that can handle cases where the number of approval steps differs depending on the applicant. In cases where the number of approval steps is smaller, we handled this by skipping approval processes where no one is in charge of processing. The following two functions were used for this setup.
- Set up an operator with a specified [Position]: When certain conditions are met, there is no assignable operator
- [Error boundary event]: Continue the process when an error occurs
If you specify a position name in the Swimlane Operator Settings, the list will be narrowed down by the specified position. By narrowing down the job titles, it is possible to prevent inappropriate users from becoming operators, or to prevent operators from being in charge of a process under certain conditions. An［Error Boundary Event] is a function to prevent the flow from stalling in the event of a process error, but it can also be used as a mechanism to skip a process under certain conditions by making creative settings.
Questetra BPM Suite offers a wide variety of functions. Please design apps that can respond to various situations by combining individual functions.