Through studying Chapter 1 to Chapter 8, you are able to create various Workflow Apps.
In Chapter 9, let’s imagine an actual business process and try to implement it as a Workflow App. We will proceed while reviewing what we have learned in the previous chapters.
Imagine a Real Task
We will create a Workflow App called “Order Approval” where sales representatives report cases they are about to accept to their supervisor, the sales manager, and get approval. In “Order Approval”, if the order is from a new company, we will check with the management department to see if it is okay to accept the order.
Specifically, the following tasks will be turned into a Workflow App:
Oahu, a sales representative, has received a new order, so he registers the data in Questetra and asks his boss, the sales manager Sumatra, to confirm whether it is okay to accept the order with the registered details.
Sumatra checks the registered details and does one of the following:
- If there are no problems with the order, and if the source of the order is a customer whose orders has been accepted in the past or the management department confirms that the source of the order is not an anti-social force, the order is approved as is.
- If there are no problems with the order, but the order source is a new one, ask the management department to check if there are any problems with the order source.
- If there are problems with the registered details but only minor corrections are required, return the request to Oahu to correct the registered details.
- If the problem is serious and difficult to resolve, reject the order.
When Oahu receives the order back from Sumatra, he corrects the data and asks Sumatra to check it again.
Canary, an employee in the management department, checks the order source information at Sumatra’s request. If there are no problems, she reports that to Sumatra, and if there are problems, she reports the specific problems to Sumatra.
After Sumatra’s approval, if the order amount is less than 1 million yen, the work for this project will be completed at this point. If the order amount is more than 1 million yen, the president will be contacted by email before the work is completed.
It’s hard to understand from text. When actually creating a workflow app, it is better to take advantage of Questetra’s feature of being able to create apps without coding, edit the workflow diagram in Modeler, and get feedback while doing so. In reality, you may not realize the necessary processes until you are defining the workflow.
Here, as a training exercise; try designing an app called “Order Approval” based on the contents of the text above.
Key Points in Designing a Workflow App
Before designing a Workflow App, let’s review the main points. To create a Workflow App, it is necessary to define the following three things:
- How the work will be carried out (Workflow diagram)
- Who will be in charge of processing each step (Operator)
- What kind of data will be handled (Data items)
How the Work Will Be Carried Out
When creating an app, you need to decide and set the type of tasks to be processed and the order in which they will be processed. To do this, you create a workflow diagram by arranging icons according to the type of task or process, and connecting the icons with flows to show the order of processing.
Who Will Be In Charge of Processing Each Step
Once you have clarified what tasks are required to complete your work, you can assign users to handle each group of related tasks. This is done by assigning users to swimlanes.
What Kind of Data Will Be Handled
In a workflow, various data is passed and processed. The type and name of the data to be passed are set in the Data Item.
So let’s consider each one.
Draw a Workflow Diagram
Think about how you want to proceed with your work and create a Workflow diagram for Order Approval.
The process starts with Oahu registering the order details. As we learned in Chapter 4, let’s set up a Start Event and a Human Task and connect them with a flow. Any task that requires human interaction can be represented as a Human Task. Once this task is completed, which task will be the next step that the process moves to?
The task that Sumatra performs is complex. There are several options to choose from and the next task seems to be determined by the decision. We learned in Chapter 7 that we can select the next task to be performed with button labels. Even though there are more choices, it seems to be possible to achieve this using button labels.
Another area where processing differs depending on the case is sending an email to the CEO if the order amount is $5,000 or more, and not sending it if the order amount is less than $5,000. This could be achieved by switching the processing route based on the value of the data item. Switching the processing route conditional on the value of the data item was also done in Chapter 7.
Finally, think about whether there is anything that can be automated. The task of reporting to the CEO by email seems like one that can be automated. In Chapter 8, we learned that emails can be sent automatically during a workflow.
Once you have created it, let’s check it out with a configuration example.
＋ Setting example
Modifying registered content is a separate task from registering an issue. This is to make it easier to see whether an issue is one that has not been worked on or one that has been returned when looking at the list of assigned tasks in My Tasks.
Also, this time we are not using the Auto Step [Update Data]. In Chapter 8, in order to check the body of the email before sending, it was necessary to create formatted text using [Update Data] before the confirmation Human Task. Here, we are sending an email without including a confirmation task, so we are creating formatted text in the [Body (Plain Text)] of the [Throwing Message Intermediate Event (email)]. Of course, there is no problem if you use [Update Data].
As a way of specifying the email destination, this time enter the actual destination email address directly in the [To] field in the settings dialogue for the [Throwing Message Intermediate Event (email)].
An [Annotation] is placed near the [Throwing Message Intermediate Event (Email)]. You can write explanations and notes about the process, making it easier to understand what processes are performed in the workflow.
Set the Operator
Next, let’s set the person in charge of each Order Approval step. The following four people appear in these steps:
- Oahu (Sales Representative)
- Sumatra (Sales Manager)
- Canary (Employee in the Management Department)
- CEO
Among these, the CEO is the recipient of emails when an order for a project worth over $5,000 is received, so they do not seem to be the operator. How can we assign the other employees, the sales manager, and the management department? Let’s set this in the swimlanes of the workflow diagram.
We could directly specify users such as Oahu, Sumatra, and Canary, but that would make the work dependant on the individual. It also would not be possible to handle promotions or transfers of members. Let’s set it up using the [Organization] information we learned in Chapter 5.
Let’s also make use of [Position]. In Chapter 7, we used [Position] to specify the supervisor of the user who started the process. In this tutorial, there was a [Position] called “Leader”, which was given to the head of an organization, such as the CEO or department manager. This seems like it could be used to specify the sales manager, who is the leader of the sales department, or to specify employees of the sales department other than the sales manager.
Once you’ve set it up, let’s compare it with the example.
+ Setting example
Let’s look at how a sales representative, a sales manager, and an employee in the management department can each be set up.
Sales Representative
Users who belong directly to the Sales Department, excluding the Sales Manager, are specified.
The organization assumed in this tutorial currently has no members belonging to organizations subordinate to the Sales Department, but if there were, you could specify users for the entire Sales Department who do not have a [Job Title] set by also specifying “Members (without Job Title) who belong to organizations subordinate to the organization “20 Sales Department”.
Note that the user who can start the process is the process manager for the swimlane with the start event, so the process for this app will be the user specified as the sales representative.
Sales Manager
Since only the sales manager needs to be specified, we specify a user with [Position: Leader] who directly belongs to the Sales Department.
The only [Position] set in this tutorial is “Leader,” so it is fine to specify a member with a Position.
Employees in the Management Department
The target is employees who belong directly to the Management Department, including the Administrative Manager. If you want to exclude managers, select “(No position)”.
Currently, there are no users who belong to organizations subordinate to the Management Department, but if there were, you could also specify “Members who belong only sub organizations of this “10 Management Department” to specify all users under the Management Department.
Set the Data Items
The last step is to set the data items. What data items will be required to process the Order Approval workflow?
First, the order details and order amount are required as order information. Next, it would be good to write down the expected order date and the employee in charge. For order source information, the company name, address, name of person in charge, and contact information for the person in charge (phone number, email) are required, and it seems that a field for writing the results after checking with the order source is also necessary.
So far we have looked at character, numeric, date, datetime, and user type data items, but which ones would be appropriate to use to represent the data items for this workflow?
What other data items might be needed?
Once you have identified the necessary data items, set the layout of the input form while remembering Chapter 6. Don’t forget to set whether each data item can be edited.
Once you have that set up, let’s compare it with an example.
+ Setting example
Almost all data items to be filled by sales representatives are required items. However, phone number is not set as required in case the sales representative only communicates via email or video call and does not know the phone number. Required data items must be set as “editable” in tasks in order for the processing of the task to be possible. Therefore, please do not make data items required if there is a possibility that they will not be entered.
The Remarks column is created using a Discussion type data item. In the discussion type, when a sentence is entered, the sentence is appended with the entrant and the date and time of entry. The added text cannot be changed. Therefore, it can be used to record the communication between the members related to the case.
Editability for each data item is set as follows.
| Register Order | Order Approval | Edit Registration Details | New Order Source Inquiry | |
|---|---|---|---|---|
| Order Details |  (Editable) |  (Display only) | (Editable) | (Display only) |
| Order Amount | (Editable) | (Display only) | (Editable) | (Display only) |
| Expected Order Date | (Editable) | (Display only) | (Editable) | (Display only) |
| Sales Representative | (Editable) | (Display only) | (Editable) | (Display only) |
| Ordering Company Name | (Editable) | (Display only) | (Editable) | (Display only) |
| Ordering Address | (Editable) | (Display only) | (Editable) | (Display only) |
| Ordering Person’s Name | (Editable) | (Display only) | (Editable) | (Display only) |
| Ordering Person’s Email Address | (Editable) | (Display only) | (Editable) | (Display only) |
| Ordering Person’s Phone Number | (Editable) | (Display only) | (Editable) | (Display only) |
| Order Source Inquiry Results |  (Hidden) | (Display only) | (Display only) | (Editable) |
| Remarks | (Editable) | (Editable) | (Editable) | (Editable) |
To prevent accidental changes when checking the input information, the information is only displayed to users who need to enter or edit the information.
The input form for the task of registering an order case looks like this:
The Order Source Inquiry Results are not entered or referenced in the Register Order task, so they are hidden.
Have you set up the workflow diagram, operators, and data items to match the operations you envisioned?
Once you get this far, then you can repeat the process of actually creating and modifying the workflow application. For example, if you want the sales manager to be able to trigger the Order Approval app, in the operator settings for the swimlane “Sales Representative”, where it says “Members belonging to organizations lower than the organization “20 Sales Department” (No Position)”, you can leave [Position] blank to allow the sales manager to start the process.
Create a variety of apps and improve them to suit your business and organizational situation. Once you have reached this point, you can repeat the process of actually creating and modifying the workflow apps. Please try making various apps yourself.
This concludes the tutorial. We got there in the end!
We have introduced the basic operations and functions of Questetra BPM Suite, how was it? Let’s try to automate and visualize your daily business processes by utilizing Questetra BPM Suite!
In the next page, we will introduce useful information for creating, improving, and operating workflow applications, such as functions that make Questetra even more useful, as an appendix, so please take a look if you are interested.
chevron_forwardAppendix: Documents Useful for Creating and Operating App
chevron_backwardChapter 8: Automated Processing in the Middle of a Workflow