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).
- 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 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
Change request status
Work order status
Request for Authorization
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.
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.|
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.
Work Order Request
Work Order — This SRD for work orders is automatically installed with the product.
Process Template Work Order
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
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
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
The system SRD status is always Draft, so that it never appears on the Request Entry console.
Includes the following special message:
Includes the following special message:
Request Type (Definition tab)
Cannot change the process
Process Template (Definition tab)
Cannot change the process
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
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 and .
- In the Application Administration console, select Custom Configuration > Service Request Management > Work Order > Rules.
In the Create Service Request on Submit field, select Yes.
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.