Task

This tutorial describes the solution in todo4teams for the following scenario:

A customer request received as an e-mail creates a ticket for a particular group (e.g. customer requests). An agent accepts this ticket. In most cases the agents handle requests by themselves directly in a single workflow step.

If the customer now has a request that the agent can not decide independently (for example discounting above a certain limit), he must obtain the approval of a decision maker (Manager). The customer is then informed by the agent by e-mail whether his wish can be met or not.

Solution

To solve the scenario described above, the following workflow can be implemented in todo4teams:

In the first step  a new group has to be  created in todo4teams, which includes the users who can make further decisions and approvals. In the following example it is the group "Management" with the ID = 24. In addition  a form (in the example "Approval") will be created, which will control this workflow.

1. The agent processes the received e-mail, recognizes that he has to request a clearance for the customer's request and selects the "Approval" form in the finishing-dialog. In the "Request" field he specifies the type and extent of the approval. Subsequently, this ticket will be finished by clicking the "Finaliza" button. The agent also has the possibility to send the customer a first e-mail and inform the customer that an approval  was requested by editing the 'E-Mail' tabsheet.
2. The ticket is now automatically forwarded to the group "Manager". Strictly speaking the ticket was cloned - preserving the original ticket to document the agent's action.
3. A member of this group ('Management') will respond to the ticket by clicking "granted" or "declined" in the "Approval" form by selecting the corresponding radio button. The "manager" can also write a comment in the form's "Comment" field.

4. The ticket is now automatically redirected to the original group, which originally processed the customer's request. The owner of this ticket remains the original (first) agent.

5. Within this ticket the agent now sees the decision and the approval in the attached "Approval" form. Now he is able to process the ticket, respond to the customer via e-mail and complete the process.

Throughout these workflow steps two additional tickets are created in the system which are linked to the ticket of the original customer's request. These tickets document the single actions. See the ticket's "Workflow" tabsheet. It lists all workflow steps including the executing user, dates etc. The original customer's request and the ticket generated by it are best  suitable for this. However, you can also enter into this dialog via one of the two folllowing tickets, that is e.g.  the ticket with the request to the manager group.

Form

The layout of the form is pretty straightforward: Above is a text field in which the agent can make the request. When sending the request, an entry is required (field name: Request).

The manager has a radio button at disposal for his decision (field name Decision) and a text field for an optional comment. When the manager try to submit his decision, the choice of a Decision will be compulsory.

It will be shown later in the script how the fields are made into mandatory fields. See also  this tutorial.

Script programming

Send Action

In order to make the field Request into a mandatory field the value is determined when sending (in the send action) and, if no value has been entered, the helper.errorMessage () method is used to display a message and prevent the form from being sent by setting the result value result to "error":

Close Action

The close- action of the form is executed three times in this workflow: First, when the agent forwards the ticket in step (2) to the manager. A second time when the manager sends his answer to the request (3) and the third time the agent closes the ticket and sends the response to the customer (4) - the form will still be attached to the ticket.

Only when editing by the manager, however,a selection is to be enforced for the radio button "Decision".

For this purpose the system checks to which group the ticket is processed in the current step. If it is the group Manager (with ID 24), the following code is required for selection and otherwise the form is not sent:

End Action

Within the server-side end-action the actual forwarding of the ticket takes place. To do this, you first have to check which group is currently processing the ticket. We again distinguish between the cases "Manager" and "Non-Manager" (i.e.  agents). Because we do not specify a special agent group, we can make the Approval form available later to different agent groups!

However, the form must remember which agent group the ticket must be returned to. This is done by the line

task.addProperty("origGroupId", ""+task.addressee.getAddressedWorkgroup().getId());

in which the ID of the addressed group is stored in a Task-Property (look here)  called origGroupId.

The line

helper.propagateTaskToGroup("Manager");

ensures the forwarding of the ticket to the group Manager. Both rows are executed only if the currently addressed group is not a manager, see the condition if (gid == 24) {...

In the other case, that the group Manager is currently addressed, the ticket is forwarded back to the originally addressed group whose ID was stored in the task property origGroupId and is determined here using the method task.getProperty ().

In the first four lines a note will be inserted into the ticket description, which should inform the manager of the attached Approval form and mark the release workflow:

If you want to use the workflow in todo4teams, please  import the ready-made form attached here and change it according to your needs. To do this, change the ID 24 used in the scripts to the escalated group and the group name Manager and replace them with values matching your todo4teams installation.