Learn about use cases and technical features of the service request, based on CRM 7.0 and SAP enhancement package 1. Understand which use cases the service request is suited for and how it differs from other service transactions, such as the service ticket.
Key Concept
From a business perspective, an SAP CRM service request is a customer inquiry for a pre-defined service. Prior to SAP CRM 7.0, the only available transactions for such inquiries were the service order and, within the Interaction Center, the service ticket, which you could use for Service Request Management. The service order, however, is usually a document with which you plan the provisioning of resources and service parts and therefore has a different focus than pure Service Request Management. As of SAP CRM 7.0, a dedicated service request object has been available. It offers many – but not all – of the same features as the service order and a few service request-specific features as well.
With the SAP CRM service request transaction functionality included in SAP CRM 7.0 (Figure 1), you can document any request a customer makes of your support organization and track its progress until it is completed. The service request allows you to document information such as the identities of the reporter and those responsible for processing the request, the status and priority of the request, the required completion date, and any devices or other entities that may be affected. To fulfill the request efficiently, the service request integrates with knowledge articles, a transaction that gives the user access to a database of predefined solutions to known issues.

Figure 1
An example service request
You usually use the service request transaction in shared service centers, technical/information help desks, and IT service desks, to name just the most typical cases. You would not use it for services that require spare parts or complex resource planning capabilities. For those, the service order is the object of choice, because it allows you to enter multiple service parts, services, and employees responsible per order, which is not the case in the service request.
Technical Overview
The SAP standard transaction type service request (SRVR) is based on the business object (BUS) type 2000223 (Service Request). In addition to the service request, a related BUS and transaction type are delivered: the master service request (BUS type 2000224, standard transaction type ITPR). The master service request offers the same functions as the service request, but also includes a bundling option that allows you to bundle several service requests into one master service request. This is helpful if several customers call about the same issue. Instead of processing each request individually, you can bundle them into a single master service request that can be processed all at once. Once the master service request is completed, all related service requests are updated. The update can be sent via email to the employees responsible for the individual service requests or even to the customers themselves.
Note
The SAP default key and description for the master service request is ITPR/IT problem management. This transaction type was defined with an IT service management scenario in mind. Problem management is a key process for IT service management, thus the transaction’s name. But master service requests are certainly generic enough to be useful outside IT service management scenarios. You can also easily create your own transaction types with keys or descriptions that fit your use cases.
Service Request Configuration
Service requests contain a number of configuration options. The sections below describe general configuration options as well as those specifically for service requests and master service requests.
Common Configuration Settings
To create your own service request or master service request type, you need to configure several customizing activities, much as you do in other service transactions:
- Define Partner Functions/Define Partner Determination Procedure
- Maintain Organizational Data Profile
- Define Text Objects and Text Types/Define Text Determination Procedure
- Define Date Types, Duration Types and Date Rules/Define Date Profile and Assign Date Profile to Transaction Type/Item Category
- Define Actions in Transaction
- Define Transaction Types (make sure to assign the CRM service request transaction category)
- Define Item Categories (the service request contains exactly one item, and you can use the standard service request item category SRQI as template for your own item category)
- Define Item Category Determination
- Define Copying Control for Transaction Types/Define Copying Control for Item Categories
- Define Status Profile for User Status
Multilevel Categorization
A new SAP CRM 7.0 feature, available for the service request as well as other transactions, is multilevel categorization. The service request has extensive multilevel categorization options, providing up to five categorization trees with up to 10 category levels each. To configure which catalog categories are available for which transaction types, follow IMG menu path Customer Relationship Management > CRM Cross-Application Components > Multilevel Categorization > Assign Transaction Types to Catalog Categories.
After configuring the multilevel categorization, you need to maintain the categories in the Category Schema view (Figure 2), which you can find, for example, in the Service Professional business role’s Service Operations work center under Categorization Schemas. Service request categorization schemas are maintained with the application ID Service Request/Incident.

Figure 2
Category schema view
In the categorization schema, you can assign, among other things:
- A service product for service request item determination (see Item Determination below)
- A service request template for the auto complete function in the service request
- One or more knowledge articles for automatic solution suggestion (see the section “Knowledge Articles for Service Request Management” later in this article)
Service Request-Specific Configuration Options
In addition to the generic configuration activities for the transactions mentioned above, there are several new service request-specific activities available as of SAP CRM 7.0, including item and service level agreement (SLA) determination, determination of settings for system proposals, and determination of a recommended priority by impact or urgency. These settings can be found in the SAP IMG under Customer Relationship Management > Transactions > Settings for Service Requests.
Because service requests are about delivering predefined services, the most notable configuration options I want to discuss further are item determination and SLA determination.
Item Determination
A service request is a transaction that requires exactly one item. To determine the service product for a service request item, you can let the system deduce the service product based on the service request’s multilevel categorization. Alternatively, you can implement your own determination logic via the Product Assignment for Creation of Service Items Business Add-In (BAdI).
If you want to make use of determination via categorization, make sure to assign the service product or products to the appropriate categories in the categorization schema. If no service product is defined for the categorization level selected in the service request but a service product is available on a higher-level category, the service product of the higher-level category is used for item determination.
In the IMG, you can not only activate item determination based on service request categorization, but also decide whether the category can be changed after the initial save and whether or not the change of the category should re-determine the service product. The service product represents the service you want to provide, and it can contain information such as service levels and pricing information which is used during service request processing.
Service Level Agreement Determination
Service Request Management gives you great flexibility to determine SLAs. Service level information, which consists of information coming from service profiles and response profiles, can be assigned to several SLA-relevant objects, such as contracts, products, objects, installed bases, and sold-to parties.
When configuring, define SLA determination procedures so that the system can automatically search for the service level information in the appropriate objects. For example, you could maintain specific service level information for your most important customers and define the SLA determination procedure so that the system first checks for service level information maintained for the service request’s customer. That way, customer service level information will take precedence over service level information from the service product. If no service level information is found there, the service product’s service levels are used for the service request’s date and deadline calculations.
In addition to the default configuration options, you can also implement your own logic in the SLA Determination BAdI.
Further Options
Apart from Item and SLA Determination, you can make use of some further options specific to service requests:
- Based on a combination of impact and urgency, you can decide which priority the system should recommend to the user.
- For functions such as Find Related Problem or Find Related Incidents, you can configure the situations in which the system should carry out searches for related transactions, for example, if the categorization of the two documents matches.
- The service request offers predefined duration types for work duration and total duration. Work duration usually only takes time into consideration if the service request is in status New or In Process. Total duration, on the other hand, calculates the whole time span from creation to completion. In the configuration, you can add or delete status as appropriate to be used for duration determination.
- The processing log is a flexible change log, in which you can control the information that is displayed and to which display group it belongs.
- Maintain number ranges for service requests and master service requests to distinguish different transaction types not only by their type, but also by different number ranges.
- For customer survey integration, see the section “New Service Request Features.”
Master Service Request-Specific Configuration Options
If you want to make use of the master service request in combination with the service request, all configuration settings mentioned for the service request also apply when creating master service request types.
To establish the master-slave relationship between the service request and master service request, follow menu path Transactions > Basic Settings > Define Object Reference Profile.
In addition, make sure to configure the activity Transactions > Settings for Service Requests > Define System Proposals for Related Transactions to make use of the Find Related Incidents and Find Related Problems functions. You can find example settings in the standard customizing for the standard transaction types ITIN, ITPR, and SRVR. See the IMG activity’s documentation for a detailed example.
In the SAP CRM application, once you create a service request, you can access the function Find Related Problems found in the service request’s menu bar More > Find Related Problems. If there are master service requests that fit your configuration settings (for example, if the service request and master service request contain the same categorization), the system will display them and you can assign the appropriate master service request to the service request. If you are processing a master service request, you can have the system propose all relevant service requests to you so that you can easily assign all appropriate service requests to the master service request. The Find Related Incidents (Service Requests) function is in the button bar of the assignment block Related Incidents.
Be sure to maintain an action profile, or use the standard action profile IT_PROBLEM_MANAGEMENT, to implement actions to update the service request’s status (standard action: IT_PROBLEM_UPDATE_STATUS) and to copy documents and attachments from the master service request to the service request (standard action: IT_PROBLEM_ATTACH_DOCUMENTS). To get to these profiles follow menu path Basic Functions > Actions > Actions in Transactions > Change Actions and Conditions > Define Action Profiles and Actions.
Knowledge Articles for Service Request Management
Yet another transaction type new to SAP CRM 7.0 for Service Request Management is the knowledge article (Figure 3).

Figure 3
An example of a knowledge article
Readers may be familiar with the solution database, which up until SAP CRM 7.0 was the only location in SAP CRM where companies could collect information about possible problems and their related solutions. The solution database had its own distinctive architecture that did not allow – per standard delivery –a solution to be copied from a completed service request.
With SAP CRM 7.0, such copying of solutions out of service requests or master service requests is now possible using the new knowledge article transaction type. The knowledge article adheres to the same overall transactional concept as do the service request and service order. It is based on the BUS type 2000106 and is tightly integrated into Service Request Management. For example, you can get a system proposal for one or more possible solutions based on the service request’s categorization. You can also easily create a knowledge article from a service request, and it is automatically linked to the service request. You have the same search, alerting, and email capabilities available for a knowledge article in the Interaction Center as you are used to from the solution database.
You can configure the knowledge article in the Define Transaction Types activity. Number ranges and authorization scopes for knowledge articles can be set in Customer Relationship Management > Master Data > Knowledge Articles. If you have, for example, assigned the authorization domain KNOWLEDGEARTICLE to the knowledge article transaction type, the authorization scope maintained for this authorization domain is available for selection in your knowledge articles. Based on this information, you can make sure that some knowledge articles can only be accessed by specific users (e.g., those knowledge articles with authorization scope Internal), whereas others can be accessed by all (e.g., knowledge articles with authorization scope Public).
Note
Two new authorization objects, which you should assign to users who need to work with knowledge articles in transaction PFCG, are available: CRM_KNOART (CRM Knowledge Article) and CRM_AUTHSC (CRM Authorization Scope).
New Service Request Features
Table 1 provides an overview of new features for the service request available with SAP CRM 7.0 enhancement package 1.

Table 1
New features for service requests available in SAP CRM 7.0 enhancement package 1
Comparison of the Service Request and Service Ticket
Last but not least, here is a short comparison of the service ticket, which was available within the Interaction Center before SAP CRM 7.0, and the service request:
If you are already using the service ticket for Service Request Management and you are satisfied with your implementation, there is no need for you to switch to the service request. However, if you have not yet implemented Service Request Management with SAP CRM, or if you are not satisfied with your current solution, you should evaluate the service request. Generally speaking, the service request offers similar features as the service ticket, but also has some extra functions as well as better integration with master service request and knowledge article management. Table 2 compares the two transactions in detail.

Table 2
Comparison of the service ticket and service request transactions
In addition, Service Request Management is available as part of the SAP CRM Rapid-Deployment Solution for Service, which is not the case for the service ticket.
Bettina Giese
Bettina Giese has been a product expert for SAP CRM since 2007, focusing most recently on rapid-deployment solutions for SAP CRM. In addition to SAP CRM, she has been responsible for topics such as IT service management, enterprise asset management, and human resources time management. She has worked at SAP AG since 1998. She has a master’s degree in information and language sciences.
You may contact the author at bettina.giese@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.