Overview of service requests
A service request is an offering that is generated from the service request definition (SRD). Users, support staff, and automated tools can create service requests.
Although service requests inherit characteristics from the selected SRD on which they are based, they have a life cycle of their own. A service request has various states to indicate its position in the life cycle. Approvals can be required for certain state transitions. You can also configure to send notifications at certain points in the service request life cycle to alert users that a certain event has occurred.
An important part of the role of the Service Request Coordinator is monitoring service requests that have errors in them. If a service request contains an instance error in one of its fulfillment applications, the request cannot move forward until the problem is resolved.
- The status and status reasons of a service request reflect a snapshot in its fulfillment life cycle and do not necessarily map 1:1 with the status and status reasons of an application request. The status and status reasons of the underlying application requests do not roll up to the service request.
- When a user submits, modifies, or cancels a request in the Request Entry console, back-end fulfillment application entries might take up to 10 minutes to be created or updated.
Service request life cycle
Service requests go through many state transitions as they progress:
A service request can transit through the following status values:
The request has been created but has not been submitted yet.
The request has been submitted and is being reviewed.
Work on the request has been temporarily suspended and the request is awaiting either approval or more information.
The request has been submitted and is pending approval. After the request is approved, its status changes to In Progress.
A request goes into Initiated/Planning status when all of the approvers have approved it. The status includes planning the work approved for implementation, targeting dates, and estimating costs. If the request is divided into several tasks, the work order manager can create and schedule these tasks.
Fulfillment providers work on the requests. They log their progress as they implement the request and perform any tasks included in it. When a task is completed, the next task implementer in the sequence is notified of the task assignment.
The request is updated to Completed when it is closed in the fulfillment application. Users can update a completed request, which creates a work order.
The approver rejects the request (for example, a manager decides that it is more cost-effective to buy a new computer than to replace the hard drive).
The request is cancelled (for example, because the user remembers the password).
The request is closed when a requester completes the survey (if surveys are enabled), or automatically closes after 15 days.
- The In Review state is an internal, temporary status.
- In BMC Helix ITSM: Smart IT, the Initiated status is called Planning. For more information, see .
- There is no mapping between the status of a request generated on the Request Entry console and the statuses of fulfillment application requests that the request generates.
Service request status reasons
When a service request enters a status, status reasons can be included. Not all statuses include status reasons. The following table shows the available status reasons.
Service request status
Possible status reasons
BMC Service Request Management does not relate the status reason for a fulfillment request to its service request status reason. For example, if the work order related to a service request is completed with status reason as Successful With Issues, the system sets the status of the related service request to Completed with status reason as Successful instead of Successful with Issues.