I write blog posts like this one and post it to the company’s contents management system, but I am struggling to do it since I am rather lazy.
Will the time come when once I provide materials of an article to a robot, it will automatically finish them into a blog post nicely? (I wish it will come…)
Never being discouraged, I will be working on various “work automatisation“!
Well, continuing from last time, I am introducing the “Cool(?) Questionnaire management system”.
Let’s Create a Cool(?) Questionnaire Management System! (1)
…This time, I would like to introduce an App which is capable of implementing a medium-sized questionnaire and manage it.
I am going to try to automate as much as possible aiming to reduce the burden of implementation/management work.
As my explanation will be long, so I will write it in a series of two articles.
This time, I’ll talk about “Questionnaire answer management“.
Now, rolling up my sleeves, I will continue!
＜Image figure of the flow from questionnaire preparation to answer management＞
Although it will have a recap of the previous post, it will be mainly about
* Answer check
in the above figure. (The range inside the blue dotted line)
What you need to prepare is only
* List of target respondents (Name, email address)
* Questionnaire request start date
* Response Dunning Interval (Days)
Based on these, you will only wait for status notification from your robot.
Business flow Explanation
I will divide it into 5 blocks and explain them.
(Please skip if you know this already.)
It will be easier to understand if you download the archive of the App (Process Model) and watch it in the Modeler while reading the explanation.
Download: Questionnaire request-Answer dunning management.qar
0) Entry of questionnaire respondents information
＜Example of input screen at the Step of “Input Questionnaire info”＞
The input form looks like the above image.
Only enter the information I mentioned before.
1) Delivery of questionnaire request email
The Steps until delivery completion are as follows.
2. Calculate the number of requests from the questionnaire respondents list.
3. Process the information (such as name and request URL) to be set in the email.
4. Set remaining transmission count
5. Transmit emails (using Throwing Message Intermediate Event (Email))
6. Check the remaining number of transmissions, if 0, go to the next process, if more than 1, go back to #3
To be accurate, the steps of 3 and 4 are carried out simultaneously at the auto-step of “Destination Set (Respondents)”.
The main point is
Even though it is called “Process”, it is not an auto-step merely to set in Throwing Message Intermediate Event (Email).
That is, when setting the URL to guide to the questionnaire, it is necessary to set “name” and “email address” as a parameter. In order to extract “name” and “email address” from the “questionnaire respondent list” and set it, you have to solve the URL encoding problem.
* Infos , infos  is the name / email address information extracted from the questionnaire respondents list
＜Data item set for the parameter of the questionnaire URL＞ above is an example of corresponding.
By using encodeURIComponent(), it makes it possible to receive parameter contents without garbling on the questionnaire App side.
(Decoding processing is necessary on the questionnaire App side.)
＜Setting example of Questionnaire request email: Throwing Message Intermediate Event (Email)＞
＜Example of Questionnaire request email＞
2) Creation of Answer dunning list
As the request for the questionnaire has been delivered, answers will be made via the web form at URL written in the email, one by one.
At this step, a processing of seeking “Unanswered respondents” is carried out
(using Add-on XML.)
2. Query the “Questionnaire” App to be surveyed from the applicable email address by the API
3. Store in the Unanswered list if a respondent is marked as unanswered by the search result
4. Go back to#1 until the questionnaire answer list becomes empty
The Add-on XML has been implemented with the steps above.
(The code is omitted here because it is so long, please download it and refer to it.)
The necessary set up is as follows.
＜Auto-step Config: “Qestionnaire answer check”＞
The API dealing with
3) Delivery of Answer dunning email
Now, we are going to work on “deliver dunning email” in
It can be done by performing almost the same processing as “1) Delivery of questionnaire request email”, since the delivery list has been created already at the step of “2) Creation of Answer dunning list”.
Also in the email body, you can use the content of embedding of request email as it is.
By changing only the fixed wording, you can urge “dunning for response”.
4) Modification of dunning info
If there is no processing of this block, the automatic processing which no person intervenes will continue to run completely automatically until all people have answered.
However, in conducting the questionnaire management, you cannot deal with it properly when, for example,
* Want to adjust the dunning interval on the way. (e.g.: I want to strengthen dunning by decreasing interval days), etc.
In order to solve this problem, a human Task “Modify respondent” step is prepared in parallel with the block of questionnaire answer dunning.
At the “Modify respondent” step, it is assumed that “dunning target person” and “dunning interval” need to be adjusted.
The contents changed in the “Modify respondent” step are not reflected during standby for the dunning date. (Timer Intermediate Event “Dunning date”)
It will be reflected while the next standby for dunning date.
Supplement Concerning API Usage
I explained that “API (/API/OR/ProcessInstance/list)” is used in “2) Creation of Answer dunning list“. I will talk a bit more about that.
The API can run a query by setting query information (XML) in the criteria parameter.
For inputs to query information, it will be mainly the following.
* Definition number of the Data Item in which the target email address is stored
If you catch one in the result of this search, you can take it as “answered”.
(Since the answer is entered in the Message Start Event (Form), it is not necessary to look at the state.)
is able to be retrieved from the URL of the questionnaire. (Entered at “Input Q info” step.)
* The definition number of the Data Item in which the target email address is stored may differ dynamically according to the questionnaire App.
However, it is a necessary Data Item as long as you use this mechanism.
You can deal with this by creating a template of the questionnaire application, copying it and changing only the question items.
I’m afraid that the explanation has been too long. (And it has continued over two posts.)
Despite this, I suppose that there is no need to make big modifications to use it in your environment.
* Settings of environment-dependent information (such as URL of your use environment and access information)
And all is configured on Questetra. (No need to touch the Script.)
As I mentioned in “Part 1”, I suppose you can easily implement/run this mechanism as long as it is for:
(E.g. in-group limited questionnaire, etc.)
* To make sure they answer (keeping track of who has not replied yet).
Even though it was a long explanation, there still are parts that I omitted.
If you have any questions, please feel free to contact us.
Once again, I provided downloadable archives of the Apps, here.
Questionnaire request-Answer dunning management.qar
201710-Survey for Network utilization.qar
|Prev article - 50. Questetra Tips||Let's Create a Cool(?) Questionnaire Management System! (1)|
|Next article - 50. Questetra Tips||Reliable for Large-scale Organizational Change! Method for Realizing Automatic Release|
|Another article - Masato Furukubo||How to do Multilingual Support of a Process Data Item Name in the Input Screen?|