Let’s Create a Cool(?) Questionnaire Management System! (2)

I will introduce a realization example of a mechanism which is a published webform screen using the Message Start Event (Form), and induction/answer management to the questionnaire using automation (Add-on). [Questionnaire Management Implementation]

Hi, there!

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

* Transmit questionnaire
* Answer check

in the above figure. (The range inside the blue dotted line)

What you need to prepare is only

* URL of the corresponding questionnaire
* 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

<Workflow diagram>

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.

1. Stand by until delivery date and time (using Timer Intermediate Event to pause its progress)
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

3. Process the information (such as name and rrequest URL) to be set in the email

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 [0], infos [1] is the name / email address information extracted from the questionnaire respondents list

<Data item set for email embedding>
<Data item set for parameter of the questionnaire URL>

<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

Deliver a dunning email to respondents who have not answered yet.

(using Add-on XML.)

1. Read the questionnaire respondents list (request email distribution target person) line by line
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.)
Download: confirmAnswers.xml

The necessary set up is as follows.

<Auto-step Config: “Qestionnaire answer check”>

The API dealing with

2. Query the “Questionnaire” App to be surveyed from the applicable email address by API

“Querying for all Process Instances records (/API/OR/ProcessInstance/list)” < Monitoring API < Workflow APIs is utilized.

3) Delivery of Answer dunning email

Now, we are going to work on “deliver dunning email” in

* Deliver a dunning email to respondents who have not answered yet.

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,

* People who should not be able to answer, did
* 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.

* App ID of target questionnaire (to be exact, process-model-info-id)
* 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.)

* App ID of target questionnaire (to be exact, process-model-info-id)

is able to be retrieved from the URL of the questionnaire. (Entered at “Input Q info” step.)

https://XXX.questetra.net/System/Event/MessageStartForm/{App ID}/0/XXXXXXXXXXXX/view

* 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.

* Review of wordings in each email
* 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:

* Closed questionnaires oriented to set targets (up to 100 people)
(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 management>
Questionnaire request-Answer dunning management.qar
<Questionnaire App>
201710-Survey for Network utilization.qar


About Masato Furukubo

Questetra, Inc. Sales Department
View all posts by Masato Furukubo

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?