Request Fields

The ID field contains the request identifier. This unique identifier is automatically generated by the application when the request is saved for the first time.

The Workflow Progress Tracker presents the names of the phases of the workflow that is linked to the request. It offers a graphical representation of the progress this workflow has made to date.

The Subject field is used to enter a short description of the request.

Examples:
For requests for incident resolution:

• Slow response time on [Service]
• Error message using [Service]
• Cannot log onto (or access) [Server or Service]
• Job [Job Name] failed with [Abend Code]
• [Customer] router in [City] down

For requests for change:

• Install [Software & Version] on [Workstation or Server Label]
• Apply upgrade from [Current Software & Version] to [Requested Software & Version]

For requests for information:

• How to [Requested Information] in [Service or Application]

For requests for support improvement:

• Request [Request ID] not resolved in time
• Workflow [Workflow ID] was implemented without approval

For requests for bestowal of praise:

• Thanks for…

The Knowledge article field is automatically set to the latest knowledge article that was applied to the request.

The Grouped into field displays the request group that is used to group the requests that have been submitted for the resolution of exactly the same incident, for the implementation of exactly the same change, for the provision of exactly the same information, etc.

Grouping two or more requests together causes a request group to be generated. The grouped requests are automatically linked to this request group. Updates made to a request group are automatically applied to the grouped requests.

A grouped request can be ungrouped after it has been opened in View mode by pressing the Actions toolbar button and selecting the “Ungroup” option.

The Requested by field is used to select the person who submitted the request.

Note that the selection made in this field does not influence which service level agreement gets applied to the request. The selection in the Requested for field dictates that.

The Requested on field shows the data and time at which the request was created.

The Requested for field is used to select the person for whom the request was submitted. The person selected in the Requested by field is automatically selected in this field, but another person can be selected if the request is submitted for another person.

Note that the appropriate service level agreement that covers the person selected in this field will be applied to the request. The selection in the Requested by field does not influence this.

The Task field is visible only when the request was automatically generated by a task. When visible, this field contains the task that caused the request to be generated.

The Category field is used to select the category of the request.

The Impact field is used to select the extent to which the service instance is impacted.

This field is available only when the request category is “Incident”. For all other categories, the impact is automatically set to “None” as those categories do not apply to requests for the resolution of service degradations or outages.

Note that a service instance is degraded when some of its non-core functionality is not working, or when the response time of the service instance is slow. A service instance is also degraded when some or all of its redundancy is no longer available (e.g. when a server of a server cluster is down) even though the use of the service instance is not affected. A service instance is down, or unavailable, when any part of its core functionality is not working.

The Service instance field is used to select the service instance in which the cause of the incident resides, for which the workflow is requested, or about which information is needed.

This field is available only when the request category is “Incident”, “RFC”, or “RFI”.

The Service provider field is automatically set to the organisation that is selected in the Service provider field of the service that is related to the selected service instance.

The Configuration items table field is used to select the CI (or CIs) that caused the incident, for which the change request has been submitted, or about which information is needed.

At least one CI needs to be selected for incidents when they are set to the status “Completed” and the selected service instance is related to one or more CIs.

As long as no CIs have been registered, this field remains hidden.

The Related to field (by default set to Workflow) is used to link the request to a problem, workflow or project. These links are mutually exclusive, meaning that when the request is linked to, for example a problem and needs to be linked to a workflow, it will first need to be unlinked from the problem.

To select a solved problem or a completed workflow or project, enter the number (i.e. the ID) of this problem, workflow or project.

The Workflow template field shows the workflow template that is related to the request template that has been applied to the request.

This field is only visible after a request template has been applied that is related to a workflow template.

The Team field is used to select the team to which the request is to be assigned.

When a service instance is manually selected in the Service instance field of the request, or when a service instance is applied from the Service Hierarchy Browser, then the support team of this service instance is automatically selected in this field.

The Member field is used to select the person to whom the request is to be assigned.

The Planned effort field is used to provide an estimate of the effort needed to resolve the request.

The Supplier field is used to select the supplier organisation that has been asked to assist with the request. The supplier organisation is automatically selected in this field after a service instance has been selected that is provided by an external service provider organisation.

The Supplier request ID field is used to enter the identifier under which the request has been registered at the supplier organisation.

If the supplier provided a link to the request, enter its URL in this field.

The Response target field automatically indicates when the current assignment team needs to have responded to the request. The target displayed in this field is the most stringent response target of the affected SLAs that are related to the request and for which the current assignment team is responsible.

The Resolution target field automatically indicates when the current assignment team needs to have completed the request. The target displayed in this field is the most stringent resolution target of the affected SLAs that are related to the request and for which the current assignment team is responsible.

The Desired completion field can be set manually when a date and time has been agreed on for the completion of the request. The desired completion overwrites the automatically calculated resolution target of any affected SLA that is related to the request when the desired completion is later than the affected SLA’s resolution target.

By default, the person selected in the Requested by field receives a notification based on the ‘Desired Completion Set for Request’ email template whenever the value in the Desired completion field is set, updated or removed.

The Status field is used to select the current status of the request.

The available options are:

• Declined – It has been determined that the request had better be assigned to a different team or team member as indicated in the Notes field.
• Assigned – The request has been assigned to a team or team member for completion.
• Accepted – Responsibility for the completion of the request has been accepted by a specific team member. This person will start to work on the request as soon as possible.
• In Progress – The request is currently being worked on. Once the request has reached this status, it is considered to have been responded to.
• Waiting for… – The work on the request has been halted. The reason for this is specified in the Notes field.
• Waiting for Customer – The work on the request has been halted because the support organisation is waiting for the customer. The reason for this has been specified in the Notes field. The request will not get closer to the current assignment team’s response and resolution targets as long as the request is in this status.
• Reservation Pending – The reservation of a configuration item has been requested. The request will be completed automatically once the reservation has ended, or after it has been canceled.
• Workflow Pending – The completion of the request is dependent on the implementation of a workflow. The responsibility for the workflow implementation has been accepted by Change or Release Management.
• Project Pending – The completion of the request is dependent on the implementation of a project. The responsibility for the project implementation has been accepted by Project Management.
• Completed – The work on the request has finished for the reason selected in the Completion reason field. Details regarding the completion of the request have been specified in the Notes field.
• On Backlog – The request is placed on a backlog. This option is only available when the request is actually on a backlog.

The Waiting until field is used to specify the date and time at which the status of the request is to be updated from “Waiting for…” to “Assigned”.

This field is available only when the Status field is set to “Waiting for…”.

The Product backlog field is used to specify the product backlog this request is related to.

This field is available only when the Status field is set to “On Backlog”.

The Estimate field is used to estimate the complexity of resolving this request, based on a scale defined by the development or Scrum team.

This field is available only when the Status field is set to “On Backlog”.

The Completion reason field is used to select the appropriate completion reason for the request when it has been completed.

The Completed at field is automatically set to the date and time at which the request is saved with the status “Completed”.

The Downtime start field is used to specify the actual date and time at which the service outage started.

This field is available only when the Impact field has been set to “Top”.

The Downtime end field is used to specify the actual date and time at which the service became available again.

This field is available only when the Impact field has been set to “Top”.

The Major incident status field is used to select the current status of the request in the major incident management process. This field becomes available after a top-impact request has been proposed or accepted as a major incident using the Actions menu options ‘Propose as Major Incident’ or ‘Accept as Major Incident’. The option ‘Propose as Major Incident’ is available for all specialists. The option ‘Accept as Major Incident’ is available only for specialists who are selected as a major incident manager in the first line support agreement that covers one of the Xurrent accounts that has access to the request.

The available options are:

• Proposed – A specialist has indicated that the request should probably be treated as a major incident.
• Rejected – The proposal to treat the request as a major incident has been rejected by a major incident manager.
• Accepted – A major incident manager has accepted the proposal to treat the request as a major incident.
• Resolved – A major incident manager has marked the major incident as resolved.
• Canceled – A major incident manager has indicated that the major incident management process does not need to be completed for this request.

The Agile board field is used to move the request to another agile board.

This field is hidden when empty. Requests can be placed on an agile board using the ‘Add to Agile Board’ option of the Actions menu.

The Column field can be used to move the request to another column of the agile board that is selected in the Agile board field.

This field is hidden when the Agile board field is empty.

The Time spent field is used to enter the time that you have spent working on the request since you started to work on it or, if you already entered some time for this request, since you last added your time spent in it.

The Effort class field is used to select the effort class that best reflects the type of effort for which time spent is being registered. This field becomes available only after a value has been entered in the Time spent field and the person who entered the time spent belongs to an organisation that makes use of a timesheet settings in which assignment time tracking is activated and to which two or more effort classes have been linked.

The Grouped requests table field lists the requests that have been grouped together by the request group. The grouped requests are automatically updated when the request group is modified.

The Instructions field displays the information from the Instructions field of the request template that was last applied to the request. Visibility to the instructions is limited to people with the Auditor, Specialist or Account Administrator role of the template’s account.

The Notes field lists all notes that have been added to the request. Internal notes are also displayed, provided that the user has the Auditor, Specialist or Account Administrator role of the account for which the internal notes were added. For each note, this field shows the name of the person who submitted it and when this was done.

The Note field is used to provide any additional information that could prove useful for resolving the request and/or to provide a summary of the actions that have been taken since the last entry.

In case of incidents, specify for instance if the requester has used the service before. If the requester used the service before, specify when the requester first encountered the incident.

If there is an error message, enter the complete error message in this field, even when a screen shot of the message is attached to the request. This allows future searches for the error message to find this request.

If an email template exists for sending email from requests, it is possible to change the Note field into an Email field. After sending it, the email is added as a note to the request. Replies to the email also become notes.

This field allows basic text formatting.

The Attach file... link is used to attach a file to a note. Multiple attachments can be added to a note. The maximum file size of each attachment is 2 GB.

The Internal note field is used to provide information that is to be visible only to people who have the Auditor, Specialist or Account Administrator role of the account in which the person adding the internal note is working.

If an internal note belongs to a support domain account, then this internal note is visible also to people who have the Specialist role of another support domain account, provided that its directory account is the same as that of the support domain account to which the internal note belongs.

However, if the internal note belongs to an account that has the ‘Strong privacy’ option switched on in its Account Settings, then the visibility of the internal note is limited to specialists of this account, provided that they are a member of the team to which the request is currently assigned, plus the auditors and account administrators of the strong-privacy account.

If an email template exists for sending email from requests, it is possible to change the Internal note field into an Internal email field. After sending it, the email is added as an internal note to the request. Replies to the email also become internal notes.

This field allows basic text formatting.

The Attach file... link is used to attach a file to an internal note. Multiple attachments can be added to an internal note. The maximum file size of each attachment is 2 GB.

The Affected SLAs table field lists the affected SLA records that have automatically been generated for the request to track the SLAs that are affected by the request.

Typically, only the SLA by which the requester is covered for the selected service instance is listed in this table field. However, depending on the impact relations specified in the service hierarchy, all SLAs for the parent service instances of the selected service instance could be affected if the Impact field is set to “High” or “Top”.

The Time entries table field lists all time entries of your organisation’s account that have been generated for the request after it was saved with a value in its Time spent field. The time entries are grouped by Person.

The Columns panel presents the columns of the agile board on which the request has been placed.