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).

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	Planning in Progress Request for Change Scheduled For Review Scheduled For Approval Scheduled Implementation In Progress	Planning In Progress Waiting Approval
Cancelled	Cancelled	Cancelled	Cancelled Rejected
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.	Resolved Closed	Completed Closed	Completed Closed
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: This SRD is used internally by the system for the (optional) creation of a linked request when a work order is created directly in Work Order Management. Users are unable to create these requests directly, but will be able to track the related work order in the "Submitted Requests" section of the Request Entry console.
Instructions	Includes the following special message: oob configuration should be such that end users will not see this request or the internal system requests category when they browse or search the catalog.
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, seeConfiguring change rules andConfiguring incident rules.

In the Application Administration console, select Custom Configuration > Service Request Management > Work Order > Rules.

To specify whether to create a request on submission of a work order, from the Create Service Request on Submit list, select In Service Request Management, In Digital Workplace or No.

Option	Description
In Service Request Management	When a user submits an work order form, a corresponding request is created. The user can view this request (which indicates the work order status) through the Requester console. The Requester console uses the requester's BMC Helix ITSM login ID to determine who created the request and where to display it. Therefore, the requester must have a BMC Helix ITSMlogin ID.
In Digital Workplace	When a user submits an work order form, a corresponding request is created in BMC Helix Digital Workplace Catalog. The user do not receive any notification from BMC Helix ITSM. However, the user will receive a ticket creation notification from BMC Helix Digital Workplace Catalog. For more information, see Designing a workflow to send notification.
No	A regular incident submission notification created and no request is created. By default, this option is selected.