e-Forms Process Documentation - MITA Home€¦ · · 2012-03-28Public eForms Main Process...

Malta Information Technology Agency, Gattard House, National Road, Blata l-Bajda HMR 9010 Malta Telephone: (+356) 21234710 Facsimile: (+356) 21234701

Web Site: www.mita.gov.mt

e-Forms Process Documentation

Date: 21/02/2012

Version: 1.0 Unit: eGov Architecture Department: eGov DEO

Public

Public eForms Main Process Documentation

Page i

Document Control Information

01. Document reference

eForms-REP-eformProcessDocumentation-v1.0.doc

02. Document type

Procedure

03. Security classification

Public

04. Synopsis

This documentation provides details how to make use of the eForms Main Process

05. Document control

Author Change controller Distribution controller

eGovernment Department eGovernment Department eGovernment Department

06. Modification history

Version Date Comments

Draft 0.1 29/11/2011 Draft version for internal review

Version 1.0 21/02/2012 First version for release


File Name: Security Classification: Page:

eForms-REP-eformProcessDocumentation-v1.0.doc Public 1 of 29

Table of Contents

DOCUMENT CONTROL INFORMATION .................................................................................................................................. I

TABLE OF CONTENTS.............................................................................................................................................................1

01. INTRODUCTION ..........................................................................................................................................................1

02. SCOPE .........................................................................................................................................................................2

03. PROCESS CUSTOM FUNCTIONALITY ......................................................................................................................3

03.1 PROCESS TIMELINE ....................................................................................................................................................3 03.1.1 How the LO timeline progresses .....................................................................................................................3 03.1.2 User’s mailbox .................................................................................................................................................6

03.1.2.1 Stage ID.........................................................................................................................................................................6 03.1.2.2 Process textual status....................................................................................................................................................7 03.1.2.3 Setting the subject manually in the initial form ..............................................................................................................9 03.1.2.4 Setting the subject automatically in the initial form......................................................................................................10

03.2 INITIAL FORM ............................................................................................................................................................11 03.2.1 Setting the initial form ....................................................................................................................................11 03.2.2 Setting the initial form to load automatically ..................................................................................................11 03.2.3 Validating the form from the server-side........................................................................................................12

03.3 PERFORMING PAYMENT ............................................................................................................................................13 03.3.1 Verifying whether the payment has been already performed ........................................................................13 03.3.2 Verifying a manual payment ..........................................................................................................................13 The Manual Verification form offers the backend user two options; either to verify that the payment was successfully made (index 1) or else to reject the payment (index 2). The above code, which is triggered as soon as the backend user submits the form, handles the option selected by the back office user and sets the next path to follow in the process accordingly. ........14 03.3.3. Verifying payment using MyBills ....................................................................................................................14

03.4 BACK OFFICE FUNCTIONALITY....................................................................................................................................18 03.4.1 Setting up approval and rejection paths ........................................................................................................18 03.4.2 Looping through rejections ............................................................................................................................20

03.4.2.1 Payment Stage ............................................................................................................................................................20 03.4.2.2 Vetting Stage ...............................................................................................................................................................21 03.4.2.3 Approval Stage ............................................................................................................................................................22 03.4.2.4 Committee Stage .........................................................................................................................................................22

03.5 EMAILS AND MESSAGES ............................................................................................................................................24 03.5.1 Branded emails to users and work queue using the email task ....................................................................24

04. FURTHER ASSISTANCE...........................................................................................................................................26




01. Introduction

The Liquid Office Process formerly known as LO process is the process which defines all the stages that the form needs to bypass till it is approved. In order to explain how this process works a timeline has been created. This timeline is used to show the progression of all the stages and their possible outcomes. In this document the progress timeline is defined using an illustration hence the developer will be guided how the form is to proceed until it reaches its approval or rejection stage. These process timeline guidelines are to be instructed using explanations, illustrations as well as code snippets.




02. Scope

This document describes the Form LO Process. This process is based on a simple flow where an application is submitted and eventually approved. In this document the LO Process is described by stating how the timeline progresses and how the initial form is set and validated. The steps of how the user can perform a payment are described and what happens in the background to verify the payment. In addition, back office functionalities are explained and finally the process of how to handle emails and messages are defined.




03. Process Custom Functionality

03.1 Process Timeline

03.1.1 How the LO timeline progresses

Once the e-form is submitted, it is passed on to the stage where it will be validated. At this stage an exception object is created which will break the process. The form will execute the validations, reset the exception status while it will pass through a loop which will automatically reset the status of the Validate Form to READY. After that the form will be validated again. If another exception is generated the steps below (The validation stages) will be repeated again.

The validation stages

If no exception is raised during the validation, the progress status is updated from the application stage. The progress status is included in the process subject whenever the form is saved or placed in the user’s mailbox. In the following example the form is passed to the Payment Form as shown in the figure below.

Amend Progress Status from the application stage

Once submitted the form will pass to the

validation stage




In the payment form, the applicant chooses the payment type. If the applicant opts for a manual payment, then the progress status is updated. The payment would then have to be vetted manually by a backend office user using the Manual Payment Form. The process flow for a Manual Payment is very straight forward to implement and it requires little additional logic to be implemented in the process scripting. On the other hand if the payment is to be done using MyBills (i.e. online payment using debit or credit cards) the user is directed to the Hosted Payment Page (HPP). After performing the payment the process is to determine whether the payment was successful or not. When an online payment is unsuccessful, the applicant is notified through an email and given instructions to resubmit the card payment details. These stages will be repeated until the payment is successful or the payment times out, as shown below. The configuration and code for the payment is further discussed in Section 3.3.

Stages to carry out a Payment

Following a successful payment an email is sent to the applicant, and a PDF copy of the form is posted to the user’s mailbox while control of the form is transferred to the Competent Authority. At this stage an e-mail is sent to the Authority’s vetter to notify the form submission in order for the process to copy the form and proceed to the vetting stage. At Vetting stage, the application can take one of 3 routes:

• If it is rejected, an email containing the rejection message is sent to the applicant. The progress status is updated to a stage where the application is final and the workflow stops ;

• If the form requires corrections or further attachments, it is returned to the applicant to resubmit the same form.

• If it is accepted, it proceeds to the next stage and the status is updated. The applicant might withdraw the form or resubmit it. If the application is to be either totally rejected or approved, the applicant is to receive either the rejection or the approval message. All these steps are shown below.




Vetting / Approval stages

Following the approval stage, there might be the case that the application needs to pass to the committee stage. If this is the case then, following the approval message, an email is sent to the Competent Authority’s Committee work queue in order to notify them that the application requires their attention. The progress status is changed i.e. the form enters the Committee Stage. Consequently the form is passed to the backend workqueue approval task. The next stage would be to identify whether the application has been approved from the committee stage or not. On approval an approval message is sent. On rejection a rejection message is sent. This part of the workflow is illustrated in the illustration below.




Committee stage

03.1.2 User’s mailbox

03.1.2.1 Stage ID

The user’s mailbox is the mailbox which is accessed by the applicant on login on the eForms portal. It holds the applications on the different stages of the application from submission to approval. An example of the mailbox would be as seen in the figure below.




Figure 01 – User’s mailbox (an example)

The mailbox parses the “subject” to display the information to the applicant. In the example below the status is given the id 9999:

ProcessTitle + " ID: " + IDNumber + " Ref: " + FileReference + " Status: " + ProcessName + "9999"

The status codes may vary for the different workflow stages. Each code is registered in the Process Timeline table for each process. The other parts of the subject are automatically determined by the form on loading as follows:

• ProcessTitle is loaded from the parameter store • IDNumber is copied from txtAppIdNo; and • the FileReference is copied from txtFileReference.

03.1.2.2 Process textual status

The process status is obtained from the hidden field named hdnProcessStatus. This status can be set manually




Setting the Progress Status Options

String progressStatusOptions = "{"+ "'1':{'Vetting':'application'," + "'Approval':'application1'}," + "'0':{'Approval':'Committee'," + "'Vetting':'Approval'," + "'':'Vetting'," + "'retToAppFailedPayment':'Vetting'" + "'application':'Vetting'," + "'application1':'Approval'}" + "}"; thisProcess.setFieldValue("hdnProgressStatusStructure", progressStatusOptions); As shown in the code above the variable progressStatusOptions is declared. This variable is to hold the process status according to how it is set i.e. either 1 or 0. Following that the hidden field named hdnProgessStatusStructure is to be set according to the progressStatusOptions defined. This is explained in detail below.

03.1.2.2.1 Progress status options

The progressStatusOptions variable is a JSON object which maps a path in the process timeline with a current process state and its subsequent stage. The process status options should have a numerical number that represents the path taken by the process. For simplicity, in this example they have been set to ‘1’ (return to applicant) and ‘0’ (approve). The following table explains the progress status options available. Progress Status Option Present Status Name Next Status Name

1 Vetting Application returned to applicant (In case application needs updates)

0 Vetting Approval stage 1 Approval Application returned to

applicant (in case of rejection)

0 Approval Committee stage 0 Applicant submits form the first time Vetting stage 0 Applicant resubmits form after rejected

at the vetting stage. Vetting stage

0 Applicant resubmits form after rejected at the approval stage.

Approval Stage

Setting the progress status structure would allow the form/ process logic to update the status of the form (contained in the hdnProcessStatus field) according as the form progresses. The real value for this is in scenarios where the same form can be accessed at different stages of the process but needs to behave differently. Taking the above code as an example, path 0 is the approved path while path 1 is used for returning the application back to the applicant. With this in mind, the process progresses in the following way:




Current Status Action Path to take New Status ‘’ Submit Application 0 Vetting Vetting Return to Applicant 1 Application Application Submit Application 0 Vetting Vetting Approve 0 Approval Approval Return to Applicant 1 Application 1 Application 1 Submit Application 0 Approval Approval Approve 0 Committee The above steps display a normal flow of events whereby the application is submitted for approval, is returned to the applicant for clarification or further details/attachments and is finally approved and sent to the committee stage. In this example, the applicant accesses the same application form on three different occasions; once during the initial application phase, once after it has been returned from the Vetting stage, and another time when it has been returned from the Approval stage. In order for the form to appear in the correct mailbox and at the correct stage on the process timeline, the process stage has to be updated accordingly and allow the form’s subject also to be updated accordingly. The process structure could be set in two locations; either in the process or else in the form itself. However, since the JSON structure depends on the paths to be known, it is advisable to set these at the process level so that if one of the paths should change, and, hence, the progress structure needs to be refreshed, it would be sufficient to republish only the process rather than both process and form. It is advised to keep the same path number for progressing, for sending back to the user, and for rejecting the application, throughout the whole process as this makes the JSON structure easier to create and maintain. However, provided than you map the paths correctly between the old and the new status, the automatic progression of statuses would still work. 03.1.2.3 Setting the subject manually in the initial form

The subject of the email which is sent to the applicant can be set manually in the initial form using the code below.

Process Status from the hidden field String ProcessStatus = thisProcess.getFieldValue("hdnProcessStatus"); String subject, subjectTemplate; Object stageID; if((ProcessStatus.equals("application"))||(ProcessStatus.equals("application1")) || (ProcessStatus.equals("retToAppFailedPayment"))) { stageID = "9999"; } else { stageID = "0001"; } In the code above the Process status is obtained from the hidden field named hdnProcessStatus. The process status will indicate if the application has, at some point, been redirected to the client for more information as follows: Process Status ID in this example

Has it been re-submitted Effect

0001 This is the first time Unless the form is submitted, the form will be displayed in the mailbox as a draft.




9999 Application had been returned during vetting or approval

1.) The comments page within the form will have a comment from the back-office stating the reason why the form was returned. 2.) The form will appear in the attention required mailbox. 3.) The user will have the submission date and reference already filled in and can be referenced. 4.) Depending on the business logic, the reference date can be changed on re-submission.

The subject template is determined using the internal parameter ‘progressTaskSubjectTemplate’ and formatted according to the template initially set. Hence the subject is determined. 03.1.2.4 Setting the subject automatically in the initial form

The subject of the email which is sent to the applicant can be set automatically in the initial form. This is performed by following the steps below.

The first step is to right click on the Progress Status from Application Stage in the process studio process timeline illustration and choose the Task Properties option. The Progress Status Properties is shown in Figure 02.

Figure 02 – Setting the Progress Status ID The property refers to the Progress Status ID of the particular stage within the process, which should be configured in the ProcessTimeline table. The subject is then automatically created using a common template configured in the parameter store.




03.2 Initial form

03.2.1 Setting the initial form

MITA Form refers to the standard template. The MITA Form is set as the initial form to load using the following steps. The first step is to right click on the MITA Form in the process studio process timeline illustration and choose the Process Properties option.

The window below appears and the Initial tab is chosen. The Instantiate Process Before Displaying Form is selected while the Initial Task is set to MITA Form -1 as shown in Figure 03.

Figure 03 – Setting the initial form 03.2.2 Setting the initial form to load automatically

Besides being set at the initial form, the MITA Form is also set as the initial form to load. This initialisation is performed using the following steps. The first step is to right click on the MITA Form in the process studio process timeline illustration and choose the Task Properties option.

The window below appears and the Form tab is chosen. The Automatically Display Next Form on Submit is should be ticked as shown in Figure 04.




Figure 04 – Setting the initial form to load automatically 03.2.3 Validating the form from the server-side

The MITA Form needs validation to verify if it has been correctly filled in. This verification uses the same XML schema that is applied for validation. The first step is to right click on the Task Properties in the process studio process timeline illustration and choose the Validation Properties option.

Figure 05 – Setting the form validating properties




When List is clicked all the forms which can be validated are loaded from the Liquid Office Store. The form chosen for validation is selected from the Forms list. 03.3 Performing Payment

03.3.1 Verifying whether the payment has been already performed

The first step following a valid submission is to verify whether the payment has been performed or not. These stages are implemented using the function below.

Implementing the payment verification workflow void enteredActive(State state) { //check whether there is a payment String opt = thisProcess.getFieldValue("hdnOptChosen"); if (opt.equals("3")) { if(Payment.checkMyBillsPaymentFromProcess(thisProcess, thisConnectAgentManager, "eForms").equals("authorised")) { thisTask.setDefaultSelectedIndex(1); } else { thisTask.setDefaultSelectedIndex(0); } } else { if (Payment.checkManualPaymentFromProcess(thisProcess, thisConnectAgentManager, "eForms")) { thisTask.setDefaultSelectedIndex(1); } else { thisTask.setDefaultSelectedIndex(0); } } } The following is an explanation of what happens behind the scenes. As soon as the payment task becomes active the choice of the user’s payment method is obtained using the hidden field hdnOptChosen. Whether the applicant chooses to use MyBills or chooses to submit a manual payment, a check is performed to determine whether the payment has been submitted and approved or not. If the payment had been successfully submitted and approved, the application would be sent to the vetting stage. Otherwise the application would be redirected to the payment page while the applicant would submit the payment for verification. In the code above, the indexes “1” and “0” used as assignment values for the thisTask.setDefaultSelectedIndex method and the actual path indexes in the process timeline. These may differ from one process to another so these have to be set accordingly. 03.3.2 Verifying a manual payment

The first thing performed after the form is validated and submitted, is verifying whether the payment has been successfully submitted or not. In case the payment has not yet been submitted and approved, the application process would expect this to occur. Hence, in case the applicant chooses to submit a manual payment, the application would expect a cheque, a bank transfer or to submit the payment using online banking. At this point an email is sent to the person responsible of verifying the payments to verify that the payment is




correct. If the payment is confirmed as correctly submitted then the applicant is allowed to continue to the next step, otherwise it is sent back to the applicant for modifications. The following code is responsible for these steps.

Implementing the manual payment verification workflow void enteringDone(State state) { AssignmentList al = thisTask.evaluateAssignmentInstruction(); thisTask.setAssignment(al); String choices = thisProcess.getFieldValue("ddlPaymentStatus"); if (choices.equals("1")) { // successful manual payment thisProcess.getTaskByName("Payment Successful").setDefaultSelectedIndex(1); } else if (choices.equals("2")) { // unsuccessful manual payment thisProcess.getTaskByName("Payment Successful").setDefaultSelectedIndex(2); thisProcess.setFieldValue("hdnProcessStatus", "retToAppFailedPayment"); } } The Manual Verification form offers the backend user two options; either to verify that the payment was successfully made (index 1) or else to reject the payment (index 2). The above code, which is triggered as soon as the backend user submits the form, handles the option selected by the back office user and sets the next path to follow in the process accordingly.

03.3.3. Verifying payment using MyBills

In case payment is submitted using MyBills there would be no person assigned to approve the payment since MyBills takes care of this. However, it does need to determine whether the payment was successful or not in order to decide which path to take following the payment. In the example illustrated in this document, the MyBills payment works in the following way:

1.) The applicant is redirected to the Payments page soon after submitting the application form 2.) The applicant selects MyBills as his payment method 3.) The MyBills page opens up in a separate window as soon as the applicant submits the

payment form. 4.) The user performs the MyBills payment while, in the background, checks whether the

payment has been successfully. 5.) The payment check iterates until either the payment in found and is successfully, the payment

is found and is not successful, the payment is not found and a specified timeout expires. The rest of this section explains the code that makes up the Payment checking process. The payment submission screen has a maximum duration set to it, which will determine when the process stops looking for a payment and assume that the payment has not taken place. The maxDuration variable is initiated in the CommonBeanShell when opening the screen editor. In this example, this timeout is set to 2 minutes, i.e. 120000 milliseconds. In a production environment, this should be set to a reasonably longer timeout in order to allow the applicant the time to perform the payment.

Implementing the manual payment verification workflow void enteringDone(State state) { AssignmentList al = thisTask.evaluateAssignmentInstruction(); thisTask.setAssignment(al); String choices = thisProcess.getFieldValue("ddlPaymentStatus");




if (choices.equals("1")) { // successful manual payment thisProcess.getTaskByName("Payment Successful").setDefaultSelectedIndex(1); } else if (choices.equals("2")) { // unsuccessful manual payment thisProcess.getTaskByName("Payment Successful").setDefaultSelectedIndex(2); thisProcess.setFieldValue("hdnProcessStatus", "retToAppFailedPayment"); } }

The next series of code is situated in the enteredActive event handler for the MyBillsVerificationScript Scripting Task. The code below takes care of the basic step of the MyBills payment approval. Three (3) variables were initiated namely the paymentStatus to hold the payment status, the branchName to hold the text shown when the payment is successful or not and the paymentDateFieldName to hold the value of the hdnDatePaymentVerified.

Implementing the verification of a payment using MyBills (1st part) try { String paymentstatus = ""; String branchName = "Payment Successful"; String paymentDateFieldName = "hdnDatePaymentVerified"; Calendar dtStartDate; String startDate = thisProcess.getFieldValue(paymentDateFieldName); log.info(startDate); Long startDatelong; In order for the MyBills to be safely implemented a variable containing the maximum duration was initially set in the process. The user needs to submit the payment information in the specified time else the payment task is aborted. The first step would be to initiate a Calendar variable which would hold the current submission’s date and time. Then the variable startDate is initiated holding the field value as found in the hidden field named hdnDatePaymentVerified. The value found in the hidden field is to be logged accordingly.

Implementing the verification of a payment using MyBills (2nd part) if (startDate == null || startDate.length() == 0) { log.info("Start date is empty"); dtStartDate = Calendar.getInstance(); startDatelong = dtStartDate.getTimeInMillis(); thisProcess.setFieldValue(paymentDateFieldName, String.valueOf(startDatelong)); log.info("Set new date : " + String.valueOf(startDatelong)); }




On first check of the MyBills payment submission, the date is not yet set, i.e. it is null, hence the code above uses the Calendar object to get the current time in milliseconds in the hdnDatePaymentVerified field. Following this first iteration, the process will loop until the payment is either found or the timeout expires. The expiry is determined according to whether the difference between the first recorded time and the current time is greater than the maximum duration initially set in the maxDuration variable. When the difference is greater than the value in the maxDuration, then the payment verification will terminate and an email would be sent back to the applicant to state that the payment was not completed successfully. The applicant would then be able to access his form again and resubmit the payment. In case the difference is smaller than the value in the maxDuration, the payment status is checked. If the payment status is found to be null or empty, then the payment verification would loop and start the verification again. In case the status is set to initialised or in progress, then the application would also reiterate until the payment is either authorised or rejected. In case the payment is authorised, the process will proceed to the next stage. Otherwise, if the payment was rejected, an email is sent back to the applicant stating that the payment was not completed successfully.

Implementing the verification of a payment using MyBills (3rd part) else { log.info("Start date is NOT empty"); long stdatemill = Long.parseLong(thisProcess.getFieldValue(paymentDateFieldName)); Calendar now = Calendar.getInstance(); long curdatemill = now.getTimeInMillis(); long diff = curdatemill - stdatemill; log.info("Difference: " + diff); if (diff < maxDuration) { log.info("Difference is smaller than max duration"); paymentstatus = Payment.checkMyBillsPaymentFromProcess(thisProcess, thisConnectAgentManager, "eforms"); if ("".equals(paymentstatus) || paymentstatus == null) { thisProcess.getTaskByName(branchName).setDefaultSelectedIndex(0); } else { if ((paymentstatus.equalsIgnoreCase("initialised")) || (paymentstatus.equalsIgnoreCase("inprogress")) || (paymentstatus.isEmpty())) { thisProcess.getTaskByName(branchName).setDefaultSelectedIndex(1); } else if ((paymentstatus.equalsIgnoreCase("authorised"))) { thisProcess.getTaskByName(branchName).setDefaultSelectedIndex(0); } else { thisProcess.getTaskByName(branchName).setDefaultSelectedIndex(2); } }




} else { thisProcess.getTaskByName(branchName).setDefaultSelectedIndex(2); } } The sample code for the myBills payment can be used and easily adapted for other processes. The things that would need to be amended are as follows:

1.) The expiry interval of 2 minutes not be deemed enough for the payment to take place 2.) The branch name for the branch which determines the path to take after the payment

verification has taken place 3.) The branch path indexes




03.4 Back Office functionality

03.4.1 Setting up approval and rejection paths

Paths are set up both in case of approval and in case of rejection of each stage. Such stages would be the Vetting, Approval and Committee. All of the paths are illustrated below.

Figure 06 – Approved from vetting paths

Figure 07 – Approval paths before passed to committee stage




Figure 08 – Committee approval paths

In order to set these approval / rejection passes, the branch paths need to be accessed from the task properties as found by right clicking on each branch. The branch paths are to be set as seen in the figure below.

Figure 09 – Branch paths for the committee approval




03.4.2 Looping through rejections

There might be three (3) rejections when it comes to the process timeline. The rejections might be:

- At Payment stage - At Vetting Stage - At Approval Stage - At Committee Stage

03.4.2.1 Payment Stage

The first rejection loop to take a look at is the one at the Payment Stage. As soon as the payment is declared as not being successful, an email is sent to the applicant to notify him as shown below.

Figure 10 – Illustration of the path taken in case of an unsuccessful payment

Besides that the applicant is given the opportunity to resubmit the form as shown in the illustration below

Figure 11 – Illustration showing that notifying that the payment was unsuccessful, the applicant is given the opportunity to resubmit the form




03.4.2.2 Vetting Stage

On rejection at the vetting stage an email is sent to the applicant as shown in Figure 12.

Figure 12 – Illustration showing that notifying that the payment was unsuccessful, the applicant is given the opportunity to resubmit the form

The form is returned to the applicant in order for the applicant to resubmit the application as shown below.

Figure 13 – Rejection at the vetting stage




Figure 14 – On rejection the applicant is given the opportunity to resubmit the form 03.4.2.3 Approval Stage

At the approval stage the form can either be approved or rejected as shown in the illustration below. On rejection a message is sent to the applicant informing him that the application has been rejected. This stage was highly simplified in the below illustration. During implementation it is important to implement the return to applicant functionality and any relevant Form Copies which are not illustrated here for simplification.

Figure 15 – The two paths which can be taken at the approval stage

03.4.2.4 Committee Stage

At committee stage the form can either be approved or rejected as shown in the illustration in Figure 16. This stage was highly simplified in the below illustration. During implementation it is important to implement the return to applicant functionality and any relevant Form Copies which are not illustrated here for simplification.




Figure 16 – The two paths possible at the committee stage




03.5 Emails and Messages

03.5.1 Branded emails to users and work queue using the email task

Throughout the whole process timeline emails are used continuously. Timeline emails are emails sent to the applicant by the eForms process to update him/her with a change in the status of the process. An email is the textual representation of the status. In the section 05.1.2.2.1 named Process Textual Process for the processes level corresponding numbers are determined The first email sent is when the payment had been successfully completed at as shown in the procedure below. The email can be sent either to the applicant or to the work queue. To determine whether the email is to be sent either to just the applicant or to the work queue, two (2) mail tasks have been implemented. The mail tasks in the process studio are as seen below.

Figure 17 - Mail Task in Process Studio Figure 18 - Mail for work queues When an email is sent to the work queue it is sent to the work queue mailbox as accessed by the people responsible to take care of whether the application is to proceed to the next stage or not.

Figure 19 – Using the Mail task For each email sent whether it is sent to the applicant or to the work queue the subject and the email content must be determined. These are determined by right clicking any of the Mail type icons in the process illustration and access the Mail Properties in the Task Properties. The window will be like the one below.




Using the mail task to send an email to the applicant the window on the left would appear. As noticed, to obtain the language by which the email is to be sent, the value of the hdnLanguage hidden field is used. Besides that, to identify the applicant email, the value in the txtAppEmail is to be identified. For implementations of the mnemonic used please refer to the document named Forms-REP-CustomExtensionDocumentation_MailTask-v1.0 in section 01.1named How to use the custom Mail Task. The message text is a parameter determined according to the message type such as being an acknowledgement email or a rejection email. Using the mail for work queue task to send an email to the work queue the window below would appear. As noticed to obtain the language by which the email is to be sent the value of the hdnLanguage hidden field is used. For implementations and further details about the mnemonics used please refer to the document named Forms-REP-CustomExtensionDocumentation_MailForWorkQueueTask-v1.0 in section 01.1 named How to use the custom Mail for work Queues Task.

Figure 20 – Using the Mail for Work Queues task




04. Further Assistance

If you have a question about this eForms Component guide, or you encounter an issue, please

contact us on [email protected].

e-Forms Process Documentation - MITA Home€¦ · · 2012-03-28Public eForms Main Process...

Documents

Transcript of e-Forms Process Documentation - MITA Home€¦ · · 2012-03-28Public eForms Main Process...