Develop > Process Designer Tailoring Best Practices > Best practices for configuring task planner

Best practices for configuring task planner

Task Planner enables you to schedule tasks in Service Manager modules such as Change Management or Request Management. This section provides information about the best practices for using the Task Planner. For example, you can configure shared information across multiple tasks, or you can use record context to drive workflows.

Configure shared information across tasks

You can use Task Planner to configure information shared by multiple tasks.

The following three types of information from a record can be shared by the tasks of a record:

  • Record fields, for example, the request fields or the change fields
  • User selections, which are input by the end user when they use Service Manager
  • Record context, which are fields defined in Task Planner. The values of these fields are populated during task implementation and then shared across the tasks of a record.

The following diagram demonstrates how these three types of information of a Request is shared among its tasks.

 

Each task can have its own input and output data. The input fields are used to receive data from other tasks, and can trigger the execution of the current task. The output fields are used to populate shared data to the record during task execution, and the data can then be shared by other tasks.

You can launch the Record Context (Ticket Context) definition page from the Task Planner. The page is shown as follows:

On the definition page of the Task Planner, you can configure the input and output fields. The Record Context fields of a record can be used as the input or output fields of a task, and the output fields can be used in subsequent tasks as the input fields.

The following Task Context page shows the run-time result of a task, which contains the input and output fields/values. The input fields are read-only, while the output fields can be edited with appropriate values that can be populated to the next task later.

Use record context fields in Condition Editor

The Condition Editor does not support using the value of a record context field directly as part of the condition, so you have to manually retrieve the value and put it into a Service Manager variable, and then you can use this variable in Condition Editor.

For example, if you want to use the record context field “employeeType” as part of the condition in the Request workflow, you need to execute the following JavaScript code before your condition is evaluated:

vars[“$L.ticketcontext.license”] = lib.c.$("#taskPlannerService").getTicketContextFieldValue("request", record.number, "employeeType");

Or you can use the JavaScript below in the Request Task workflow:

vars[“$L.ticketcontext.license”] = lib.c.$("#taskPlannerService").getTicketContextFieldValue("request", record.parent_request, "employeeType");

Finally, you can configure the condition to something in the Condition Editor as shown below:

Use predefined additional task fields

When you plan a task in Task Planner, you might want to use fields that are not available in the out-of-box configuration. In this case, you can define new fields for Task Planner at the object level or category level.

For example, in the following screenshot you can see that a field is defined at the object level – if you do not specify any value for the Task Category Name field, the field is defined at the object level, which applies to all category tasks.

And as shown in the following screen shot, if you specify a value for the Task Category Name field, the field is defined at the category level, which applies only to this task category.

At run time, the predefined fields at both the object level and the category level are merged together and displayed in Task Planner. If a field is defined at both levels, the definition at the category level is used.

After being defined, the predefined additional task fields are displayed at the bottom of the Task-Properties tab. Your entered data is inserted into the task that is created in Task Planner.

 

Plan appropriate number of tasks in a same open phase

When you define a task plan, you can specify the “Open in Phase” field of a task, which means this task is created at run time when the workflow of the record moves to the phase. Currently all the tasks you plan with the same “Open in Phase” value are created immediately when the record moves to the corresponding phase.

Too many tasks for a phase may result in decreased performance. For example, if you plan more than 10 tasks, the operator might feel obvious performance downgrade when he moves the record to that phase. To ensure the best performance, it is recommended that no more than 10 tasks are automatically started once a phase is entered.

Note: The performance of generating tasks in Task Planner is not only affected by the number of planned tasks, but also by the business logic you plan for task creation. The more complex and time-consuming the logic is, the more performance downgrade you might encounter.