This page is in the process of being edited, it may be incomplete or contain errors.
EditRelated articles
Types of service request
EditIntroduction
The concept of "task" is applied in Octopus for service requests, changes and problems
(in "Problems" starting from Summer 2011 version).Tasks are created to reflect the implementation process ("workflow") of a service request, the steps for preparing and implementing a change and the tasks involved in analyzing a problem; in all cases, they can be assigned to a group / assignee and can provide some order in their execution.
EditTask creation
The following steps explain how to create a task directly in an service request, problem or change, it is called a manual task. It is a task that is created when it is needed in the request.
1. From the tab "Tasks", select
Editing mode and click on the buton
"Add". The image below shows three (3) tasks, so we can describe how they can intervene between them.
2. Assign a name to the task and include instructions for the assignee in charge of executing to the location designated in the illustration.
3. The link
Due date : sets the time allowed for a player to complete a task (execution deadline); it may be a fixed date, or a period in hours/ days / week / month. The system will calculate the due to the activation of the task is activated, considering the stated period.
4. If you want this task to be activated automatically after its creation, click
"Activate".
5. Enter the group (and the assignee) to which the task will be assigned to.
In our example, the task is assigned to a service center, task 2 to the Panel, and Task 3 in Technical Support. No player has been appointed, which means that all group members will see the task until one of them supports it.
In our example, the task 1 is assigned to the service center, task 2 to the Specialists group and the task 3 to the Technical Support. No assignees have been designated, which means that all group members will see the task until one of them takes control of it
6. Enter the estimated effort, if desired. This is different from the due date, for example, create a network access can be estimated at 15 minutes, but is given a term of one (1) the intervening days to complete the task.
7. The total effort shows the cumulative efforts of the activities of a task and is for information purposes only.
8. The "Prerequisites" to specify the (s) task (s) to be performed
before enabling this task.
For example, a task "Installation" could be activated automatically lorsque'une task "Receive Goods" is completed. Be careful Don't pas activate a task that contains one or prerequisites, and it will activate itself when the task will be completed prior ..
9. The box "Monitoring" is used to denote a task that does not affect the aim of executing the query, but we want to follow and execute even if the request is completed. They are often administrative tasks (invoicing, journals, checks, etc.).
10. If you have several tasks, use the arrows to move the tasks to the top

, or to the bottom

.
11. To delete a job created in error or no longer useful, click the

.
12. The icon

opens the edit task module.
EditCreating a process execution ("workflow") of a type of service request(SR)
Using a type of SR, a set of tasks can be pre set to build the implementation process ("workflow") of the service request and make regular and consistent, in fact, whenever such SR is selected, the same tasks are generated, assigned to groups and / or designated participants, with the same instructions work the same schedule, etc..
1. Go to
Tools> Reference Data Management ... > Service Request> Typeand choose the type of service request for which you want to build a "workflow".
2. Go to tab "Tasks", enter "Edit mode" and follow the instructions in
"Creating a task - General concepts ".
3. An additional option is offered, to make this work visible on the web portal self-service
(you must first enable the "Suivi of task progress via the Web application service free" from the menu Tools> Options).
See "Viewing the tasks on the self-service Web portal" for more details.
These couples of hints could be useful to you:♦ The first task of a set must be activated;
♦ Never activate a task containing one or more dependencies; it will activate by itself once the dependency has been reached;
♦ If a couple of consecutive tasks concern the same group or assignee, make only one task and write the realization steps in the task instructions to reduce the quantity of assignee tasks;
♦ Il est superflu de créer une seule tâche pour un type de demande de service; la SR peut être directement assignée au groupe / intervenant apte à l'exécuter (allège la gestion de la SR);
♦ Il n'est pas nécessaire de rendre visibles à l'utilisateur TOUTES les tâches qui font partie d'un type de SR; n'affichez que ce qui est pertinent pour le suivi de la requête par l'utilisateur;
♦ Ne configurez que les tâches qui reviennent régulièrement dans un type de SR; les tâches occasionnelles pourront être ajoutées manuellement;
♦ L'ajout d'une tâche manuelle, la modification ou la suppression d'une tâche existante dans une requête ne modifiera pas les tâches pré définies d'un type de SR;
♦ L'annulation d'une demande de service annule systématiquement toutes ses tâches.
4. Pour en apprendre plus sur cette fonctionnalité, nous vous invitons à visionner cette vidéo:
EditTasks in "Problems" and "Changes"
The Summer 2011 version now incorporates tasks into "Problems" and "Changes" requests, but they can only be added manually. In the current Octopus version, we cannot pre configure a problem or a change (template) like a type of SR; the change templates from
Reference Data Management are only used for the creation of scheduled jobs (see article
What are the Change Templates for?).
However, for those who want to create and use the change templates with predefined tasks, we have developed a plug-in (or extension module) that can be applied to your database. Because of its popularity, we will eventually add it permanently at the next "Changes" module revision. Until then, you can request it through our support (
Octopus technical support).
EditTasks displaying on the self-service Web portal
When we identifies tasks as visible on the self-service Web portal, the user can see the evolution of his requests.
- the green check means that the task is completed

- the blue arrow means that the task is in process

- the gray arrow means that the task has not started yet

For example, we have illustrated bellow the tasks list of a service request in Octopus. We can see five (5) tasks, the last one being a billing task, designated as a follow up task that does not need to be visible on the We portal.
Displaying this service request on the Web will be as this; you will notice that the billing task is not shown.