Creating requests from fulfillment applications
You can configure fulfillment applications so that fulfillment requests generate service requests in BMC Service Request Management. Doing so enables end users to view information about fulfillment requests, such as activity log entries, within the context of service requests. For example, when a service agent creates an incident, change request, or work order on the backend, a service request is also created, and the end user can open the service request from the Request Entry console.
The application ships with three system Service Request Definitions (SRDs) to support the reverse creation of requests from fulfillment applications. Each SRD comes with its corresponding system Process Definition Template (PDT) and Application Object Template (AOT).
Important
- Entitlement rules are required for the system SRDs if the Apply Entitlement Rules to Global SRDs option is set to Yes. For more information, see Enabling entitlement.
- Since work orders do not include Impact and Urgency fields, the service request is created with a default value of Medium for Impact and Urgency. Service request notifications include the Medium value for Impact and Urgency, but not the Priority value from the work order.
- In BMC Helix ITSM: Smart IT, the Initiated status is called Planning. For more information, see
Submitting service requests
in the Smart IT online documentation.
Relationship of service request status to fulfillment request status
Service requests and the fulfilment requests (incidents, change requests, or work orders) have life cycles of their own. The following table shows the relationship between the service request status and the fulfillment request status:
Service request status | Incident status | Change request status | Work order status |
---|---|---|---|
Draft | Not applicable | Not applicable | Not applicable |
Waiting Approval | Not applicable | Not applicable | Not applicable |
Rejected | Not applicable | Not applicable | Not applicable |
Initiated/Planning | New Assigned | Request for Authorization | Assigned |
Pending | Pending | Pending | Pending |
In Progress | In Progress |
|
|
Cancelled | Cancelled | Cancelled |
|
Completed If multiple fulfillment requests are created from a service request, and one of the fulfillment requests is canceled, the status of the service request is set to Completed with a status reason of With Issues. |
|
|
|
Closed | Not applicable | Not applicable | Not applicable |
Service request status when there are multiple fulfillment steps
A service request can include multiple fulfillment steps, some or all of which might be activated or bypassed, depending upon processes and conditions configured in the service request definition (SRD). The following rules apply:
Service request status | Status reason | Service request status occurs if... |
---|---|---|
Initiated/Planning | Not applicable | At least one fulfillment step is activated. The other fulfillment steps can be activated, bypassed, cancelled, or rejected. |
Pending | Not applicable | At least one fulfillment step is pending. |
In Progress | Not applicable | At least one fulfillment step is in progress. |
Cancelled | Not applicable | All of the fulfillment steps are bypassed, cancelled, or rejected. |
Rejected | Not applicable | The service request has been rejected by the approvers. If a fulfillment step (for example, a change request) is rejected, the status of the service request is not set to Rejected. |
Completed | Successful | All of the fulfillment steps are bypassed or resolved. |
Completed | With Issues | At least one fulfillment step is resolved, and at least one fulfillment step is cancelled or rejected. The other fulfillment steps can be bypassed, resolved, cancelled, or rejected. |
Out of the box SRDs
Service Request Management contains the following SRDs out of the box. Each of these SRDs comes with its corresponding system PDT and AOT. These SRDs support automatic creation of service requests from fulfillment applications. Work assignments are been configured for these SRDs.
SRD title | SRD type | PDT name | AOT name |
---|---|---|---|
Work Order Request | Work Order — This SRD for work orders is automatically installed with the product. | Process Template Work Order | Work Order |
Change Request | Change Request — The SRD for change requests is included with BMC Helix ITSM: Change Management. The system SRD for change requests is installed only when BMC Helix ITSM: Change Management is present. | Process Template sample Change | Change Sample |
Service Desk Incident | Incident — The SRD for incidents is included with BMC Incident Management. The system SRD for incidents is installed only when BMC Incident Management is present. | Process Template sample Incident | Incident Sample |
Warning
The PDT and AOT names have the term Sample in their titles, but they are not sample data. Do not delete these SRDs, PDTs, and AOTs. If you try to delete them, you will receive a system warning.
The following fields in the system SRDs are locked and cannot be edited:
Field name on Service Request Definition form | Characteristics |
---|---|
Status | The system SRD status is always Draft, so that it never appears on the Request Entry console. |
Description | Includes the following special message: |
Instructions | Includes the following special message: |
Request Type (Definition tab) | Cannot change the process |
Process Template (Definition tab) | Cannot change the process |
Reopen Request | The default setting of Reopen Fulfillment Process cannot be changed. |
Business Service (Definition tab) | Cannot add a business service. The name of this field is Business Service in Work Order Management and Service in BMC Change Management and in BMC Incident Management. |
Approval Type (on the Service Request tab) | Specifies whether the request created from this SRD needs approval and who must approve the request |
Important
Summary records created for the BMC Helix ITSM Requester Console are automatically converted to SRDs when the product is installed.
How activity log information is passed
When end users and back-end application users update the activity log on a service request or a back-end request, the following scenarios can occur:
When an end user updates the activity log of a service request, the new work notes are passed to all the backend requests related to the service requests that are in progress. Work notes will not be passed to backend requests that have not yet been opened.
- If an end user adds work notes to a service request that is not currently in progress (no back-end requests exist), the work notes are set to the backend requests after the initial back-end requests are created.
- When all work notes are passed to backend request at the same time, the submit date on the backend request becomes the date when the work note was passed, not the date that the original work note was created.
- When an end user reopens a service request, the end user can add a work note (for example, to indicate the reason for reopening). That work note is passed to a back-end request that is reopened, but not to any backend request that was bypassed, cancelled, or rejected. If a new work order is created instead, all work notes from the service request are passed to the new work order (including the work note with the reason for reopening).
- When a backend application user updates the activity log on a backend request, the work notes are passed to the related service request. In the activity log in the Request Entry console, these updates appear as new entries.
- When an end user submits an issue from a Knowledge Base article in the Request Entry console, the URL to the article is not active in the work notes of the backend request. You can copy and paste the URL into the address bar of a browser to view the article.
To generate a request from a fulfillment application
The following example uses Work Order Management. The procedure is similar for BMC Incident Management and Change Management. For more information, see
Configuring change rules
and
Configuring incident rules
.
- In the Application Administration console, select Custom Configuration > Service Request Management > Work Order > Rules.
In the Create Service Request on Submit field, select Yes.
Important
This setting is not applicable if the work order is submitted by using BMC Helix Digital Workplace.
- Ensure that the rule is enabled, and save it.
- Create a new work order.
When you submit the new work order, a service request is created.
Comments
Log in or register to comment.