
Hi there!
Today, I would like to talk about how to utilize the Receive Task, a new feature added to version 11.7.
v11.7 2018-06-11 Equipped the Open Form that Receives Entry in the Middle of Workflow
Questetra already has a function for receiving applications from people outside of the system, the Message Start Event (Form). For the details of this feature, please see the following page.
M220: Auto Starting Triggered by Published Web Form Entry
The Receive Task (Form) provides an input form to people outside the system in the same way as the Message Start Event (Form). However, it differs from the Start Event in that it can be placed in the middle of a Process.
Now, we are going to create a simple Workflow App for receiving applications using a Message Start Event. However, we will use a Receive Task (Form) to confirm the existence of the applicant’s email address on the way. The Steps are as follows:
#1. Have an applicant input an email address at the Message Start Event (Form)
#2. Send an email to the email address entered at #1 to inform of the URL in #3
#3. Let the applicant input the rest of the information in a Receive Task (Form)
#4. The Human Task is something additional
The list of Data Items is as follows. The Title is not used.
Data Item Name | Data-type | Required | Start Event (Form) |
Receive Task (Form) |
Human Task |
---|---|---|---|---|---|
Title | – | – | – | – | Only display |
Email address | String-type single line |
〇 | Editable | Only display | Only display |
Name | String-type single line |
〇 | – | Editable | Only display |
Form key | String-type single line |
– | – | – | Only display |
Initial value
#{#randomString(20)} |
Form key must be selected in the API key field of the Receive Task (Form).
Form key is a string of 20 random characters that is different for each Process, depending on the Initial Value setting. If this is set to a fixed value, the URL of the third Step can be easily inferred, so there is a concern that email addresses entered in the first Step could be leaked to a third party.
Lastly, set up the Throwing Message Intermediate Event (Email) at the second Step.
The point here is to transmit the URL for the third Step.
That is, since only the person who receives the email knows the URL for the third Step, it works as confirmation of the existence of the email address.
Destination |
${[Email address:0]} |
---|---|
Subject | Thank you for applying |
Body | |
Please access the following URL, and enter the rest of required information. ${var[applicationRoot]}System/ReceiveTask/Form/1760/2/${[ProcessID]}/${[Form key:2]}/view |
In this current scheme, there is no deadline for the third Step.
It would be better to treat the application as cancelled if it is not processed within a certain period of time.
I would like to cover that on another occasion.
Pingback: Phone Number Verification through Web Form Application – Questetra Support
Pingback: How to Utilize Receive Task (Form) – Set a Deadline for Application Form (Revised edition) – Questetra Support
Pingback: Receive Task (FORM) – Questetra Support
Pingback: How to Utilize a Receive Task (Form) – Set a Deadline for an Application Form – Questetra Support