Request task form details

The following table identifies and describes some of the features on the request task form.

Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Request task field descriptions
Label	Description
Request Task ID	The system-generated unique ID for this request task.
Title	A short description that summarizes the request task. It is a mandatory field.
Description	A detailed description of the request task. This field is prepopulated with data from parent request/order. It is a mandatory field.
Parent Request	Displays the unique ID of parent request/order.
Category	This field describes the type of request task. In out-of-box, the following categories are available: Automation Installation Labor Purchase Reservation Uninstallation
Phase	This is a system-generated field that specifies the name of the current phase of the request task. These phases are available in out-of-box workflows: Waiting Active Review Closure Cancelled CMDB Update (only available in “Purchase”/“Reservation”/”Installation”/”Uninstallation” task workflow) Execution (only available in “Automation” task workflow) Completion (only available in “Automation” task workflow)
Status	Displays the status of the request task. These statuses are available in out-of-box workflows: Planned – Request task is opened but not activated. Ready – Request task is activated. In Progress – Request task is being handled by Request Analyst. Pending Customer – Additional information is required from user/requester. Pending Vendor/Supplier – Vendor/Supplier will handle this request task. CMDB Update (Only available in “Purchase”/“Reservation”/”Installation”/”Uninstallation” task workflow) – CMDB is being updated. Pending Review – High priority request task will be reviewed. Cancelled – Request task is cancelled. Closed – Request task is closed.
Impact	A measure of the effect of the request task on business processes. Impact and urgency are used to assign priority. These impacts are available out-of-box: Enterprise Site/Dept Multiple Users User This field is prepopulated with data from parent request/order. It is a mandatory field.
Urgency	A measure of how long it will be until a request task has a significant impact on the business. Impact and urgency are used to assign priority. These urgencies are available out-of-box: Critical High Average Low This field is prepopulated with data from parent request/order. It is a mandatory field.
Priority	The order in which to address the request task in comparison to others. The priority value is calculated using impact and urgency.
Assignment Group	The support group assigned to work on this request task. This field can be prepopulated by the data defined in assignment rule or manually set by Request Coordinator. It is a mandatory field.
Assignee	The person assigned to work on this request task. This person is a member of the assignment group. This field can be prepopulated by the data defined in assignment rule or manually set by Request Coordinator.
Request Coordinator	The name of the person responsible for coordinating the implementation of the parent request/order. Each Coordinator may belong to several assignment groups. Each group can have just one Request Coordinator.
Planned Start	If “Global Lead Time” is not zero in request or order, this field will be calculated starting from request “Delivery Date” and upstream from the last task to the first one in task planner, task dependency and planned lead time will be considered. In case “Global Lead Time” is zero in request or order, this field will be calculated from the “Expected Finish Date” instead of “Delivery Date”. This field is read-only in the request task form.
Planned End	If “Global Lead Time” is not zero in request or order, this field will be calculated starting from request “Delivery Date” and upstream from the last task to the first one in task planner, task dependency and planned lead time will be considered. In case “Global Lead Time” is zero in request or order, this field will be calculated from the “Expected Finish Date” instead of “Delivery Date”. This field is read-only in the request task form.
Planned Lead Time	Defines the duration time that the request task will spend. Data is prepopulated by the value defined in task planner of Request Model. This field is read-only.
Actual Start	It will be auto-populated when task is activated.
Actual End	It will be manually filled by Request Analyst when request task is done.
Contractual Lead Time	By default it equals to “Planned Lead Time”. However it is allowed to be adjusted by authorized operator according to real situation. Once it is changed, the “Planned Start” and “Planned End” will be re-calculated accordingly. The out-of-box request task SLT is still measured based on “Planned Lead Time”.
Cost > Total Cost	Total cost incurred by fulfillment activities. This field in “Purchase” task indicates the cost of received part items. This field in other tasks indicates the labor cost.
Cost > Currency	Specifies the currency of the total cost.
Cost > Date/Technician/Hours Worked	The table specifies when and who will work on the request task for how many hours. The labor cost is calculated based on the hourly rate of the technician and the hours spent by the technician.
Purchase > Part No.	The part no. of the purchased item listed in product catalog. This is a required field.
Purchase > Vendor	The vendor of the specified part item which is defined in the modelvendor table. This is a required field.
Purchase > Ship To Location	The destination location the purchased items should be shipped to. This is a required field.
Purchase > Ordered Quantity	The number of part items requested or ordered. This is a required field.
Purchase > Received Quantity	The number of received part items.
Purchase > Balance	Equals “Ordered Quantity” minus “Received Quantity”.
CI Update History > button Submit to CMDB/Update CMDB	The Request Analyst clicks this button to execute actual CI creation or CI status update. A confirmation message box will be displayed once this button is clicked. If “Yes” is selected in the message box, CI will be created or CI status will be updated. Otherwise, CMDB update action is abandoned.
CI Update History > CI Name/Old Status/New Status/Operation Time/Whether Updated?/Receipts Number	Shows the CMDB update result. New created CIs will be shown in “Purchase” task. Status updated CIs will be shown in “Reservation”/“Installation”/”Uninstallation” task.
Request Information > CartItem Id/Cart Item/Requested For/Quantity/Status/User Selection	Displays the request information provided by user/requester. The request information includes the items ordered from Service Catalog, the user selection details of the ordered items. The information in this table will be referenced by the operator who performs CMDB update.
Summary > Closure Code	Specifies a predefined closure code to describe how the request task has been fulfilled. These closure codes are available out-of-box: Successful Successful (with problems) Failed Rejected (financial) Rejected (technical) Rejected (security) Withdrawn Withdrawal requested by customer Cancelled Denied request fulfillment
Summary > Closure Comments	This field is to document additional comments to close the request task.
Workflow section	Displays a figure of request task workflow. It indicates the current phase which the request task is in, and traces the phase transition history.
Activities section	Records information that the operator enters during the lifecycle of the request task. Every time you update a request task, you can fill in an update on the Activities section (New Update) with or without “Visible to Customer” flagged. A log of all the updates is stored on the Journal Updates and activities list.
Attachments section	You can use the Attachments section to attach documents to request task.
Related Records section	Contains a list of all related records for the request task. The related records in request task form only include changes.
SLT section	The SLT (Service Level Target) section displays SLAs related to the request task. The Service Level Targets subsection defines the Process Target details, such as beginning and ending state, and time allowed between these states. The Upcoming Alerts subsection displays the alerts to generate when processing the Process Target.
Task Context section	Displays the input and output parameters of the request task.
History section	Displays the timestamps and operators that the request task is opened or updated by.

Request task field descriptions

Label

Description

Request Task ID

The system-generated unique ID for this request task.

Title

A short description that summarizes the request task. It is a mandatory field.

Description

A detailed description of the request task. This field is prepopulated with data from parent request/order. It is a mandatory field.

Parent Request

Displays the unique ID of parent request/order.

Category

This field describes the type of request task. In out-of-box, the following categories are available:

Automation
Installation
Labor
Purchase
Reservation
Uninstallation

Phase

This is a system-generated field that specifies the name of the current phase of the request task. These phases are available in out-of-box workflows:

Waiting
Active
Review
Closure
Cancelled
CMDB Update (only available in “Purchase”/“Reservation”/”Installation”/”Uninstallation” task workflow)
Execution (only available in “Automation” task workflow)
Completion (only available in “Automation” task workflow)

Status

Displays the status of the request task. These statuses are available in out-of-box workflows:

Planned – Request task is opened but not activated.
Ready – Request task is activated.
In Progress – Request task is being handled by Request Analyst.
Pending Customer – Additional information is required from user/requester.
Pending Vendor/Supplier – Vendor/Supplier will handle this request task.
CMDB Update (Only available in “Purchase”/“Reservation”/”Installation”/”Uninstallation” task workflow) – CMDB is being updated.
Pending Review – High priority request task will be reviewed.
Cancelled – Request task is cancelled.
Closed – Request task is closed.

Impact

A measure of the effect of the request task on business processes. Impact and urgency are used to assign priority.

These impacts are available out-of-box:

Enterprise
Site/Dept
Multiple Users
User

This field is prepopulated with data from parent request/order. It is a mandatory field.

Urgency

A measure of how long it will be until a request task has a significant impact on the business. Impact and urgency are used to assign priority.

These urgencies are available out-of-box:

Critical
High
Average
Low

This field is prepopulated with data from parent request/order. It is a mandatory field.

Priority

The order in which to address the request task in comparison to others. The priority value is calculated using impact and urgency.

Assignment Group

The support group assigned to work on this request task. This field can be prepopulated by the data defined in assignment rule or manually set by Request Coordinator. It is a mandatory field.

Assignee

The person assigned to work on this request task. This person is a member of the assignment group. This field can be prepopulated by the data defined in assignment rule or manually set by Request Coordinator.

Request Coordinator

The name of the person responsible for coordinating the implementation of the parent request/order. Each Coordinator may belong to several assignment groups. Each group can have just one Request Coordinator.

Planned Start

If “Global Lead Time” is not zero in request or order, this field will be calculated starting from request “Delivery Date” and upstream from the last task to the first one in task planner, task dependency and planned lead time will be considered. In case “Global Lead Time” is zero in request or order, this field will be calculated from the “Expected Finish Date” instead of “Delivery Date”. This field is read-only in the request task form.

Planned End

Planned Lead Time

Defines the duration time that the request task will spend. Data is prepopulated by the value defined in task planner of Request Model. This field is read-only.

Actual Start

It will be auto-populated when task is activated.

Actual End

It will be manually filled by Request Analyst when request task is done.

Contractual Lead Time

By default it equals to “Planned Lead Time”. However it is allowed to be adjusted by authorized operator according to real situation. Once it is changed, the “Planned Start” and “Planned End” will be re-calculated accordingly. The out-of-box request task SLT is still measured based on “Planned Lead Time”.

Cost > Total Cost

Total cost incurred by fulfillment activities. This field in “Purchase” task indicates the cost of received part items. This field in other tasks indicates the labor cost.

Cost > Currency

Specifies the currency of the total cost.

Cost > Date/Technician/Hours Worked

The table specifies when and who will work on the request task for how many hours. The labor cost is calculated based on the hourly rate of the technician and the hours spent by the technician.

Purchase > Part No.

The part no. of the purchased item listed in product catalog. This is a required field.

Purchase > Vendor

The vendor of the specified part item which is defined in the modelvendor table. This is a required field.

Purchase > Ship To Location

The destination location the purchased items should be shipped to. This is a required field.

Purchase > Ordered Quantity

The number of part items requested or ordered. This is a required field.

Purchase > Received Quantity

The number of received part items.

Purchase > Balance

Equals “Ordered Quantity” minus “Received Quantity”.

CI Update History > button Submit to CMDB/Update CMDB

The Request Analyst clicks this button to execute actual CI creation or CI status update. A confirmation message box will be displayed once this button is clicked. If “Yes” is selected in the message box, CI will be created or CI status will be updated. Otherwise, CMDB update action is abandoned.

CI Update History > CI Name/Old Status/New Status/Operation Time/Whether Updated?/Receipts Number

Shows the CMDB update result. New created CIs will be shown in “Purchase” task. Status updated CIs will be shown in “Reservation”/“Installation”/”Uninstallation” task.

Request Information > CartItem Id/Cart Item/Requested For/Quantity/Status/User Selection

Displays the request information provided by user/requester. The request information includes the items ordered from Service Catalog, the user selection details of the ordered items. The information in this table will be referenced by the operator who performs CMDB update.

Summary > Closure Code

Specifies a predefined closure code to describe how the request task has been fulfilled.

These closure codes are available out-of-box:

Successful
Successful (with problems)
Failed
Rejected (financial)
Rejected (technical)
Rejected (security)
Withdrawn
Withdrawal requested by customer
Cancelled
Denied request fulfillment

Summary > Closure Comments

This field is to document additional comments to close the request task.

Workflow section

Displays a figure of request task workflow. It indicates the current phase which the request task is in, and traces the phase transition history.

Activities section

Records information that the operator enters during the lifecycle of the request task. Every time you update a request task, you can fill in an update on the Activities section (New Update) with or without “Visible to Customer” flagged. A log of all the updates is stored on the Journal Updates and activities list.

Attachments section

You can use the Attachments section to attach documents to request task.

Related Records section

Contains a list of all related records for the request task. The related records in request task form only include changes.

SLT section

The SLT (Service Level Target) section displays SLAs related to the request task. The Service Level Targets subsection defines the Process Target details, such as beginning and ending state, and time allowed between these states. The Upcoming Alerts subsection displays the alerts to generate when processing the Process Target.

Task Context section

Displays the input and output parameters of the request task.

History section

Displays the timestamps and operators that the request task is opened or updated by.