SRM Admin Guide PDF

BMC Service Request Management 7.6.
04
Administration Guide
January 2011
www.bmc.com
Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada
Address BMC SOFTWARE INC Telephone 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.
© Copyright 2006-2011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent
and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and
logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the
property of their respective owners.
IT Infrastructure Library® is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc.,
under license from and with the permission of OGC.
ITIL® is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the
U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.
Linux is the registered trademark of Linus Torvalds.
Oracle, Java, and JavaScript are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
UNIX is the registered trademark of The Open Group in the US and other countries.
The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or
licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product
and to the proprietary and restricted rights notices included in the product documentation.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF
THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to
restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and
DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX
77042-2827, USA. Any contract notices should be sent to this address.
Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or email. To expedite your inquiry, please see “Before Contacting BMC Software.”
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support. From this website, you can:
■ Read overviews about support services and programs that BMC Software offers.
■ Find the most current information about BMC Software products.
■ Search a database for problems similar to yours and possible solutions.
■ Order or download product documentation.
■ Report a problem or ask a question.
■ Subscribe to receive email notices when new product versions are released.
■ Find worldwide BMC Software support center locations and contact information, including email addresses, fax
numbers, and telephone numbers.
Support by telephone or email

In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or
send an email message to customer_support@bmc.com. (In the Subject line, enter
SupID:<yourSupportContractID>, such as SupID:12345.) Outside the United States and Canada, contact
your local support center for assistance.
Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:
■ Product information
— Product name
— Product version (release number)
— License number and password (trial or permanent)
■ Operating system and environment information
— Machine type
— Operating system type, version, and service pack
— System hardware configuration
— Serial numbers
— Related software (database, application, and communication) including type, version, and service pack or
maintenance level
■ Sequence of events leading to the problem
■ Commands and options that you used
■ Messages received (and the time and date that you received them)
— Product error messages
— Messages from the operating system, such as file system full
— Messages from related software
License key and password information
If you have a question about your license key or password, contact Customer Support through one of the following
methods:
■ E-mail customer_support@bmc.com. (In the Subject line, enter SupID:<yourSupportContractID>,
such as SupID:12345.)
■ In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support
center for assistance.
■ Submit a new issue at http://www.bmc.com/support.
Contents
Preface 13
Type of users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
BMC Service Request Management documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 1 Introducing BMC Service Request Management 17

What is BMC Service Request Management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Benefits of BMC Service Request Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Main components of BMC Service Request Management . . . . . . . . . . . . . . . . . . . 20
Overview of setup tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Set up the framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Create application templates (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Create AOTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Create PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Create SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Configure approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Configure assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Configure entitlements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
What users see . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Basic steps to get started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
About service requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Service request life cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Service request status reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Customizing the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapter 2 Getting started 35

Opening application consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
About the Application Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Configuration prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Defining the application administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
User roles and permission groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
User access to application consoles and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Application functional roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Contents 5
Performing a standard configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Creating a company. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Creating organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Creating locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Creating support groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Creating people information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Creating support staff members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Creating non-support staff people . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Creating product categories (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Creating operational categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Managing standard configuration data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Creating on-behalf-of definition rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
How on-behalf-of functionality works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Allowing unknown users access to the Request Entry console. . . . . . . . . . . . . . . . . . . 60
Configuring business hours and holidays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configuring mid tier and multi-tenancy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Configuring the mid tier to view DVF fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 3 Configuring navigational categories 65

About defining navigational categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Defining global navigational categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Defining company navigational categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Sorting navigational categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 4 Creating application templates and application object templates 73

About application templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Parameters for creating application templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
About work order templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Configuring work order templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Modifying or deleting work order templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Creating change templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Creating incident templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
About application object templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Defining AOTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
About registering application templates with AOTs . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Chapter 5 Creating process definition templates 87

About PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Understanding data flow in PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
How PDTs are defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
How PDTs work when a user requests a service . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
About variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Creating PDTs—Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6 Administration Guide
Creating a standard PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Opening the Process Definition Template form and getting started . . . . . . . . . . . 91
Designing the PDT flow in the Visual Process Editor . . . . . . . . . . . . . . . . . . . . . . . 92
Defining variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Defining the properties of the process objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Mapping the direction of the data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Defining General Details in a standard PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Adding work information to the PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Checking use of this PDT by other PDTs and SRDs. . . . . . . . . . . . . . . . . . . . . . . . . 97
Creating a quick launch PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
About using the Service Catalog Manager Console to manage PDTs . . . . . . . . . . . . . 99
Search criteria—Managing PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Using the Visual Process Editor to view processes from the Service Catalog
Manager Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Example of creating PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Dynamic data flow—mapping data between applications . . . . . . . . . . . . . . . . . . . . . 105
About building PDTs that use dynamic data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Chapter 6 Creating service request definitions 109

Service request definition life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
How SRDs are related to Atrium Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Creating SRDs—Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
System SRDs shipped with the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Creating a standard SRD with the Service Request Definition form . . . . . . . . . . . . . 116
Creating a quick launch SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Adding a PDT to an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Adding a standard process template to an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Adding a quick launch process template to an SRD . . . . . . . . . . . . . . . . . . . . . . . 127
About adding questions and mapping variables and service request fields . . . . . . 128
Adding questions to an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Mapping variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Mapping service request fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Concatenating multiple inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Adding a service CI to an SRD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Selecting service CIs for an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Setting approvals for the service request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Associating SRDs with packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Selecting entitlement information for an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Modifying entitlement rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Creating People qualifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Adding work information to SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Adding attachments to a Work Info entry that is attached to an SRD . . . . . . . . 145
Setting approvals for an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Defining SRD approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Adding alternate approvers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Submitting SRDs for approval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Viewing the approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Approving SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Contents 7
Defining service targets for an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Associating service targets with an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Configuring service targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Adding surveys to an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Managing SRDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
About modifying SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Searching for SRDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Changing the SRD image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Configuring visible fields in the Request Entry console . . . . . . . . . . . . . . . . . . . . 161
Managing service request notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Viewing the SRD audit log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Defining SRD customer information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Adding an advanced interface form to an SRD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Viewing metrics about an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Adding an attachment to an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Deploying SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Taking an SRD offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Restoring the SRD to the online state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Resetting the date of an expired SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
About building SRDs that use dynamic data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Creating an SRD that tests the Change PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Creating an SRD that uses the Incident PDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Miscellaneous configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Defining service request definition settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Defining SRD levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Configuring service request image definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Managing SRD images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Configuring survey questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Defining behavior rules for surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Configuring request entry preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Configuring service request HTML definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Defining default Request Entry console preferences . . . . . . . . . . . . . . . . . . . . . . . 182
Configuring service request query exclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
How activity log information is passed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Viewing statistics of searched terms on the Request Entry console . . . . . . . . . . . . . . 184
Setting Service Catalog Manager Console preferences . . . . . . . . . . . . . . . . . . . . . . . . . 186
Chapter 7 Using the Service Request Designer 189

Overview of the Service Request Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Starting the Service Request Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Completing the Description section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Completing the Fulfillment Process section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Completing the Approvers section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Completing the Entitlements section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Completing the Options section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Completing the Deployment section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Chapter 8 Creating questions to use with SRDs 203
About creating questions to use with SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Defining text questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Defining radio button questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Defining check box questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Defining range questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
About menu questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Defining static menu questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Defining query menu questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Defining dynamic query menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Defining date and time questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Chapter 9 Configuring approvals 217

Approvals and the Approval Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Creating individual and group approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Approvals for service requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Configuring a custom approval chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Creating approver mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Approvals for SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Approval states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Approval state transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Process types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Company versus global approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Setting up approval processes for your company . . . . . . . . . . . . . . . . . . . . . . . . . 234
Configuring the Request ID link in Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . 238
Chapter 10 Configuring packages and entitlements 239

Overview of configuring entitlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Creating packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Editing packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Deleting packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Enabling entitlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Creating entitlement groups (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Creating entitlement rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Create people entitlement definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Adding service request definition qualifications . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Validating users (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Chapter 11 Using the Work Order Management application 247

Work order manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Work order assignee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
The Work Order Management application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Work Order form views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Best Practice view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Deploying the Classic view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
The Work Order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Contents 9
Creating work orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Entering work information for a work order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Using the Classification tab to classify work orders . . . . . . . . . . . . . . . . . . . . . . . . 256
Relating work orders to other objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Adding details to a work order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Searching for work orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Using Defined Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Using custom searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Creating a custom search with advanced qualifications . . . . . . . . . . . . . . . . . . . . 260
Adding or modifying a customer profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Configuring the search type for Customer and Contact fields . . . . . . . . . . . . . . . 262
Configuring the People form to appear when selecting customer or contact. . . 263
Selecting work order templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Viewing details of a service request associated with the work order . . . . . . . . . . . . 265
Viewing the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Creating reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Viewing, modifying, and deleting reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Sending email messages and pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Work order life cycle—Status transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Assigning work orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Reassigning work orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Receiving notifications of work order assignments . . . . . . . . . . . . . . . . . . . . . . . . 275
Fulfilling work orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Viewing truncated data in a work order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Working with tasks as a request manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Work order task groups and tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Assigning tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Assigning a sequence number to task groups and tasks . . . . . . . . . . . . . . . . . . . . 278
Reassigning tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Planning the time for tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Adding financial information to a task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Working with tasks with work orders as an assignee. . . . . . . . . . . . . . . . . . . . . . . . . . 280
Searching for assigned tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Viewing task groups and tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Viewing the flow of a task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Accepting assigned tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Modifying tasks for work orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Adding work information to a task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Tracking task efforts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Working with a task in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Adding ad hoc tasks to work orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Adding predefined task group or task templates to a work order. . . . . . . . . . . . 288
Canceling tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Closing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Service targets in Work Order Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Creating service targets for a work order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Configuring work order rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Updating assignment availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Updating your profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Setting Work Order Console preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Chapter 12 Configuring assignments 299

Creating assignment routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Creating group assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Assignment events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Automatic assignment to individuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Chapter 13 Importing and Exporting PDTs and SRDs 305

Exporting SRDs and PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Exporting supporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Importing SRDs and PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
About the Version and Patch fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
About importing data from another company . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Importing SRDs linked to Atrium Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . 310
Viewing the history of imports and exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
About migrating the application from test to production environments . . . . . . . . . 313
Exporting definitions from your test environment . . . . . . . . . . . . . . . . . . . . . . . . 313
Exporting additional supporting data from your test environment . . . . . . . . . . 314
Exporting SRDs from your test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Importing definitions to your production environment . . . . . . . . . . . . . . . . . . . . 316
Importing data to your production system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Importing SRDs to your production environment . . . . . . . . . . . . . . . . . . . . . . . . . 316
Chapter 14 Opening the Request Entry console in context 319

Using the Context URL Builder utility to generate URLs . . . . . . . . . . . . . . . . . . . . . . 320
Using context fields when creating launch-in-context URLs . . . . . . . . . . . . . . . . . . . 324
Manually creating URLs to open the Request Entry console in context . . . . . . . . . . 327
About using an Open Window action to open the Request Entry console in context. .
327
Examples of launch-in-context URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Appendix A Internationalization and localization 329

About internationalization and localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Supported languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
About localizing the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Locale fallback mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Localizing BMC Service Request Management objects . . . . . . . . . . . . . . . . . . . . . 332
Configuring the BMC Remedy AR System server for localization. . . . . . . . . . . . . . . 333
Localizing navigational categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Localizing SRD levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Localizing questions to use with SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Remapping questions to an SRD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Localizing AOTs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Localizing PDTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Localizing SRDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Contents 11
Localizing surveys in an SRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Localizing advanced interface forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Configuring advanced interface forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Finishing localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
About localization problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Using the localization utility to change the locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Appendix B Creating and using advanced interface forms 345

Advanced interface forms—Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Creating advanced interface forms from templates . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Passing requestable offering data to advanced interface forms . . . . . . . . . . . . . . 350
Registering advanced interface forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Relating Mapped and Details tab fields in the Work Order Template form . . . . . . . 353
Creating SRDs with advanced interface forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Mapping fulfillment application fields to the service request fields . . . . . . . . . . . . . 354
Requesting a service with an advanced interface form . . . . . . . . . . . . . . . . . . . . . . . . 355
Appendix C Using the mid tier prefetch utility 357

Preloading specified forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Tips for using prefetch with Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Prefetch components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Glossary 363
Index 369
Preface
This guide describes how to administer BMC Service Request Management. This
application runs on the BMC Remedy Action Request System (BMC Remedy
AR System) platform and consumes data from the Atrium Service Catalog.
BMC Service Request Management provides a consistent user interface where
users can request a service or report an incident through the service desk. Users or
service desk staff can select services from a Service Catalog that the business
service catalog manager sets up.
BMC Service Request Management works with other processes, such as BMC
Remedy Incident Management and BMC Remedy Change Management, to resolve
a user’s request or incident. BMC Service Request Management manages the entire
process, from submission to completion.
Type of users
This guide is for the following application users:
Application administrators who administer the application.
Request catalog managers and business service managers who set up the service
catalog and define the process for each catalog offering.
Service desk staff (or the frontline support staff) who handle customer calls or
web submissions, create or modify service requests, and communicate the
resolutions.
Fulfillment providers (or backline support staff) who work on change requests,
incidents, or work orders that are generated from service requests.
NOTE
Documentation is available to users who report incidents, make change requests,
or create work orders from the public view of a service request. It consists of a
separate set of help files that are accessed from the web-based forms by clicking the
Help link.
Preface 13
BMC Service Request Management 7.6.04
BMC Service Request Management

documentation
The following table lists the documentation available for the application.
Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is
available on product installation DVDs and the Customer Support website
(http://www.bmc.com/support). You can order printed documentation from the
Customer Support website.
NOTE
To access the support website, you need a support contract.
You can access application help by clicking Help links in the application.
Title Document provides Audience

BMC Service Request Management Information about new features and known Everyone
Release Notes issues.
BMC Service Request Management Procedures for installing the application. Administrators
Installation Guide
BMC Service Request Management Procedures for configuring and administrating the Administrators
Administration Guide application. Replaces the separate administrator’s
and configuration guides that were provided for
previous releases of the application.
BMC Service Request Management User’s Procedures for using the application. Everyone
Guide
Best Practices: Deploying, Extending, and Best practices for creating and deploying BMC Administrators/
Customizing BMC Service Request Service Request Management in your enterprise. Developers/
Management 7.6.00 white paper
Programmers
BMC Remedy Action Request System Information about configuring AR System servers Administrators
Configuration Guide and clients, localizing, importing and exporting
data, and archiving data.
BMC Remedy Action Request System Information about AR System applications and Developers
Form and Application Objects Guide their user interface components, including forms,
fields, views, menus, and images.
BMC Remedy Action Request System Topics on installation and configuration of the Users and
BMC Remedy Approval Server Guide Approval Server, how to use the Approval Server, administrators
and understanding the approval workflow.
BMC Remedy IT Service Management Procedures for configuring the BMC Remedy IT Administrators
Configuration Guide Service Management applications.
BMC Remedy Service Desk: Incident Procedures for using the BMC Remedy Service Everyone
Management User’s Guide Desk: Incident Management application.
BMC Service Request Management documentation
Title Document provides Audience

BMC Remedy Change Management Procedures for using the BMC Remedy Change Everyone
User’s Guide Management application.
BMC Service Level Management User’s Procedures for using the BMC Service Level Everyone
Guide Management application; includes new features
and overview.
Preface 15
Chapter
1 Introducing BMC Service

Request Management
This section provides an overview of the BMC Service Request Management

application, describes user roles, and provides other general information.
The following topics are provided:
What is BMC Service Request Management? (page 18)
Overview of setup tasks (page 20)
Basic steps to get started (page 24)
About service requests (page 30)
Customizing the application (page 33)

What is BMC Service Request Management?

BMC Service Request Management enables the IT department and other business
departments to define offered services, publish those services in a service catalog,
and automate the fulfillment of those services for their users. With BMC Service
Request Management, users can help themselves, which reduces the number of
requests coming into the service desk. This enables IT professionals to focus on
more mission-critical activities, such as resolving incidents related to service
failures and restoring critical services. The application also provides the ability to
automate workflows for each service, enforcing consistency of process and faster
fulfillment of the request.
Figure 1-1 illustrates the BMC Service Request Management solution.
Figure 1-1: BMC Service Request Management solution
BMC Service Request Management shares a common foundation with BMC

Remedy IT Service Management—both applications are built on BMC Remedy
Action Request System. BMC Service Request Management leverages the
foundational elements of the BMC Remedy IT Service Management Suite (for
example, workflow, approvals, task management, notification, and email). This
integration platform simplifies and reduces the management costs.
BMC Service Request Management also captures the relationships between
catalog items and business service definitions through its integration with the
Atrium Service Catalog.
BMC Service Request Management ties into BMC Service Level Management
(BMC SLM) so that request service targets are rolled into comprehensive service
level agreements and contracts.
What is BMC Service Request Management?
BMC Service Request Management is integrated with BMC Remedy Change

Management and BMC Remedy Incident Management. You can also integrate
BMC Service Request Management with other third-party applications.
Benefits of BMC Service Request Management

BMC Service Request Management solves the business problem of customers not
knowing where or how to request services. They might not even know which
services IT or other business service organizations provide. The application helps
internal groups manage customer expectations. For example, it provides
information about the level of service employees should expect when their PC
hard drive is broken or they have lost their password.
In addition, support organizations do not always understand how much money is
spent on service fulfillment or its quality. They frequently do not know where
requests are coming from, what types of requests they receive most often, what
their service goals are, and whether they are meeting those goals. The application
helps support organizations understand customer expectations and how to fulfill
them. BMC Service Request Management can show the value that support
organizations provide to the business by demonstrating the actual cost of the
services they offer and providing insight into the resources necessary when
providing certain kinds of services.
Following are some of the benefits of using the application:
Standardized catalog of services—In an easy-to-use web user interface, users
can review the available services to which they are entitled, request them, and
see their status online. Services are described in easy-to-understand language
that makes sense for the audience, not technical or other jargon. Service
providers set expectations by describing how much services cost and how long
it takes to deliver them. Most important, service providers can set clear
expectations to customers about when the service will be delivered.
Integration of service catalog with fulfillment processes—Service requests are
transparently connected to fulfillment processes and providers. This seamless
integration makes sure service delivery is consistent and reduces service
delivery costs through automation.
Complete tracking and management of requests from start to finish—You can
build and manage service targets for the delivery of all services through the
entire life cycle of the service request. For example, you can demonstrate that a
request for a new server takes four days to fulfill. You can make sure that service
delivery is on time and meets customer satisfaction. You can enable more
effective management of customer demand, your resources, and business costs.

Main components of BMC Service Request Management

The application consists of the following main components:
Self-service interface—Entry point where users can submit requests from the
service catalog. It provides user-friendly access to services, without exposing the
implementation details to the service requester.
Service catalog—Repository of available and agreed upon services that IT and
other business services organizations provide to customers in terms that are
relevant to users, described in the customer’s language. The service catalog
maintains operational information about available services that users can select.
Each service request definition (SRD) can have a business process defined and
automated. SRDs provide the characteristics required to facilitate the selection
and execution of delivery for a given service offering. This includes attributes,
such as categorization, effective start and end dates, pricing information,
approval and service level management criteria, as well as the definition of
application objects that will support the delivery of a service.
Request management—Builds the processes in support of the services in the
catalog and manages the execution of the request processes. Request
management is integrated with the fulfillment applications that perform the
work of the request (for example, an incident, change request, or work order).
Overview of setup tasks

This section provides an overview of what is involved in setting up the BMC
Service Request Management system. You are essentially setting up a catalog of
requestable offerings from which users can select and submit a service request.
Examples of services requests include:
Reporting issues with IT systems
Requesting changes to employee data
Setting up equipment, space, and accounts for new employees.
Figure 1-2 shows the basic steps for getting up and running.
Figure 1-2: Getting BMC Service Request Management up and running
Analyze
Before you begin using the application, you need to analyze your processes and
roles. Ask yourself what services users will be requesting. If you are integrating
with other applications (such as BMC Remedy Change Management or others),
some of the services are already configured.
You might start by listing all the user requests your company might have. Then,
organize the user requests into categories. For example, an IT category might
include a service for setting up a new employee’s computer, phone, and email; a
Facilities category might include a service for moving an office or replacing a
broken light bulb. In BMC Service Request Management, these services are defined
in service request definitions (SRDs).
When you know the service requests that you want for your users, you can break
those services down into:
Processes—In BMC Service Request Management, these processes are called
process definitions templates (PDTs). A process (or PDT) is used to group steps into
a process that is part of a service request. For example, if a user submits a request
for a software program to be installed, a company process might include these
three processes: order the software, place the software in the inventory system,
and install the software.
Process steps—In BMC Service Request Management, these process steps are
called application object templates (AOTs). Process steps (or AOTs) are the steps
required to complete a process. For example, the steps required to order
software might be to contact the vendor, create a purchase order, and so on. The
AOT represents how the process is fulfilled.
Optionally, you can create an application template, which is referenced in an AOT
to prepopulate fields in the fulfillment record that the service request creates.
Finally, you can set up your Questions Library so that you will have questions
ready to map from service requests to the backend fulfillment applications, or you
can create questions within the SRD. See “Creating questions to use with SRDs” on
page 203.
Set up the framework

Before you begin configuring services, set up users, and assign these users to the
appropriate permissions and functional roles. You can also associate them with the
appropriate support groups, if necessary. BMC Service Request Management
includes some predefined roles. Additionally, set up permissions for users and
groups to ensure that the appropriate people have access to the forms. For more
information, see “User roles and permission groups” on page 41 and “User access
to application consoles and functions” on page 44.
You must also set up approvers in the People form. For more information, see
“Creating individual and group approvers” on page 218. Setting up approvers
allows you to have SRDs approved before they are made available to users on the
Request Entry console, and it allows you to set up an approval process for service
requests from users.

Additionally, you must configure the navigation categories for the services that
you want to provide. For more information, see “Configuring navigational
categories” on page 65.
Create application templates (optional)

Application templates are used to pre-populate fields in the fulfillment record. You
can use application templates for routine incidents, standard changes, or work
orders that users frequently request. For example, you can use:
Work order templates with the Work Order Management application, which is
included with BMC Service Request Management.
Change templates with the BMC Remedy Change Management application.
Incident templates with the BMC Remedy Incident Management application.
NOTE
Application templates are sometimes called “application fulfillment templates”
because you create them from the underlying applications that fulfill their tasks
(for example, Work Orders or BMC Remedy Change Management), not BMC
Service Request Management.
For more information, see “Creating application templates and application object
templates” on page 73.
Create AOTs
An AOT is the interface to the back-end application that creates the backend
fulfillment application record. In the AOT, define the company, application, and
application template (if any).
For more information, see “Creating application templates and application object
Quick tip: To define an AOT, use the Application Object Template form. To access
this form, from the Application Administration Console, click the Custom
Configuration tab. From the Application Settings list, choose Service Request
Management > Application Configuration > Define Application Object Template,
and click Open.
Create PDTs
After creating the AOTs, you must create a process definition template (PDT),
which is the intermediate object that relates AOTs to SRDs. In other words, a PDT
can define the process used to fulfill a specific service request, for example,
creating an incident request and a series of change requests for a hard drive
upgrade. PDTs are not directly used by themselves; they are intended for use only
with SRDs.
PDTs can:
Reference one or more AOTs and other PDTs.
Be launched in a series or in parallel.
Include conditions to determine whether an AOT or PDT is launched.
Quick tip: To define a standard PDT, use the Process Definition Template form. To
access this form, from the IT Home page, click the Service Catalog Manager
Console link. Click Console Focus in the left navigation pane, and click Process.
For more information, see “Creating process definition templates” on page 87.
Create SRDs
After you have your application templates, application object templates (AOTs),
and process definition templates (PDTs) created, you can create your service
request definition (SRD). An SRD represents a service offering that users can
request through the Request Entry Console.
When you create an SRD through the Service Request Definition form, you can
change the status to Request for Approval. If no approvals are required, the status
changes to Deployed. If approvals are required, when the SRD is approved, the
status changes to Deployed, and the SRD is online so that users can request a
service.
Quick tip: To define an SRD, use the Service Request Designer. To access this
wizard, from the IT Home page, click the Service Request Designer link under the
BMC Service Request Management heading. To manage an SRD and track its
progress from Draft to Deployed, use the Service Request Definition form.
For more information, see “Creating service request definitions” on page 109.
Configure approvals
Optionally, you can set approvals for SRDs and service requests. Use the Service
Request Definition form to configure approvals for an SRD and its corresponding
service request. Approvals for SRD and service requests are optional.
For more information, see “Configuring approvals” on page 217.

Configure assignments
You can set up assignments to assign a service request to a service request
coordinator. Then, you can assign the backend fulfillment requests that are created
to the support groups to fulfill them.
Quick tips:
To configure assignment routing, on the Standard Configuration tab of the
Application Administration Console, select the company. Then, click the Create
link next to Assignment.
To configure group assignments, use the Group Assignment form.
For more information, see “Configuring assignments” on page 299.
Configure entitlements
Optionally, you can configure entitlements. Entitlements enable you to define
which users can access service offerings to create service requests.
Entitlements are useful for enterprise customers or companies using multi-tenancy
because users can view only the available services to which they are entitled. Small
or medium-sized companies might not need to add this extra level of access
control.
Quick tip: To define entitlements, use the Entitlement Console. To add them to
SRDs, use the Entitlements tab of the Service Request Definition form.
For more information, see “Configuring packages and entitlements” on page 239.
What users see

Users do not see all of the backend processes that you configured—application
templates, AOTs, PDTs, and SRDs. They simply see a catalog of services that they
can use to submit a service request. BMC Service Request Management makes it
simple for users to request a service or report a problem. Then, all of the objects you
configured go to work and help the backend team approve, track, and fulfill the
request.
Basic steps to get started

To perform the basic level of application configuration, perform the steps listed in
the following table.
You should have a basic understanding of performing common configuration
tasks using the Application Administration Console (for example, you know how
to log into the IT Home Page, define users in the People form, and so on).
Action Where to begin For more information

1. Configure your company or organization
Perform standard configuration of From the Application “Managing standard
your company or organization Administration Console, click the configuration data” on page 56
(such as People, Company, Standard Configuration tab. BMC Remedy IT Service
Location, and Site information). Management Configuration Guide
Note: If you have already have
performed this step in BMC
Remedy IT Service Management,
you can ignore this step, except for
creating assignment routing for
the application. See “Creating
assignment routing” on page 300.
2. Define users
Define the application From the Application “Defining the application
administrator. Administration Console, click the administrator” on page 39
Standard Configuration tab. Then,
select the Create link for People.
Define the support staff with From the Application “User roles and permission
appropriate privileges. Administration Console, click the groups” on page 41
Standard Configuration tab. Then, “Creating support groups” on
select the Create link for People. page 49
“Creating support staff
members” on page 50
3. Configure settings for BMC Remedy Mid Tier
Configure the Application Settings From the Application “Configuring mid tier and multi-
form with the mid tier path. Administration Console, click the tenancy settings” on page 62
Custom Configuration tab. Then,
select Service Request Management
>Advanced > Application Settings.
Verify that the mid tier URL needed From the AR System “Configuring the mid tier to view
to identify the DVF components is Administration Console, select DVF fields” on page 63
correct. System > General > Server
This step is necessary to make sure Information.
that, for example, the Request Entry
console shows the navigational
categories correctly.


4. Configure BMC Service Request Management building blocks
Create application templates with From the Application “About application object
pre-set values. Administration Console, click the templates” on page 82
Custom Configuration tab. Then, “About work order templates”
select Service Request Management on page 76
> Work Order > Work Order “Creating change templates” on
Template. page 81
If BMC Remedy IT Service “Creating incident templates” on
Management applications are page 82
installed:
Select Change Management >
Template > Template.
Select Incident Management >
Template > Template.
Define the application object From the Application “Defining AOTs” on page 83
template (AOT). Administration Console, click the
> Application Configuration >
Define Application Object
Template.
5. Configure navigational categories
Create navigational categories, From the Application “Configuring navigational
including descriptions and images. Administration Console, click the categories” on page 65
> Navigational Categories >
Category Management.
View, modify, or create images. From the Application “Configuring service request image
Administration Console, click the definitions” on page 174
> Request Entry Management >
Service Request Image
Configuration.
6. Prepare settings, questions, levels, and images for SRDs
Define default behavior of SRDs. From the Application “Defining service request
Administration Console, click the definition settings” on page 173
> Advanced > Service Request
Definition Settings.
Define the questions to use with From the Application “Creating questions to use with
SRDs. Administration Console, click the SRDs” on page 203
> Application Configuration >
Define Questions Library.

Define SRD levels. From the Application “Defining SRD levels” on page 174
Administration Console, click the
> SRD Level > SRD Level.
Relate images to SRDs that appear From the Application “Managing SRD images” on
in the Request Entry console. Administration Console, click the page 175
Service Request Definition Image
Management.
Configure survey questions for From the Application “Configuring survey questions” on
requesters. Administration Console, click the page 176.
> Advanced > Survey
Configuration.
7. Configure miscellaneous items
Define default behavior for From the Application “Defining behavior rules for
surveys. Administration Console, click the surveys” on page 177
> Advanced > Preferences.
View or modify HTML definitions. From the Application “Configuring service request
Administration Console, click the HTML definitions” on page 181
> Advanced > Service Request
HTML Configuration.
Update the default Preference From the Application “Defining default Request Entry
record for the Request Entry Administration Console, click the console preferences” on page 182
console. Custom Configuration tab. Then,
Default Console Preference.
View, modify, or create search From the Application “Configuring service request
exclusions. Administration Console, click the query exclusions” on page 183
Service Request Search Exclusion
String.
(optional) Configure the “classic From the Application “Deploying the Classic view” on
view” of the Work Order console. Administration Console, click the page 250
select Foundation > Advanced
Options > View Selection
Framework - Deploy View.


8. Configure work order templates and rules
Modify or delete work order From the Application “Modifying or deleting work order
templates. Administration Console, click the templates” on page 80
> Work Order > Work Order
Template.
Configure work order rules. From the Application “Configuring work order rules” on
Administration Console, click the page 295
> Work Order > Rules.
9. Configure service target defaults (applies only if BMC SLM is installed)
Modify default service target From the Application “Configuring service targets” on
templates. Administration Console, click the page 155
> Service Level Management >
Service Target Defaults.
10. Configure approval process and mappings
Define approvals for each phase in From the Application “Setting up approval processes for
the business process for a company Administration Console, click the your company” on page 234
or category. Custom Configuration tab. Then,
select Foundation > Advanced
Options > Approval Process
Configuration.
Map the BMC Service Request From the Application “Creating approver mappings” on
Management approval processes to Administration Console, click the page 223
individuals and groups for an Custom Configuration tab. Then,
organization. select Service Request Management
> Approval > Approval Mappings.
11. (optional) Configure assignment
Create assignment routing for BMC From the Application “Creating assignment routing” on
Service Request Management. Administration Console, click the page 300
Standard Configuration tab. Then,
select Assignment.
Create group assignments for BMC From the Application “Creating group assignments” on
Service Request Management. Administration Console, click the page 301
Note: Even if you have already
select Foundation > Configure
creating assignment routing for
Assignment > Configure
other BMC Remedy IT Service
Application Assignment.
Management applications, you
must configure the Service
Request Assignee, Work Order
Manager, and Work Order
Assignee.

12. (optional) Configure entitlement
Create entitlement groups From the Application “Creating entitlement groups
(optional). Administration Console, click the (optional)” on page 243
> Entitlement > Entitlement Group
Management.
Create people entitlement rules. From the Application “Create people entitlement
Administration Console, click the definitions” on page 244
> Entitlement > Entitlement
Management.
Add service request definition From the Application “Adding service request definition
qualifications for entitlement. Administration Console, click the qualifications” on page 245
Management.
Validate users (optional). From the Application “Validating users (optional)” on
Administration Console, click the page 246
Management.
Configure on-behalf-of definition From the Application “Creating on-behalf-of definition
rules for users (optional). Administration Console, click the rules” on page 58
Note: On-behalf-of definition rules
can also be used for service
> Entitlement > On Behalf Of
requests, even if entitlement is
Management.
not enabled.
13. Create a process definition template (PDT)
Create a process definition From the Service Catalog Manager “Creating process definition
template (PDT). Console, select Focus > Process. templates” on page 87
14. Create a service request definition (SRD)
Create a service request definition From the Service Catalog Manager “Creating service request
(SRD), and deploy it. Console, select Focus > Request definitions” on page 109
Definition.
After you deploy the SRD, it automatically appears in the Request Entry console.
Users can then submit request for the services available to them.

About service requests

A service request is the request record that is generated from the service request
definition (SRD). Service requests are created from SRD selections by users,
support, and automated tools. A service request is the parent object that manages
and tracks the execution of a selected SRD.
Although service requests inherit characteristics from the selected SRD on which
they are based, they have a life cycle of their own. As described in “Service request
life cycle” on page 31, a service request has various states to indicate its position in
the life cycle. Approvals can be required for certain state transitions. A service
request might also send notifications at certain points in its life cycle to alert users
that a certain event has occurred.
NOTE
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 Service Request

(Request Entry) console, backend fulfillment application entries might not be
created or updated immediately. A delay of up to 10 minutes can occur.
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.
About service requests
Service request life cycle

Service requests go through many state transitions as they progress.
Figure 1-3: Service request life cycle
NOTE
The In Review state is an internal, temporary state.

The following table defines all the possible state transitions of service requests from
one state to another state. Notifications occur when state transitions or errors occur.
“To” state
Draft In Waiting Pending Planning In Completed Rejected Cancelled Closed
Review Approval Progress
“From” Draft Yes No No No No No No Yes No
state Waiting No No Yes Yes No No Yes Yes No
Approval
Pending No No Yes Yes No No No Yes No
Planning No No No Yes Yes Yes No Yes No
In No No No Yes No Yes No Yes No
Progress
Completed No No No No No No No No Yes
Rejected Yes No Yes No No No No Yes No
Cancelled No No No No No Yes No No Yes
Closed No No No No No No No No No
Service request status reasons

When a service request enters a state, status reasons can be included. Not all states
include status reasons. The following table shows the available status reasons.
Service request status Status reasons

Pending Approval
Review
More Information
Completed Successful
Successful With Issues
Cancelled By User
By Provider
Closed Cancelled
Customizing the application
Customizing the application

BMC Service Request Management is built on BMC Remedy AR System. This
enables experienced administrators, workflow developers, and consultants to
extend and customize the behavior of the advanced interaction forms supplied
with BMC Service Request Management to meet the changing needs of your
organization and to integrate it with other applications. BMC offers courses for
beginners through advanced workflow developers.
For more information, visit BMC Software education at:
http://www.bmc.com/education/
For information about extending the functionality of BMC Service Request
Management, visit the Customer Support website at:
http://www.bmc.com/support

Chapter
2 Getting started
This section describes how to set up the application.
NOTE
You must have the SRM Administrator permission to configure the application.

Opening application consoles (page 36)
About the Application Administration Console (page 37)
Configuration prerequisites (page 38)
Defining the application administrator (page 39)
User roles and permission groups (page 41)
User access to application consoles and functions (page 44)
Application functional roles (page 46)
Performing a standard configuration (page 46)
Managing standard configuration data (page 56)
Creating on-behalf-of definition rules (page 58)
Allowing unknown users access to the Request Entry console (page 60)
Configuring business hours and holidays (page 61)
Configuring mid tier and multi-tenancy settings (page 62)
Configuring the mid tier to view DVF fields (page 63)

Opening application consoles

The following procedures describe how to open application consoles.
To open application consoles by using a browser

1 Type the following URL in to your browser’s address bar:
http://webServer:port/arsys/
webServer is the fully qualified name of the BMC Remedy Mid Tier system,
specified in the format server_name.company.com.
port is an optional port number, which is needed if the web server is not on the
default port (port 80).
2 Enter your user name and password, and click Login.
3 In the navigation pane of the Overview Console, click one of the application
console links, such as Service Catalog Manager Console.
TIP
Create a favorite or bookmark for each console you want to access directly.
To open application consoles by using BMC Remedy User

1 Choose Start > All Programs > BMC Software > AR System > BMC Remedy User.
2 In the Login dialog box, follow these steps:
a In the User Name field, type your user name.
NOTE
Guest users and unknown users who are not associated with a company must log
in using the default set up by their company.
b In the Password field, enter your password.

c In the Preference Server field, specify the server name if your administrator set
up a preference server for centralized user preferences.
3 Click OK.
If the IT Home Page does not open automatically:
a Choose Tools > Options.
b In the Options dialog box, click the Home Page tab.
c Select the Open the Home Page Automatically option.
d Log out of BMC Remedy User, and log in again.
4 In the navigation pane, click one of the application console links, such as Service
Catalog Manager Console.
About the Application Administration Console
About the Application Administration Console

You configure the application using the Application Administration Console. The
console shows common items and items for the applications that you have
installed. The configuration forms are available only to BMC Remedy AR System
administrators and application administrators.
NOTE
Always open forms from this console. If you open the forms directly from the
object list in BMC Remedy User, you might not see all the information you need,
or you might experience unexpected results.
The Application Administration Console has two tabs: Standard Configuration

and Custom Configuration. The Standard Configuration tab (Figure 2-1) lists
seven steps that walk you through the process of configuring your organization’s
information.
NOTE
If you installed and configured a BMC Remedy IT Service Management Suite
application before installing BMC Service Request Management, the standard
configuration steps might have already been done.
Figure 2-1: Application Administration Console—Standard Configuration tab

The Custom Configuration tab provides access to configuration forms. Use the
forms accessed from this tab to go beyond the standard configuration.
Figure 2-2: Application Administration Console—Custom Configuration tab
For more information about configuration, see the BMC Remedy IT Service
Management Configuration Guide.
Configuration prerequisites
You can configure the application to contain custom entries about the various
people, groups, skills, responsibilities, and geographic locations associated with
your organization.
Before you begin configuring the application, verify that the following
configuration prerequisites are met:
You must have an BMC Remedy AR System write license (either fixed or
floating) and an application license to create or modify entries in the Application
Administration Console.
You must have a basic knowledge of BMC Remedy AR System administration
tasks.
Defining the application administrator
Defining the application administrator

The application is installed with a default application administrator (appadmin),
which you can use to start configuring the application and define the application
administrator.
The following procedure describes the minimum number of entries that you need
to make to enable the administrator to configure the application. You should add
support staff information to the application administrator entry, as described in
“Creating support staff members” on page 50.
To define a BMC Service Request Management administrator

1 Log into the BMC Remedy AR System server as the appadmin user.
2 On the Standard Configuration tab of the Application Administration Console,
select the company for which to define the application administrator.
3 Click the Create link next to People.
NOTE
Always configure people by opening the People form from the Application
Administration Console. Information that you add or modify on the People form
is automatically updated to the BMC Remedy AR System User form, but
information updated on the User form is not updated to the People form.
4 In the People form, enter information in the required fields.

5 Enter the administrator’s email address.
The default notification method is email.
6 For the application administrator (and all support staff), select Yes in the Support
Staff field.
The Support Groups tab appears. For the application administrator and all support
staff, you must complete the Login/Access Details tab and the Support Groups
tab.
7 Give the person the appropriate administrator permissions.
a On the Login/Access Details tab, enter the Login ID and the Password.
b Click Update Permission Groups.
c In the Permission Group field on the Permission Group dialog box, select a
permission group to add, and click Add/Modify.
Request > SRM Administrator
Foundation > ASE-Administrator
Task > Task Administrator (optional, so that the SRM administrator can
access the Task Management System configuration forms)
For more information about permissions, see “User roles and permission
groups” on page 41.

d If required, select a license type of Fixed or Floating.

e Click Add/Modify for each permission group.
f When you finish adding permission groups, click Close.
8 If you use the Company field to restrict access to specific companies, complete the
following steps to give the application administrator access to data in the
applications by assigning the administrator to specific companies. Otherwise,
select Yes in the Unrestricted Access field (the default) on the Login/Access Details
tab of the People form.
To select a specific company:
a Click Update Access Restrictions.
b In the Access Restriction field of the Access Restrictions dialog box, select a
company for which to add access to the person.
c Click Add/Modify and Close.
9 If the administrator will also be a service request coordinator, business manager,
work order manager or assignee, or fulfillment provider, follow these steps to
relate the person to at least one support group:
a Click the Support Groups tab.
b Click Update Support Groups and Roles.
c In the Add Support Group Relationship area of the Update Support Group
Memberships and Roles form, select the Company, Support Organization,
Support Group, and Relationship Role.
NOTE
The relationship roles are Member and Associate Member. These values are
informational only. Member means that the person belongs to the support group.
Associate Member means that the person has access to modify requests assigned to
that support group.
d Click Add.
A support person can belong to more than one support group. To select the
primary support group, select the support group, and click Set to Default.
To change the relationship role, click Make Associate Member or Make Member.
10 Click the Functional Role Update tab.
You can use this tab to assign functional roles to people in support groups.
Functional roles extend access granted by permissions groups, but only for specific
support groups that are used in the application. For example, someone might be a
member of two support groups, but is a Request Approver for only one.
User roles and permission groups
11 To add a functional role, complete the following steps:

a Select the Company, Support Organization, and Support Group Name.
Selections in lists for the Company, Support Organization, and Support Group
Name fields on this tab appear only if support groups have been related to the
person on the Support Group Update tab.
b Select a functional role (such as Request > Request Approver) and click Add.
12 Click Close, and click Add in the People form.
13 Confirm the password.

The following table lists user roles, permission groups, and related information.
The responsibilities of these roles can vary from organization to organization, and
in some organizations, one person might fulfill several roles. Permission groups
are used to grant users access to different consoles and modules in the application.
User role Console Permission groups Support staff Responsibilities

member?
User Request Entry No permissions No Submits service requests
are required Monitors the status of their
requests
Makes requests on behalf of
other users (entitlement rule
and application license are
required)
See the BMC Service Request
Management User’s Guide.
Business manager Business Manager Business Manager Yes Approves requests as the
Console requester’s manager, which is
Approval Console specified in Manager’s Name
field on the More Details tab of
Overview Console
the People form.
Reviews the consolidated or
individual status of service
requests in the organization
See the BMC Service Request


member?
BMC Service Application SRM No Installs and configures the
Request Administration Administrator application
Management Console ASE Configures the connection to
application Overview Console Administrator the fulfillment application
administrator (optional) Integrates third-party
Task applications (optional)
Administrator Performs system-level
(optional) troubleshooting
See:
BMC Service Request
Management Installation Guide
Integrating BMC Service
Request Management with
Custom AR System Applications
white paper
Service catalog Service Catalog Request Catalog Optional Defines AOTs and PDTs.
manager Manager Console Manager Creates SRDs (requestable
Service Request Entitlement services), including SLAs, cost
Designer Administrator and price, system-level
Overview Console (optional) common offerings, and
SLM Config mappings to the process flow
(optional) from the business.
Manages the process as SRDs
move from draft to approval,
and then to deployment.
Defines entitlement to SRDs
(optional)
See “Creating service request
definitions” on page 109.
Business analyst Service Request Business Analyst No Uses the Service Request
Designer Entitlement Designer to create requestable
Overview Console Administrator services
(optional) Defines entitlement to SRDs
(optional)

member?
Service request Service Request Service Request Yes Monitors requests in which
coordinator Coordinator User the service request coordinator
Console is defined as the coordinator,
Request Entry making sure that the requests
console are executed on time
Approval Console Reviews the approval status of
requests
Overview Console
Open the back-end Service
Requests form to view the
status of service requests and
troubleshoot issues with
request fulfillment
Creates service requests for
other users (entitlement rules
are required)
With additional configuration,
can approve requests
Fulfillment Work Order Service Request Yes Works as the change assignee,
provider Console User incident assignee, or the work
Overview Console Change User order assignee, to make sure
(optional) that requests are fulfilled
properly
Incident User
(optional) Completes the assignments
required to fulfill requests
Work Order
Master (optional) See the BMC Service Request
Work order Work Order Work Order Yes In large companies, plans and
manager Console Master oversees the work order
Overview Console Work Order process
Config (optional) In small companies,
additionally functions as work
order assignee who performs
the tasks for work orders
Tracks work orders
See “Using the Work Order
Management application” on
page 247.
Work order Work Order Work Order Yes Implements assigned work
assignee Console Master orders
Overview Console Creates work order tasks
See “Using the Work Order
Management application” on
page 247.

User access to application consoles and

functions
The following table describes the consoles and functions that various users and
roles can use to access in the application.
Types of service BMC Service Request Management roles

request users
Unknown Registered Service Business Entitlement Request SRM Business
user user (in Request Manager Administrator Catalog Administrator Analyst
the People User Manager
form)
Consoles
Request Entry Yes Yes Yes Yes Yes Yes Yes Yes
console
Business No No No Yes No No No No
Manager
Console
Service No No Yes No No No No No
Request
Coordinator
Console
Service Catalog No No No No No Yes No No
Manager
Console
Service No No No No No Yes No Yes
Request
Designer
Application No No No No Yesa No Yes No
Administration
Console
Import Export No No No No No Yes No No
Console
Functions
Create, modify, Yes Yes Yes Yes Yes Yes Yes Yes
close, reopen,
or cancel
service
requests. View
broadcasts and
access surveys.
Create, modify, No No Yes Yes No No No No
or cancel
service
requests for
others.
User access to application consoles and functions
Types of service BMC Service Request Management roles

request users
Unknown Registered Service Business Entitlement Request SRM Business
user user (in Request Manager Administrator Catalog Administrator Analyst
the People User Manager
form)
Approve No Yes Yes Yes Yes Yes Yes Yes
service
requests.
Define No No No No Yes Yesb Yes No
entitlement
rules.
Create reports. No No Yes Yes No Yes No No
Access No No No No No No Yes No
application
administration
and
configuration.
Create and No No No No No Yes No No
modify AOTs.
modify PDTs.
modify SRDs
using the
Service
Request
Definition
form.
Create SRDs No No No No No Yes No Yes
using the
Service
Request
Designer.
Perform No No Yes No No No Yes No
system-level
trouble-
shooting.
a.
Access to entitlement configuration only.
b.
Create or modify entitlement rules through the Entitlement tab on the Service Request Definition
form.

Application functional roles

Application functional roles are used for notifications and to extend access granted
by permission groups. Only support staff members can be given functional roles.
NOTE
For more information about notifications, see “Configuring mid tier and multi-
tenancy settings” on page 62.
The following table lists the functional roles defined in the application and their
purposes.
Functional role Purpose
Request Approver Identifies support people in support groups as approvers for requests. If a support
group has been defined to approve service requests, this role must be granted to at
least one individual in the group so he or she can approve service requests.
SRD Approver Identifies support people in support groups as approvers for SRDs. If a support
group has been defined to approve SRDs, this role must be granted to at least one
individual in the group so he or she can approve SRDs.
Work Order Assignee Grants full access to work orders that are assigned to the assignee’s group.
Work Order Manager Grants full access to work orders that are assigned to the manager’s group. This
role can be applied to either the Assigned or Manager Group in the work order
form.
Performing a standard configuration

The Standard Configuration tab of the Application Administration Console walks
you through the standard process of configuring your organization’s information.
If you are performing custom configuration, start by performing standard
configuration on this tab. If you have administrator permissions, you can perform
all of the configuration on this tab; if your account is missing a required permission
(such as the Config Categorization Admin permission to configure operational
categories), you are prompted to determine whether to grant yourself the required
permission.
After you finish, you can:
View and modify standard configuration data, as described in “Managing
standard configuration data” on page 56.
Continue to perform custom configuration as described in “Working with the
Custom Configuration tab” in the BMC Remedy IT Service Management
Configuration Guide.
To perform standard configuration by using the Standard Configuration tab

1 Open the Application Administration Console.
See “Opening application consoles” on page 36.
On the Standard Configuration tab, check marks appear next to each step for
which standard configuration has been performed.
Figure 2-3: Standard Configuration tab
2 Continue to configure the selected company, or create a company.

To create a company, follow the procedure described in “Creating a company” on
page 48.
TIP
If you create a company, but do not complete standard configuration, you can
return to this procedure. Select the company you are configuring, and continue.
3 Click Next Step.
NOTE
Complete steps in sequence. If you skip a step, you might not be able to complete
a subsequent step. For example, you cannot create a people record for support staff
unless a support group has been created.

4 To create additional configuration records for a step, click the appropriate Create
link.
For example, to create additional departments for the company, click the Create
link next to Organization.
5 To modify or further customize a configuration record, click the appropriate View
link.
Creating a company
The first step in standard configuration is to configure a company. Everything else
that you configure belongs to this company. You can configure multiple
companies if your company is made up of smaller companies that are separate
entities.
To create a company
1 On the Standard tab of the Application Administration Console, click Click here to
create and configure a new company.
2 From the Company dialog box, enter the company name.
3 Select or enter a Company Type:
Customer—This company is an external company for which you provide
services.
Operating Company—This company is an internal company or business unit
for which you provide services.
Additional standard company types (Generic Contact, Manufacturer, Supplier,
and Vendor) are available for custom configuration using the Company form.
4 Click Add.
Creating organizations
Organization structure is defined as Company > Organization > Department,
which represents how a company is represented from a business perspective.
To create the company and organizations

1 From the Standard Configuration tab of the Application Administration Console,
click the Create link next to Organization.
2 From the Organization form, enter or select the organization.
Enter the name of the organization to create it. After you add the first department
to the organization, you can select the organization when you add another
department.
3 Enter the department, and click Add.
Creating locations
The Location structure is defined as Company > Region > Site Group and Site,
which represents locations of sites. The location structure can be used in group
assignment and other mapping functions, such as approvals. Sites represent a
physical location (such as a building) for a company.
To create locations
select the company for which to create a location.
2 Click the Create link next to Location.
3 (optional) Enter or select information in the Region and Site Group fields of the
Location form.
You can use the Region and Site Group fields to create a location structure with
two or three levels.
Region—Geographic areas can be divided into regions. A company can have
several regions, depending on how many sites it has and where the sites are
located. Examples of company regions are Northwest, Atlantic, and Pacific.
Creating regions under a company is done only for reporting.
Enter the name of a region to create it. After you add the first site group or site
to the region, you can select the region when you add another site or site group.
Site Group—Geographic areas can be subdivided into site groups, which are
collections of individual locations. A company can have any number of site
groups, depending on how many locations it has and where the locations are.
An example of a company site group is ABC Europe Group.
Enter the name of the site group to create it. After you add the first site to the site
group, you can select the site group when you add another site.
4 Enter the site designation in the Site field.
5 Enter or select the site address information.
6 Click Add.
Creating support groups

The Support Groups structure is defined as Company > Support Organization >
Support Group, which represents how a company is structured from a support
perspective. Support groups are typically used to assign work.
NOTE
Support groups are used in configuring business hours and holidays, which are
used in calculating the expected completion date of requests and in the Work
Order application.

To create support groups

select the company for which to create a support group.
2 Click the Create link next to Support Group.
3 From the Support Group form, enter or select information in the Support
Organization and Support Group Name fields.
Enter the name of the support organization to create it. After you add the first
support group to the organization, you can select the organization when you add
another support group.
4 Select the support group role.
The Support Group Role field describes the role that the support group has in the
organization. For example, the support group named Internal Support might
provide the Help Desk function, while another support group provides Tier 2
support.
5 Click Add.
Creating people information

You can create records for both support and non-support and staff. Non-support
staff members include anyone who is not a member of the IT or business services
organizations, or does not create or modify records in the application.
You must set up a login ID and password for anyone with access to the application,
aside from guest access. People information also includes each person’s company,
organization, business and home addresses, desk location, support groups, and
selected additional information.
After adding users, log into the application with the new users to make sure they
can access the IT Home Page. Then verify that the users can view the correct
application consoles. For example, a user with Request Catalog Manager
permissions should be able to see only the Request Entry console and the Service
Request Coordinator Console.
Creating support staff members

Depending on how your organization assigns roles, you must add support staff
records for the following people:
Service Request Coordinator (requires the Service Request User permission)
Business Manager
Work Order Master
Work Order Assignee
To create support staff members

select the appropriate company.
2 To determine whether this person has already been added as a user, complete the
following steps:
a Click the View link next to People.
b From the People form, search for a user to add as a member of the support staff
(for example, the user who you want to be a fulfillment provider).
c Select the person to define as a member of the support staff.
Information for the selected user appears in the People form.
3 If this person has not yet been added as a user, Click the Create link next to People.
4 From the People form, enter the person’s first name and last name.
5 Select the client type.
6 (optional) Select a contact type, such as Hotline or Tech Support.
7 Set Support Staff to Yes.
8 To enter the phone number, click in the Phone Number field and press ENTER.
Select a Country Code for a phone number from the list or enter one manually.
If you omit the phone number, it is set as unknown.
9 (optional) Enter the email address. An email address is required to receive email
notifications.
10 (optional) If this person is a home-based employee, click Edit Home Address to
enter the home address and click the icon to the right of the Edit Home Address
field to enter the phone number.
11 In the Organization Information area, select the company and, optionally, select
the organization and department.
12 In the Location Information area, select the site.
13 To enable this person to log into the system, perform the following steps on the
Login/Access Details tab:
a Enter a login ID and password.
People who have access to the People form can change their password.
b Under License Type, select Fixed or Floating in the License Type field.
c If you have the BMC Remedy AR System full text search option, select the
appropriate Full Text License Type.
d In the Application Permissions area, click Update Permission Groups.
The Permission Group dialog box appears.

e In the Permission Group field, select each appropriate permission group to add,
such as Business manager, Service Request User, or Work Order Master.
f Click Add/Modify for each permission group.
14 If you use the Company field to restrict access to specific companies, click Update
Access Restrictions to give the support staff member access to data of the selected
companies. Otherwise, select Yes in the Unrestricted Access field on the Login/
Access Details tab.
15 From the Support Groups tab, click Update Support Groups and Roles and add the
support staff member to one or more support groups.
16 Add any remaining information needed to create the support person, and click
Save.
17 Confirm the password.
The person’s information is stored in the BMC Remedy AR System User form and
in the People form.
Creating non-support staff people

You can create non-support staff records for employees, customers, and vendors.
Support staff can use these records to complete forms, such as to indicate that a
specific customer called the help desk to report an incident. If non-support staff
have a login ID and password, they can record their own requests on the Request
Entry console.
NOTE
For information about guest users, see “Allowing unknown users access to the
Request Entry console” on page 60.
To create non-support staff records

select the appropriate company.
2 Click the Create link next to People.
3 From the People form, enter the person’s first name and last name.
4 Select the client type.
Client type Information required

Office-Based Select or enter a site in the Site field.
Employee
Field-Based
Employee
Contractor
Customer Site information is optional.
Prospect
Vendor
Home-Based You must enter home information in addition to the site
Employee information.
5 (optional) Select a contact type, such as Finance or Sales.

6 Set Support Staff to No.
7 To enter the phone number, click in the Phone Number field and press ENTER.
Select a Country Code for a phone number from the list or enter one manually.
If you omit the phone number, it is set as unknown.
8 (optional) Enter the email address. An email address is required to receive email
notifications.
9 (optional) If this person is a home-based employee, click Edit Home Address to
enter the home address and click the icon to the right of the Edit Home Address
field to enter the phone number.
10 In the Organization Information area, select the company and, optionally, select
the organization and department.
11 In the Location Information area, select the site.
You must select a site for employees, but it is optional for customers and vendors.
12 To enable this person to log into the system, perform the following steps on the
Login/Access Details tab:
a Enter a login ID and password.
People who have access to the People form can change their password.
b Under License Type, select Fixed, Floating, or Read in the License Type field.
NOTE
If you select a Read license for any user, you must set the Submitter Mode option
to Locked in the Licenses tab of the AR System Administration: Server Information
form. See the BMC Remedy Action Request System Configuration Guide.
c If you have the BMC Remedy AR System full text search option, select the
appropriate Full Text License Type.
13 Click Add.

Creating product categories (optional)

You can create product categories for use in various forms. Products can be any
items used by an organization. Products are typically used to classify a
configuration item, an incident, a change request, or a work order.
NOTE
In BMC Service Request Management, product categorization is used only by the
Work Order Management application.
The Product Categorization structure is defined as Tier 1 > Tier 2 > Tier 3 > Product
Name and Manufacturer > Model Version, which is used to categorize different
products or configuration items in the Atrium Service Catalog.
Before creating or modifying product information, it is important to understand
product relationships:
When creating product category information, you must complete all three tiers.
The product name or manufacturer field is optional, but both are required if
either is specified. One tier can be sufficient, depending on the item being
created. If you create a product for which only one tier is required, you can set
the other two tiers to None.
Each product category can have more than one product model/version.
Products can be associated with one or more companies.
Each product category must be unique. You might find it helpful to view existing
categories before creating categories. For more information about viewing
categories, see “Managing standard configuration data” on page 56.
To create product categories

select the company for which to create product categories.
2 Click the Create link next to Product Category.
3 (optional) From The Product Category form, select the Product Type.
4 Select the configuration item (CI) type.
The CI Type field specifies the type of CI for which you are creating this product
category.
5 Select or enter the Product Categorization Tiers.
TIP
If you are creating a product that requires only one tier, enter None for the other
two tiers.
After you create a product category with a particular tier 1 and tier 2, you can select
those tiers when creating additional product categories. For example, if you create
a product category for Hardware > Server > Linux®, you might first enter all three
categories, but when you create a product category for Hardware > Server >
Windows, you can select both Hardware and Server.
6 (optional) Enter or select a product name.
If you specify a product name, you must specify a manufacturer. Select a
manufacturer, or click new to add a new manufacturer.
7 If you specify a product name, you must specify a manufacturer. Select a
manufacturer, or click New to add a manufacturer.
If you click New, the New Manufacturer dialog box appears. Enter a company,
select Enabled for the status, and click Save.
8 In the Product Category dialog box, select Enabled for the status.
NOTE
To temporarily prevent the category from being selected from the application, set
the status to Proposed.
9 In the Origin field, leave the default value of Custom.

10 In the Suite Definition field, select Yes if this product is part of a suite of related
products; otherwise, select No.
11 Select whether the category is available for the current company, or whether it is
available for all companies.
12 Click Add.
The operational category is automatically related to the selected company. and is
available on other forms.
Creating operational categories

You can create operational categories of services for use in various forms.
Operational categories list all the operational services that a typical help desk or
business services organization provides, such as add user account and change
server password. It can also contain items that represent symptoms of incidents or
problems, such as application failure and network failure.
NOTE
In BMC Service Request Management, operational categorization is used only by
the Work Order application.
Each operational category must be unique. You might find it helpful to view
existing categories before creating categories. For more information about viewing
categories, see “Managing standard configuration data” on page 56.

To create operational categories

select the company for which to create operational categories.
2 Click the Create link next to Operational Category.
3 From the Operational Catalog form, select or enter an operational category.
After you create an operational category with a particular tier 1 and tier 2, you can
select those tiers when creating additional operational categories. For example, if
you create an operational category for Add > User > Account, you might first enter
all three categories, but when you create an operational category for Add > User >
Web Page, you can select both Add and User.
4 Select Enabled for the status.
NOTE
You can set the status to Proposed to temporarily prevent the category from being
selected from an application.
5 Select whether the category is available for the company that you are configuring,
or whether it is available for all companies.
6 Click Add.
When you save the operational category, it is automatically related to the Global
company. This makes the operational category available on other forms, for all
operating and customer companies.
Managing standard configuration data

After you perform the standard configuration, you can view the data. When you
view the data, a form appears in which you can perform additional custom
configuration. For example, if you view support groups, you can use the Support
Group form to modify the data already entered or add additional information,
such as the business hours for a support group.
To view or modify standard configuration data

select the company for which to view or modify configuration data.
2 Click the View link next to the standard configuration data to view or modify.
The corresponding form appears with the search results that show all the records
for the selected company. If appropriate, records applicable to all companies are
also listed. For example, if you click the View link next to Support Group, the
Support Group form appears, showing all matching support groups.
The top part of the form shows the search results, and the bottom half shows the
selected record.
Managing standard configuration data
3 Select the appropriate record.

You can view the data or make changes, as appropriate. For additional
information, see the following table.
Location of view link Form Additional information

Configuration for Company form See “Creating a company” on page 48.
Company
Organization People Organization You can make updates on this form, such as selecting a different
Update form department or typing the new name of an organization.
You can also make changes to the company’s organizations from
the Organizations tab of the Company form. See “Creating
organizations” on page 48.
Location Site Company You can view the locations for a company from this form, but you
Relationship form cannot make changes.
To modify a site, click the Edit Site button from this form to open
the Site form. See “Creating locations” on page 49.
Support Group Support Group form See “Creating support groups” on page 49.
People People form See “Creating people information” on page 50.
Product Category Product Company From this form, you can only enable or disable the product
Relationship form category for the company or applications.
To modify the product category, click the Edit Product Category
button from this form to open the Product Catalog form. See
“Creating product categories (optional)” on page 54.
Operational Operational From this form, you can only enable and disable the operational
Category Company category for the company or applications.
Relationship form To modify the operational category, click the Edit Operational
Category button from the Product Category Relationship form to
open the BMC Atrium Operational Catalog form. See “Creating
operational categories” on page 55.
Assignment Routing Configure See “Configuring assignments” on page 299.
Assignment form
4 Click Save.

Creating on-behalf-of definition rules

The application administrator can create on-behalf-of definition rules to specify
that:
A member of a support group can enter a service request on-behalf-of another
individual in a company, an individual in a specified company, or an individual
in a specified group. The -Global- company can be used to allow entering a
service request for anyone.
An individual can enter a service request on-behalf-of another individual,
another individual in a specific company, or an individual in a specified group.
Anyone can enter a service request on-behalf-of anyone else by using a company
to company rule with -Global- for the requester and -Global- for the requester to
act on-behalf-of.
An individual with a BMC Remedy AR System Read license can act on-behalf-
of another individual, group, or company.
NOTE
Users who are allowed to submit requests on-behalf-of another user must be
assigned a fixed or floating license. Otherwise, they cannot manage requests after
they have been submitted on-behalf-of another user. In addition, they cannot
manage a cart for another user.
You can use this feature even if you choose to disable entitlement management.
To create on-behalf-of definition rules

1 From the Application Administration Console, click the Custom Configuration
tab.
2 From the Application Settings list, choose Service Request Management >
Entitlement > On Behalf Of Management, and click Open.
3 From the On Behalf Of Definition Rules form, click the Create button.
4 From the On Behalf Of Definition form, enter a unique Rule Name.
5 Select a company.
6 Select a status.
Creating on-behalf-of definition rules
7 Define the Requester by selecting a Requester Type.
If you select this Follow these steps

Requester Type
User 1 Click Select User.
2 In the People Search form, enter criteria to find a particular person
from the People form, and click Search.
3 Choose a person from the results list, and click Select.
4 The Login ID of the person appears.
Note: You can select any user from any of the companies you have access
to. If you are not permitted to act on-behalf-of the selected user, you
receive a warning message.
Company Select information from the remaining fields (for example,
Organization, Department, and so on).
Group Choose a group name for the company (for example, Calbro Services >
Service Desk).
When selecting a group for the Requester Type, you can only select a
group that you have access to.
Note: To enter a request on-behalf-of a group you are not a member of,
you must select Yes in the Unrestricted Access field (the default) on
the Login/Access Details tab for your record on the People form
8 Define a user or company that the user is acting on-behalf-of.
If you select this Follow these steps

Requested For
Type
User 1 In the People Search form, enter criteria to find a particular person
from the People form, and click Search.
2 Choose a person from the results list, and click Select.
3 The Login ID of the person appears.
Note: If users do not have at least General Access permissions, they
cannot cancel or modify a Draft request that was submitted on their
behalf. To allow them the full capability of managing requests that
have been submitted on their behalf, the BMC Remedy AR System
Administrator must assign the General Access permission to the
appropriate records in the User form.
Company Select information from the remaining fields (for example,
Organization, Department, and so on).
Group Choose a group name for the company.
When selecting a group for the Requester Type, you can only select a
group that you have access to.
Note: To enable the user to receive a request on-behalf-of a group of
which the user is not a member, select Yes in the Unrestricted Access
field (the default) on the Login/Access Details tab for that user’s
record on the People form.
9 Click Save.

How on-behalf-of functionality works

When a user enters a request on behalf of another user, the following process takes
place:
The Requested By and Contact Information sections on the Service Request and
Work Order forms provide the details about the person who submitted the
service request or work order. (The organization and department of the
Requested By person are based on the Requested By company.)
The Requested For and Customer Information sections on the Service Request
and Work Order forms provide the details about the person who the service
request or work order was submitted on behalf of. (The organization and
department of the Requested For person are based on the Requested For
company.) If a user submits a service request on behalf of himself, the Requested
For information equals to that of the Requested By.
The Location Information section lists the location company, region, site group,
and site of the service request or work order. Region, site group and site are
based on the location company. The location information is not necessarily the
same as the Requested For person’s location on the People form. (Many
applications allow the location information to be modified manually.)
When the backend request is submitted, the location information from the
backend is passed to the location information on service request. If the
information is not provided from the backend, the system sets the location
information on the service request to that of the Requested For person from the
the People form. The same happens with the work order.
Allowing unknown users access to the Request

Entry console
The Request Management Application Settings form is used if your organization
allows unknown users to access the Request Entry console to submit service
requests.
Users are considered to be unknown users if they have not been given login
information, even if they have been defined in the People form.
If guest users must be able to access to navigational categories and SRDs, create
them for global companies.
To allow unknown users access to the Request Entry console

1 On the System Settings form, set the tenancy mode to Single-Tenancy and add a
company name.
To open the System Settings form, open the Application Administration Console,
and click the Custom Configuration tab. Then, choose Foundation > Advanced
Options > System Configuration Settings > System Settings.
Configuring business hours and holidays
2 On the Application Settings form, set the Allow Unknown Users option to Yes and
add login information.
To open the Application Settings form, open the Application Administration
Console, and click the Custom Configuration tab. Then, choose Service Request
Management > Advanced > Application Settings.
3 Create a default People record with a valid BMC Remedy AR System login to be
used for unknown users.
4 On the Configuration tab of AR System Administration: Server Information form,
select the Allow Guest User option.
For information about setting the BMC Remedy AR System options, see the BMC
Remedy Action Request System Configuration Guide.
NOTE
For unknown users who have a BMC Remedy AR System login and no People
record, some organizations might not want guest users to access their systems. In
this situation, do not enable the Allow Guest User option.
Configuring business hours and holidays

You can view and modify the hours of operation for each support group on the
Business Hours and Holidays tab of the Support Group form. Support group
business hours and holidays are used in calculating the expected completion date
of requests and in the Work Order Management application.
To add business hours and holidays

tab.
2 From the Application Settings list, choose Foundation > Organizational Structures
> Support Groups, and click Open.
3 In the Support Group form, search for the support group.
4 Select the support group, and click the Business Hours and Holidays tab.
5 In the Business Hours area, click Update.
6 On the Define Business Hours form, click the Server Time Zone button.
NOTE
To set the server time zone, you must first specify the time zone. To set the time
zone, choose Foundation > Organizational Structures > Time zone from the
Custom Configuration tab of the Application Administration Console.
7 Enter the start and end times or click the 7 X 24 or Default button, and click Save.
The business hours you specified appear on the Business Hours and Holidays tab
of the Support Group form.

8 To add business holidays, click the Update button in the Business Holidays section
of the form.
9 On the Business Holidays Definition form, click the Server Time Zone button to
select the time zone for the BMC Remedy AR System server.
10 In the Holiday field, enter a holiday date.
11 Click Add, and enter the remaining holidays.
Configuring mid tier and multi-tenancy

settings
The SRM Application Settings form is used to configure the mid tier path. This
path must be set correctly, so that you can view the data visualization fields (DVF)
in the application.
In addition, this form is used to configure multi-tenancy settings for the Request
Entry console. Use this form to determine if your organization supports multi-
tenancy or usage by a single default company.
You can also use this form to determine if your organization allows unknown
users to access the Request Entry console to submit service requests, or whether
your organization will use the Request Entry console as the front-end to the
application. (For information, see “Allowing unknown users access to the Request
Entry console” on page 60.)
NOTE
Multi-tenancy is how access control to data is enforced in the application. For
example, when you create an SRD, you either specify which company it belongs to
or you designate it as a “global” SRD. As a result, if the SRD is attached to Calbro
Services, for example, only users who belong to Calbro Services can access it. But
if the SRD is global, you are allowing any user to see it, regardless of which
company they belong to.
To configure mid tier and multi-tenancy settings

tab.
Advanced > Application Settings, and click Open.
3 If Single-Tenancy appears in the Tenancy Mode field on the SRM Application
Settings form, specify whether to allow guest users to access the Request Entry
console, as follows:
a In the Allow Unknown Users field, select Yes or No.
b If you select Yes, specify the proxy login information.
Configuring the mid tier to view DVF fields
NOTE
If Multi-Tenancy appears in the Tenancy Mode field, your organization uses the
Company field for access control. You cannot allow guest users to access the
system; only users registered in the People form are allowed access. For
information, see “Allowing unknown users access to the Request Entry console”
on page 60.
4 In the Mid Tier Path field, enter the default path of the BMC Remedy Mid Tier
using the fully-qualified domain name format, for example:
http://255.255.255.255:8080/arsys
http://ccm-five1-vm2.labs.acme.com/arsys
http://chardonnay.labs.acme.com:8080/arsys
5 Click Save.
Configuring the mid tier to view DVF fields

To view the data visualization fields (DVF) in BMC Service Request Management,
you must properly configure the BMC Remedy Mid Tier.
NOTE
You must perform this task even if you only use BMC Remedy User to access the
application.
To configure the mid tier to view DVF fields

1 From the IT Home Page, open the AR System Administration Console.
2 Choose System > General > Server Information.
3 In the Server Information window, click the Advanced tab.
4 In the Default Web Path field, enter the mid tier URL.
The format is http://webServer:port/contextPath. The default value for
contextPath is arsys.
Specify port only if you are not using the default port number of 80. Make sure
you use the fully-qualified domain name.
NOTE
For the application to function correctly, the URL used to access the Request Entry
console must contain the current BMC Remedy AR System server for the mid tier,
which is the value in the $SERVER$ variable.
5 Click OK.
6 Open the BMC Remedy Mid Tier Configuration Tool:
http://midTierHost/arsys/shared/config/config.jsp
7 Click General Settings.

8 Enter the AR Server name in the Data Visualization Module Server field, matching
the server you specified in step 4 on page 63.
You should configure the Data Visualization Module on the mid tier to use only
one server.
9 Click AR Server Settings.
10 Verify that the value in the SERVER NAME column matches the BMC Remedy AR
System server name you specified in step 4.
11 Log into the BMC Remedy AR System server with your browser, and open the IT
Home Page.
12 In the left navigation pane, click the Request Entry link under Service Request
Management.
13 If you correctly configured the mid tier, the Request Entry console appears.
Chapter
3 Configuring navigational
categories
This section describes how to configure navigational categories.
NOTE
You must have the SRM Administrator permission to navigational categories.

About defining navigational categories (page 66)
Defining global navigational categories (page 68)
Defining company navigational categories (page 70)
Sorting navigational categories (page 71)

About defining navigational categories

You must set up navigational categories so that you can choose one when an SRD
is created. These navigational categories appear in the Request Entry console when
the user clicks Browse Catalog.
When creating navigational categories, as a best practice, divide the service into
two parts and make two lists:
Items you support—for example, Hardware, Software, Networks, and so on.
Services you provide—for example, Repaired, Replaced, Trained, and so on.
Create a spreadsheet with the items you support on the left side and the services
you provide on the top row. Each spreadsheet cell represents a category and
service pair (for example, Hardware/Repaired). Determine which pairs apply to
your organization, and you can map your old tree to this new structure.
You define the categories in the Category Management form. This form is used as
a repository to store the categorizations that differentiate the catalog offerings,
including graphics. You can create generic categories that globally apply to all
organizations (for example, Hardware/Computers/Dell) or categories unique to
specific companies.
NOTE
Navigational categories do not appear in the Request Entry console until they are
associated with an SRD. Some SRD categories are pre-configured by default with
their own images. You can relate a different image with these categories. In
addition, when you configure your own navigational categories for your
organization, you can assign customized images to them, based on your
organization. (For more information, see “Configuring service request image
definitions” on page 174.)
After you define the navigational categories, their values appear in the following
areas:
Service Request Definition form
Defined Locales form (click the Other Locales button on the Service Request
Definition form)
SRD Qualification for Entitlement form
Approval Mappings
You can define categories for one company, which makes the appropriate
categories visible only for that company. Using the Category Management form,
you can create three levels of categorizations for a specific company (for example,
Installation > Desktop > Windows, or Change > Application > Password).
The company and categories enforce the uniqueness of the categorization, which
means that only one unique combination of categories is allowed for each
company and each locale.
About defining navigational categories
When defining navigational categories, the best practice is to follow this sequence
of steps:
Step 1 “Defining global navigational categories” on page 68
Step 2 “Defining company navigational categories” on page 70
Step 3 “Sorting navigational categories” on page 71
Follow this sequence because you move company navigational categories up and
down the navigation tree relative to the global categories. After you specify the
sequence of the global categories, they are fixed and do not change when you start
working on your company categories. After you establish the global categories,
you move the company categories around them, above or below a global category.
TIP
Define only a manageable number of SRDs and navigational categories. Increasing
the number of navigational categories to users can slow the performance of search
operations in the Request Entry console.
The system prevents you from creating duplicate Category 1 records. You can,
however, create Category 2 and Category 3 records that have the same name. For
example, you can create two Category 3 records called Password Reset because
the two different contexts in the Request Entry console determine its particular
use.
Business Systems (Global Category 1)
iTime (Category 2)
Password Reset (Category 3)
Network (Calbro Category 1)

NT Authentication (Category 2)
Password Reset (Category 3)
As a result, users should not be confused by seeing Password Reset in two
different locations in the Request Entry console.
To avoid confusion in a multi-tenancy environment, you should create your most
general categories as global. When you have finished the overall general structure
of your Category 1, 2, and 3 records, you can create more particular categories for
your company.
NOTE
If guest users must be able to access navigational categories, create the categories
for global companies.

Defining global navigational categories

You can create up to three levels of global navigational categories that appear in
the Request Entry console when a user clicks Browse Catalog.
To define global navigational categories

tab.
Navigational Categories > Category Management, and click Open.
When you open the Category Management form, the company that appears is
Global if the Multi-Tenancy is set for the Service Request Management application
settings. Otherwise, the Select Company field defaults to the Single-Tenancy
company you specified. For more information, see “Configuring mid tier and
multi-tenancy settings” on page 62.
All administrators have access to Global categories. If you have Unrestricted
access, you can see all companies on your BMC Remedy AR System server in the
Select Company list. Otherwise, you can see only Global and the company to
which you have access.
3 To create a global Category 1 record, follow these steps:
a Click Add.
New Category appears in the Categories tree.
b Select New Category from the tree.
c Enter a Category Name (for example, Hardware).
This category name represents a Category 1 record shown in the Request Entry
console. The category name is shown in the Navigational Categories section of
the Service Request Definition form.
If you want to enter the greater than (>) or less than (<) sign in the Category
Name field, use encoded text (&gt for >, and &lt for <); otherwise, browsers will
interpret the greater than and less than signs as valid HTML markup if the
category name is included in a URL.
d (optional) Add a brief description of the category.
e (optional) Click Change Image to select an image.
For more information about adding image definitions or modifying associated
images, see “Configuring service request image definitions” on page 174 and
“Managing SRD images” on page 175.
f Select the status of the navigation category (for example, Active).
The status determines if the category is available on other forms (for example,
the Request Entry console or the SRD Qualification for Entitlement).
g Click Apply to add the category details to the tree.
Defining global navigational categories
4 To add additional Category 1 records, select Categories at the top of the tree, and
click Add.
Repeat step b to step g, until you finish adding Category 1 records.
5 To create a Category 2 record in the tree:
a Select the Category 1 record, and click Add.
b Enter a category name (for example, Printer) and a description.
In the Request Entry console, the Category 2 value appears under Browse Sub-
Categories.
NOTE
You cannot select images for Category 2 records.

a Select the Category 2 record.
b Click Add.
c Enter a category name (for example, Xerox Laser Printer) and a description.
Category 3 values appear when a user clicks a Browse Sub-Categories link for a
service category in the Request Entry console. You cannot select images for
Category 3 records.
7 To delete a category, select the category to delete, and click Delete.
To delete a parent Category 1 record, you must first delete the child Category 2 and
Category 3 records.
NOTE
You cannot delete a navigational category that is currently used with an SRD. You
must first select a different category for the SRD or delete the SRD. Then, you can
delete the category.
8 To localize the navigation categories, click Manage Locales.

Translated categories follow the default language sort order specified in Category
Management.
The Category Localization form lets you manually translate each category. You can
specify the locale to show the navigational category in the language that is the most
useful to your users. You can deliver localized navigational categories to different
users, simultaneously, in multiple languages with different display properties.
NOTE
Deleting a category unrelated to an SRD deletes all localized categories. For more
information, see“Localizing navigational categories” on page 333.
To sort global navigational categories, see “Sorting navigational categories” on

page 71.

Defining company navigational categories

You can create up to three levels of company navigational categories, which
appear in the Request Entry console when a user clicks Browse Catalog.
Calbro Category 1
Global Category 1
Global Category 2
Calbro Category 3
Global Category 3
Calbro Category 3
Global Category 2
Calbro Category 2
Calbro Category 1
Global Category 1
You can create a combination of global and company navigational categories, and
later interleave these categories together. For example, you can insert a company
category between two global categories.
NOTE
You can add company Category 2 or Category 3 records under global categories,
but you cannot add global categories under company categories.
To define company navigational categories

tab.
Navigational Categories > Category Management, and click Open.
The Category form appears in New mode. The global categories you previously
created (for example, Software, Hardware, and so on) appear in the category tree.
3 To create a company Category 1 record:
a From the Select Company field, select your company (for example, Calbro
Services).
b Select Categories at the top of the tree.
c Click Add.
d Select New Category from the tree.
e Enter a Category Name (for example, Calbro Services Computers).
If you want to enter the greater than (>) or less than (<) sign in the Category
Name field, use encoded text (&gt for >, and &lt for <); otherwise, browsers will
category name is included in a URL.
f (optional) Add a brief description of the category and change the image.
Sorting navigational categories
g Select the status of the navigational category.

h Click Apply to add the category details to the tree.
4 Add additional Category 1 records, until you finish adding your Category 1
records.
The Category 1 records can be either global or company-specific.
b Click Add.
c Enter a category name (for example, PC) and a description.
The Category 2 records can be either global or company-specific.
b Click Add.
c Enter a category name (for example, Ubuntu) and a description.
7 To delete a category, select the category to delete, and click Delete.
To delete a parent Category 1 record, you must first delete the children Category 2
and Category 3 records.
NOTE
You cannot delete a navigational category that is currently used with an SRD. You
must first select a different category for the SRD or delete the SRD. Then, you can
delete the category.
Sorting navigational categories

You can sort category items in each category level up or down in the category tree.
Global Category 1 Software
Calbro Category 2 Acrobat
Global Category 2 Microsoft
Calbro Category 3 Excel
Global Category 3 MS Word
Global Category 1 Hardware
Calbro Category 1 Email
Calbro Category 1 Computers
Calbro Category 2 PC
Calbro Category 2 Macintosh
For example, you can move Calbro Category 1 Email up above Global Category 1
Hardware or you can move it below Calbro Category 1 Computers, but you cannot
move it to any Category 2 or Category 1 level in the tree.

You can sort Category 2 and Category 3 records in their category levels. You can
sort its global and company Category 2 records (for example, Calbro Acrobat or
Global Microsoft), or its global and company Category 3 records (Calbro Excel or
Global Microsoft Word).
NOTE
After you have selected a company, you cannot sort any Global categories. You
must select Global as the company to enable sorting of Global categories.
To sort navigational categories

1 Select a record in the Categories tree.
2 Click the arrows to move the categories up or down.
You can sort global and company records in each category level.
TIP
Sort the Global categories first, and sort the company categories later.
3 (optional) To test your navigation categories:

a From the Service Catalog Manager Console, click Create.
b From the Service Request Definition form, create one or more SRDs with your
navigation categories (global or company), and deploy them.
c Log into the Request Entry console.
If you correctly configured the navigational categories, your global and
company categories appear properly.
4 Click one of the Browse Subcategories links.
The Category 2 and Category 3 values appear.
Chapter
4 Creating application
templates and application
object templates
Before you can create process definition templates (PDTs) and service request
definitions (SRDs), you must create an application template, which is stored in an
application object template (AOT). You will have an AOT for each step in the
process of a service request.
AOTs are created by the Service Catalog Manager to define the process steps that
are used in PDTs.
NOTE
You must have the Request Catalog Manager permission to create AOTs.

About application templates (page 74)
About application object templates (page 82)
Defining AOTs (page 83)
About registering application templates with AOTs (page 86)

About application templates

You can use application templates for routine incidents, standard changes, or work
orders that users frequently request.
NOTE
Do not confuse application templates with application object templates (AOTs)—
AOTs are container objects that contain an application template.
Application templates are templates that are part of other applications, for
example:
Work order templates are used with the Work Order Management application,
which is included with BMC Service Request Management.
Change templates are used with the BMC Remedy Change Management
application.
Incident templates are used with the BMC Remedy Incident Management
application.
NOTE
Application templates are sometimes called “application fulfillment templates”
because you create them from the underlying applications that fulfill their tasks
(for example, Work Orders or BMC Remedy Change Management), not BMC
For the SRM administrator, the main use of an application template is including it
with an AOT.
If you use an application template with an AOT, you must create the application
template before defining the AOT. In addition, if you do not associate the
application template in the Application Object Template form, it is not accessible
for BMC Service Request Management to use.
NOTE
You can create an AOT without an application template. Quick launch and no-
template AOTs do not use application templates. No-template AOTs create the
fulfillment request without a fulfillment application template. For more
information, see “Configuring service request image definitions” on page 174.
An application template can map to only one AOT. You can create as many
application templates as needed, but the best practice is to create application
templates for routine incidents, standard changes, or work orders that users
frequently request.
As the SRM administrator, you can simplify the process of creating work orders by
creating work order templates for your support groups. The support groups can
use the templates to quickly and efficiently create standard work orders with a
minimum of mouse clicks and keyboard entry. Work order templates are useful in
any work order that follows well-defined methods for specific and repeated
requirements—for example, Installs, Moves, Add Changes (IMAC).
For example, using the Work Order Template form, you can create a special
“Office Upgrade” template, which is built into an AOT to create requests with
certain pre-set values. When a service to upgrade office furnishings is requested,
BMC Service Request Management creates a work order with the company,
categorizations, tasks, and assignments predefined.
NOTE
For more information about AOTs, see the “Defining AOTs” on page 83.
Parameters for creating application templates

Create the application templates with the following parameters. You can modify
these values as needed for your own environment.
Application Tab or field Value Function

template
Incident Header Enter required Receives data input (Categorization
Management information to complete Tier 1) from service request.
incident template (for
example, IMT).
Note: Set Status to
Assigned.
Authored For Groups tab Enter company
information in required
fields.
Change Header Enter required Receives data input (Categorization
Management information to complete Tier 1) from incident.
Template change template (for
example, CMT).
Classification Tab Enter information in the
required fields.
Authoring For Groups Enter company
tab information in the
required fields.
Work Order 1 Header Enter required Receives data input (Categorization
information to complete Tier 1) from change request and places
work order template (for it in the Description field.
example, WOT1).
Note: On the Work Order form, the
Classification Tab Enter company Summary field is used for the
information in required description.
fields.

Application Tab or field Value Function

template
Work Order 2 Header Enter required Receives data input (Categorization
information to complete Tier 1) from change request and places
work order template (for it in the Detailed Description field.
example, WOT2).
Classification Tab Enter required
information to complete
work order template.
About work order templates

When using Work Order Management, you can simplify the process of creating
work orders by configuring work order templates for use in AOTs. You also can
create work order templates that help support staff to quickly create work orders.
NOTE
You must have Work Order Config permission to create work order templates.
You can create templates for any work order or task for users who regularly
perform preapproved work orders that follow well-defined methods for specific
and repeated requirements, for example, Installs, Moves, and Add Changes
(IMAC). You can create as many templates as needed, however, as a best practice,
create templates for only standardized processes that your users perform on a
frequent basis.
The values you configure in the Work Order Template form are used to add
information to the Work Order form.
Work order template classification

The values you specify in a work order template’s Classification tab are used to
add information to the corresponding Classification tab in the Work Order form.
The Classification tab is used to describe the work order and show which products
or services are affected by the work order.
Operational categorization is based on a three-tier hierarchy defined in the
Operational Catalog Setup form. The Operational Categorization Selection
settings add information to the operational categorization fields in the
Classification tab of the Work Order form.
Product categorization is based on a five-tier hierarchy defined in your Product
Catalog Setup form. The Product Categorization Selection settings add
information to the product categorization fields in the Classification tab of the
Work Order form.
For more information about company product catalog information and
operational catalog information, see the BMC Remedy IT Service Management
Assignment settings in a work order template

The values you configure in a work order template’s Assignment tab are used to
add information to two areas in the Assignment tab of the Work Order form:
The Request Manager settings fill the Request Manager fields in the Assignment
tab of the Work Order form. Here you configure the support company,
organization, and group to which the work order will be assigned.
The Request Assignee settings fill the Request Assignee fields in the Assignment
tab of the Work Order form. Here you configure the support company,
organization, and group by which the work order will be implemented.
Configuring work order templates

This section provides information about configuring work order templates.
To configure work order templates

tab.
2 From the Application Settings list, choose Service Request Management > Work
Order > Work Order Template, and click Open.
3 Enter information in the following fields at the top of the Work Order Template
form:
a In the Company field of the, select a company for the template.
b In the Summary field, enter a brief description of the work order.
c In the Template Name field, enter a name for the template.
d In the Work Order Type field, select the appropriate type for this template—for
example, General (the default) or Project.
e (optional) In the Notes field, enter a complete description of the template.
f In the Status field, select a status.
This information is entered to the Summary field on the Work Order form.
g Click Save to add your template to the list of available work order templates.
NOTE
The new template is unregistered for BMC Service Request Management. To
register the template by adding it to an AOT, see “Defining AOTs” on page 83.
4 From the Classification tab of the Work Order Template form, enter information in
the following fields:
a In the Company field, select the name of the company for requests based on this
template
b (optional) In the Region field, select the area of the company.
c (optional) In the Site Group field, select the city of the company.

d (optional) In the Site field, select the location of the company for this work order.
e (optional) In the Business Service field, select a business service configuration
item (CI) to relate to this work order. Items in the list are retrieved from the
Atrium Service Catalog.
f (optional) Select the appropriate operational categorizations for Tier 1, Tier 2,
and Tier 3.
Here you configure the three-tier hierarchy defined in your operational catalog.
g (optional) Select the appropriate product categorizations for Tier 1, Tier 2, Tier 3,
Product Name, and Model/Version.
Here you configure the five-tier hierarchy defined in your product catalog. If
you do not see the appropriate product, continue to make selections in product
categorization until you see the appropriate product.
h Click Save.
5 From the Tasks tab of the Work Order Template form, enter information in the
following fields to specify which tasks and task groups to include in this template:
a To add a task or task group to your template, select a request type in the Type
list (for example, Task Template) and click Relate.
b (optional) Use the Type (for example, ALL) and Category (for example, Task
Management System) fields in the Select Template dialog box to filter the list of
tasks that appear.
c Select a task or task group, and click Relate.
The task or task group is added to the template.
d Close the dialog box, and click Save.
To configure assignment settings

1 In the Work Order Template form, click the Assignment tab.
2 Specify Request Manager settings as follows:
a In the Support Company field, select the company that the work order is
assigned to.
b In the Support Organization field, select an organization.
c In the Support Group Name field, select a group.
d In the Request Manager field, select a manager.
3 Specify Request Assignee settings as follows:
a In the Support Company field, select the company to implement the work order.
b In the Support Organization field, select an organization.
c In the Support Group Name field, select a group.
d In the Request Assignee field, select an assignee.
4 Click Save.
5 Register the work order template for use with an AOT.

For more information, see “About registering application templates with AOTs”
on page 86.
6 Create a PDT using this AOT.
Adding information for advanced interface forms

You configure the fields in the Details and Details2 tabs exclusively for use with
advanced interface forms.
The Details tab and the Details 2 tab specify static-content fields you can include
with this work order template. This functionality is especially useful for work
orders because you can include up to 22 character fields (255-character limit each),
2 date and time fields, and 6 integer fields for users to add information to their
work order.
To configure details fields

1 From the Work Order Template form, click the Details tab or the Details 2 tab.
2 In the Field Labels column, enter field labels (questions posed to users) as they
should appear on the work order.
For example, the label for the SR Type Field 1 field (Enter first name of employee)
on Mapped tab of your advanced interface form should be entered to the first Field
Labels field on the work order template.
Figure 4-1: Mapped fields from advanced interface form

For optional questions posed to users, enter any default field values to appear on
the work order next to the corresponding field labels when a user does not provide
a response.
For more information about using advanced interface forms, see “Creating and
using advanced interface forms” on page 345.
3 In the Field Values column, enter any default field values that you want to appear
in the corresponding fields.
The following table shows the field types for the details fields.
Field number Field type
1-5 Character
6-7 Date/time
8-9 Integer
10 - 23 Character
24 - 27 Integer
28 - 30 Character
4 Click Save.
These fields appear when users select the SRD in the Request Entry console.
NOTE
Unless more than 15 total fields, or all the available fields for any field type
(22 character fields, 2 date/time fields, or 6 integer fields) are configured, the
Details 2 tab will not appear to users in the Request Entry console.
Modifying or deleting work order templates

This section provides information about modifying or deleting work order
templates.
To modify or delete work order templates

tab.
Order > Work Order Template, and click Open.
3 To switch the form to Search mode, click the New Search button from a browser,
or press F3 from BMC Remedy User.
4 Enter the search parameters to find the template to modify or delete, and click
Search.
5 To modify a template, select it, make your changes, and click Save.
6 To delete a template, select it, and delete it using one of the following methods:
Change to Status field value to Delete and save the change template.
If you have AR Admin permissions, choose Actions > Delete in BMC Remedy
User, or click the Delete button below the results list in a browser.
Creating change templates

If you have BMC Remedy Change Management installed on your system, you can
create change or incident templates to use with your AOTs.
To create change templates

NOTE
Only users with Change Master or Change Config permissions can create change
templates for their support group. For additional information about change
templates, see the BMC Remedy IT Service Management Configuration Guide.

tab.
2 From the Application Settings list, choose Change Management > Template >
Template, and click Open.
3 From the Change Template form, create a change template that performs a basic
task for your users (for example, reset the phone number and voice mailbox for a
new employee).
4 After you configure your settings, click Save to add your template to the list of
available change templates.
The new template is unregistered. To register the template by adding it to an AOT,
see “Defining AOTs” on page 83.

Creating incident templates

If you have BMC Remedy Change Management or BMC Remedy Incident
Management installed on your system, you can create change or incident
templates to use with your AOTs.
To create incident request templates

NOTE
Only a user with Incident Master or Incident Config permissions can create
incident templates for their support group.
BMC Service Request Management cannot create an incident request if the

incident template that defines an assignee.
For additional information about incident templates, see the BMC Remedy IT
Service Management Configuration Guide.

tab.
2 From the Application Settings list, choose Incident Management > Template >
Template, and click Open.
The Incident Template form appears in New mode.
3 Create an incident template that performs a basic task for your users, (for example,
so that new employees who forgot their passwords can create an incident).
4 After you configure your settings, click Save to add your template to the list of
available incident templates.
The new template is unregistered. To register the template by adding it to an AOT,
see “Defining AOTs” on page 83.
About application object templates

Use the Application Object Template form to define the company, application, and
optional application templates to use with the AOT. Defining an AOT enables it to
be used for later development, when you or the Service Catalog Manager creates
process definition templates (PDT) and service request definitions (SRD).
IMPORTANT
Do not confuse AOT with application templates—AOTs are container objects that
contain an application template.
Each AOT can include one application template. You can add only an unregistered
application template to an AOT. For more information, see “About application
Defining AOTs
You can use the Application Object Template form to associate target data to AOTs
that are used with BMC Service Request Management. Adding target data to your
AOT allows you to add requester questions when you define your SRD. You
cannot add questions to your SRD until you have added target data to your AOT.
You can map input and output variables in your AOT to pass data dynamically
between different fulfillment applications:
Input variables are entered in target fields and are required for the fulfillment
application (analogous to input parameters to a procedure). In the AOT, the
inputs are answers to target data questions. If an AOT has an input defined, at
runtime the data is passed to the fulfillment request at the request creation time.
Output variables are taken from a field on the fulfillment application. These
variables are the process results of the AOT that are made available to the caller
of the process (analogous to output parameters to a procedure). If an AOT has
an output defined, at runtime an entry is created in a variable temporary form
when the fulfillment request is resolved.
For information about target data from applications other than BMC Remedy
Change Management, BMC Remedy Incident Management, or the Work Order
application, see the Integrating BMC Service Request Management with Custom AR
System Applications white paper.
Defining AOTs
The following procedure describes how to define an AOT.
To define AOTs
tab.
Application Configuration > Define Application Object Template, and click Open.
3 Enter the following information in the Application Object Template form:
Field Description
Locale Select the locale to show the AOT in the language that is the most
(optional) useful to your users. You can deliver localized AOTs for use with
PDTs, simultaneously, in multiple languages with different
formatting.
Here you are creating the initial set of display properties in the
AOT, based on the locale that you specify (for example, fr_FR).
If English is the only locale installed, this field is not available.
Company Specify the company connected with this AOT.

Field Description
Type Specify the type of AOT. You can select from the following types:
NO TEMPLATE—AOT does not use an application template to
create the fulfillment request. You can include target data.
Quick Launch—Launches a URL in another window and
completes the service request for tracking purposes. Using a
quick launch AOT with an SRD does not require approval.
Quick launch AOTs do not use application templates.
TEMPLATE—AOT uses an application template with pre-
defined values. You can include target data. You cannot use this
option with global AOTs.
Name Enter a descriptive name of the AOT.
End User Enter a name of the AOT for users to appear at runtime in the
Displayed Name Request Entry console when you view the Process Details of the
service request.
Summary Enter a descriptive summary of the AOT.
App Registry Select BMC Remedy Change Management, BMC Remedy Incident
Name Management, or the Work Order application.
Note: Not all the items that appear in the menu are eligible.
Template Name Registers an application template with this AOT when the form is
in New mode (see step 4 on page 84). The name of the
unregistered template is entered in the field.
After registering the template, you have locked the AOT to that
template.
Note: You can select only application templates that have not yet
been registered.
Status Select the AOT’s status.
URL The URL field becomes activated when you select the Quick
Launch type.
Enter the URL needed to launch the window.
4 From the Template Name field, click Select to register an application template with
this AOT.
The Register Application Template form appears.
When you create an application template (for example, a work order template),
you can register it with an AOT. The pre-set values in the application template in
associated with the AOT. When you include the AOT in an SRD, the pre-set values
are used to create the fulfillment requests when the SRD creates a service request.
NOTE
Application templates must be created by the registered fulfillment application
before you can register them with BMC Service Request Management. For more
information about change and incident templates, see “About application
Defining AOTs
Registered templates that belong to the registered application show Yes in the
table, along with a name and brief description.
For more information, see “About registering application templates with AOTs”
on page 86.
5 Select an unregistered template from the list, and click Register.
The Register Application Template dialog box closes, and the name of the
application template appears in the Template Name field.
The application template becomes registered with the AOT when you save your
changes.
NOTE
Application templates can be registered only once, and you can include only one
application template for each AOT.
If you receive an error message (ARERR 9280), make sure that the server name in
the mid tier configuration matches the server name used by the CAI application
registry. BMC recommends using fully-qualified names.
6 Click the Add Target Data button.
7 From the Available Target Data table, add target data fields to the AOT.
Make sure that sufficient target data is added. An attempt to create a work order
from the SRD will fail if the required fields are not included (for example, if the
Description field is not added as a target).
8 In the list of selected target data, define a default value for the target data in the
Default Value field.
For example, administrators can configure that the Customer Name field with a
prepopulated value ($USER$) appears on the SRD. Administrators can also add
hidden fields to the SRD, with prepopulated values.
Even if the target data is not exposed, you should provide default values, so that
the correct target data is provided. An attempt to create a work order from the SRD
will fail if the required fields do not have the correct values entered (for example,
if the Summary field is left empty).
9 In the Exposed field, select Exposed to expose the field to the PDT.
10 Click Save.
When the Service Catalog Manager associates the AOTs to the PDT, this action
rolls up the target associated with the AOT to the PDT.
11 Save the AOT.

About registering application templates with

AOTs
After defining AOTs, you must register the application templates with your AOTs.
You can modify these values as needed for your own environment.
AOT Tab or field Value Function

Incident Application Object Enter required Receives data input (Categorization
Management Template fields information to complete Tier 1) from service request.
AOT the AOT (for example,
AOT_IM).
App Registry Name BMC Remedy Incident
Management
Add Target Data Categorization Tier 1
(Exposed)
Summary (Exposed)
Change Application Object Enter required Receives data input (Categorization
Management Template fields information to complete Tier 1) from incident.
AOT the AOT (for example,
AOT_CM).
App Registry Name BMC Remedy Change
Management
Add Target Data Categorization Tier 1
(Exposed)
Summary (Exposed)
Work Order Application Object Enter required Receives data input (Categorization
AOT 1 Template fields information to complete Tier 1) from change request and
the AOT (for example, places it in the Description field.
AOT_WO1).
Note: Output variable is not required
App Registry Name Work Order Application in this scenario.
Add Target Data Summary (Exposed)
Work Order Header Enter required Receives data input (Categorization
AOT 2 information to complete Tier 1) from change request and
the AOT (for example, places it in the Detailed Description
AOT_WO2). field.
App Registry Name Work Order Application Note: Output variable is not required
Add Target Data Detailed Description in this scenario.
(Exposed)
Chapter
5 Creating process definition

templates
Before you can create service request definitions (SRDs), you must create a process
definition template (PDT) for each process for a service request.
NOTE
To create and modify PDTs, you must have Request Catalog Manager permissions.

About PDTs (page 88)
Understanding data flow in PDTs (page 88)
About variables (page 90)
Creating PDTs—Quick Start (page 90)
Creating a standard PDT (page 91)
Creating a quick launch PDT (page 98)
About using the Service Catalog Manager Console to manage PDTs (page 99)
Example of creating PDT (page 102)
Dynamic data flow—mapping data between applications (page 105)
About building PDTs that use dynamic data flow (page 106)

About PDTs
A process definition template (PDT) is an intermediate object that relates AOTs or
nested PDTs to SRDs. In other words, a PDT is a fulfillment process. It can define the
process used to fulfill a specific service request, for example, creating an incident
request and a series of change requests for a hard drive upgrade. PDTs are not
directly used by themselves; they are intended for use only with SRDs.
As a best practice, simplify the design of your PDTs to make them easily reusable.
A single PDT can be related to multiple SRDs.
NOTE
A PDT can be nested inside other PDTs, but you can nest PDTs only up to six
levels. A PDT cannot be nested inside itself.
Use the Process View of the Service Catalog Manager Console to create and
manage PDTs.
Understanding data flow in PDTs

Creating a PDT includes adding other nested processes (PDTs) and application
object templates (AOTs) that are needed to complete a service request. Application
object templates can include work orders, the BMC Remedy Change Management
and BMC Remedy Incident Management applications (if these applications are
installed), or quick launch AOTs.
SRDs are not directly related to AOTs. The SRD uses one PDT (which is related to
the AOTs and PDTs) to define the process that fulfills the request.
How PDTs are defined

When you define PDTs, include the following elements:
You associate processes and application object templates (AOT) with the PDT.
A PDT can also be “nested” inside other PDTs, up to six levels. As a rule of
thumb, however, you should avoid creating too many layers of nested PDTs, to
avoid performance problems on the server.
You can specify the order in which the processes and AOTs are activated. You
can order them to run either in parallel (in any order) or in strict sequence (1, 2,
3, and so on). You also add conditions to the PDT to skip sequences, for example,
1, 3, 5, and so on.
For example, activating a phone line for a new employee requires that the
application create the following fulfillment requests:
Verify the employee’s specific details.
Search for an available phone number to assign.
Order the phone.
Understanding data flow in PDTs
Activate the line.

Test the line.
Schedule an appointment for a technician, if necessary.
Notify the employee that the service is active.
When you have finished defining the PDT, you can verify the sequence of the
processes and AOTs in the Process View of the Service Catalog Manager Console.
How PDTs work when a user requests a service

When a user requests a service from the catalog and the PDT is created as a series
of fulfillment requests (for example, change requests), fulfillment providers can
perform some of these changes at the same time in parallel, some changes must be
performed in a strict sequence, and some changes are conditional.
When the PDTs and AOTs run in parallel, the application simultaneously creates
one change request to order the phone and another change request to search for an
available phone line. The fulfillment providers can work on their requests at the
same time. For a request for ordering a phone, you can design a PDT that creates
one request to verify the employee’s specific details and another to search for an
available phone line to assign. These two requests can be performed in any order.
When the PDTs and AOTs run in a strict sequence to order a phone, the application
activates the first change request to order the phone (this change request is
assigned a change request ID). The other change requests are not yet activated, nor
are they assigned change request IDs. Only after the first change request is
completed does the application activate the second change request. As a result, the
assignee must completely finish the first change request before the second assignee
can start testing the phone line. In turn, both these requests must be completed
before the application activates the third request to notify the employee that the
phone line is active.
NOTE
If you create a service request that activates a sequence of fulfillment requests—for
example, a series of change requests, incidents, or work orders—and then you
cancel a fulfillment request that was activated, the next request in the sequence is
activated. However, if you cancel the service request, the fulfillment requests are
cancelled.
When the PDTs and AOTs are conditional, flow criteria determines if the next action
is executed or bypassed. For example:
If the first change request is completed, create the second request.
If the first change request is not approved, create an incident.
For more information, see “Designing the PDT flow in the Visual Process Editor”
on page 92.
If you have also have Service Request User permissions, you can open the request
in the Service Requests form and view the application instances that were created
in the Processes and Questions tab.

About variables
You can define output variables that hold the results of an AOT or PDT. You use
these variables as input to another AOT or PDT. You also use variables when
mapping questions to SRDs.
Process input variables—Used to pass data to the current PDT or AOT. They can
also be used to pass data from the request to the fulfillment process. The
direction of input variables is to target fields. Input variables are required for the
fulfillment application (analogous to input parameters to a procedure). In the
AOT, the inputs are answers to target data questions. If an AOT has an input
defined, at runtime the data is passed to the fulfillment request when the request
is created.
Process output variables—Used to pass data from the current PDT or AOT to
another PDT or AOT. The direction of output variables is from a field on the
fulfillment application. These variables are the process results of the AOT that
are made available to the caller of the process (analogous to output parameters
to a procedure). If an AOT has an output defined, at runtime an entry is created
in a variable temporary form when the fulfillment request is resolved.
Internal variables—Used internally within the PDT or AOT and not exposed
outside the PDT or AOT. You can pass data between process fulfillment steps,
conditions, and so on. You cannot map questions to Internal variables.
Creating PDTs—Quick Start

To create PDTs, perform the following steps.
Action For more information, see

1 Verify that the navigational categories, “About application templates” on
application template (optional), and the page 74
AOT are configured. “Defining AOTs” on page 83
“Configuring navigational categories” on
page 65
2 Open the Service Catalog Manager “Opening application consoles” on
Console. page 36
“About using the Service Catalog
Manager Console to manage PDTs” on
page 99
“About PDTs” on page 88
Creating a standard PDT

3 Select one of the process definition “Creating a standard PDT” on page 91
template (PDT) types: “Creating a quick launch PDT” on
Standard PDT page 98
Quick Launch PDT
You cannot combine PDT and SRD types.
For example, you must use a standard
PDT with a standard SRD.
4 (optional) Localize the PDT. “Localizing PDTs” on page 337
5 Add the PDT to the SRD. “Adding a standard process template to
You cannot combine PDT and SRD types. an SRD” on page 125
For example, you must use a standard “Adding a quick launch process template
PDT with a standard SRD. to an SRD” on page 127

You use the Process Definition Template form to create a standard PDT.
This form includes the following functionality:
General Details tab—Defines Description, Work Info, and Used By areas
Process Details tab—Includes workspace in which you drag-and-drop AOTs,
nested processes (PDTs), and conditions to build the PDT and define variables.
The Visual Process Editor enables you to add processes and conditions to the
standard PDT that are needed to complete a service request.
The following sections describe the best practices you should follow when creating
a standard PDT.
Opening the Process Definition Template form and getting started

To create a PDT, use the Process Definition Template form.
To open the Process Definition Template form and get started

1 Open the IT Home Page.
2 Click the Service Catalog Manager Console link.
3 Click Console Focus in the left navigation pane, and click Process.
4 Click Create in the Process View of the Service Catalog Manager Console.
5 In the Process Details tab of the Process Definition Template form, enter the name
and description of the PDT.

6 Add a company to the PDT.

The company can represent internal groups or business units as well as external
vendors or customers. If you select Global, any user (including guests) can access
the PDT.
NOTE
PDTs can be used in a multi-tenancy environment.
7 From the Request Type list, select Standard.

A standard SRD is linked to a PDT. In the PDT context, a standard SRD means that
the Service Catalog Manager must select PDTs of the same request type, or AOTs
that are TEMPLATE or NO TEMPLATE type.
See “Creating a standard SRD with the Service Request Definition form” on
page 116. For more information about AOT template types, see “About application
object templates” on page 82.
Designing the PDT flow in the Visual Process Editor

The next step is to place the AOTs, nested PDTs, and conditions in the PDT. The
Visual Process Editor enables you to “drag and drop” process objects from the
Palette to construct the design and flow of your PDT.
You can create conditional processing in PDTs by specifying the flow criteria that
determines if the next AOT or PDT in the branch is executed. The SRM
administrator can define conditions that would determine which branches in the
process flow are executed or bypassed.
If you add a condition to the PDT, you create a decision branch in the process flow:
If the condition passes, the PDT executes the Yes branch.
If the condition fails, the PDT executes the No branch.
To design the PDT flow in the Visual Process Editor

1 In the Process Definition Template form, click the Process Details tab if it is not
already in view.
2 Drag-and-drop PDT, AOT, or condition objects from the Palette to add processes
to the Visual Process Editor workspace.
When designing your PDT, you can mix and match any combination of nested
PDT, AOT, or condition objects for a Standard SRD.
Figure 5-1: Adding nested PDTs, AOTs, and conditions to the process
The objects are activated in the visual sequence displayed in the workspace. Here
the Install Office AOI runs first.
If it is successful, the PDT executes the Yes branch and the New Employee PDT
is activated.
If it is unsuccessful, the PDT executes the No branch and the Create an
incident AOT is activated.
When you specify that processes are in the same level (for example, the two AOTs),
they run in parallel.
When you drag a new node (for example, an AOT) to a row of nodes, the node is
added to the beginning or end of the row.
3 To rearrange PDTs, AOTs, and conditions, select the object in the workspace and
drag it to its new level or position.

Figure 5-2: Dragging PDTs or AOTs to different levels
For example, you can drag the AOT to a new level, next to the Install office
PDT.
4 To delete an object, right-click it, and select Delete Shape.
If you delete a condition, any AOTs, PDTs, and nested conditions in the branches
of the condition are also deleted. You will not receive a confirmation, and you
cannot undo the action.
Defining variables
The next step is to define the variables that can be used to control the data flow and
process flow that you are defining in this PDT.
You can pass data between processes and process steps (for example, from a work
order to a change request) by adding variables to the process flow. These variables
are also mapped to SRDs for their target data. For more information, see “About
variables” on page 90.
To define variables
already in view.
2 Select an AOT or PDT in the Visual Process Editor workspace.
3 Click the Define Variables panel (at the bottom right).
4 In the Define Variables area, define the names, description, and default value of the
variable.
5 Select the process input type (Process Input, Process Output, or Internal).
You use these to specify the direction of your variables. The Internal type is used
to pass data between PDTs in the process diagram. You cannot map questions to
Internal variables.
Select Process Input if you want to map the variable to a question when creating
an SRD.
6 For Process Input variables, if you want to request that data is entered for this
variable (by users answering a question, through a mapping, or through a default
value), select the Input Required check box.
7 Click Add.
You can modify or remove these variables as needed. You can also view their
usage.
Defining the properties of the process objects

When you are finished with the design and flow of the PDT, you must define the
properties of the AOT, PDT, and condition objects.
To define the properties of the AOT or PDT objects

already in view.
3 In the Name field of the Define Properties panel, select an AOT or PDT from the
menu.
4 Verify the read-only information in the remaining fields.
5 If you are sure you selected the correct AOT or PDT, click Apply to show the
correct object name in the process workspace.
To define the condition properties

1 Select the condition object in the Visual Process Editor workspace.
2 In the Name and Description fields, enter a name and description for the condition.
3 In the Condition field, enter a qualification that the condition will evaluate.
You can use variables that you created for the PDT. Click the ellipsis button (...) to
open the Condition Builder and create the condition.
4 Click Apply.
Mapping the direction of the data flow

After you define the variables and the properties, map the direction of the data
flow. For example, you can specify that the data from one variable is passed to
another variable. The variables you defined under the Variable panel are available
for mapping to target data.
To map the direction of the data flow

already in view.
3 Click the Map Data panel (at the right).

4 In the table on the Map Data panel, select one of the fields that you exposed in the
AOT. (The fields come from the fulfillment application.)
5 If you want to enter data into the field on the fulfillment application, select a
variable from the Input field.
The data from the variable will be entered into the field on the fulfillment
application.
6 If you want field data from the field on the fulfillment application pushed to
another AOT or PDT, select a variable from the Output field.
You can enter variables in the Input and Output fields. For example, an input
variable might enter data into a Cube Number field, but if the fulfillment provider
changes the data in that field on the fulfillment application, the data can be pushed
to the next process steps (AOT) through the Output variable.
7 Click Apply.
8 Click Save.
Defining General Details in a standard PDT

When creating a standard PDT in the Process Definition Template form, you can
define other information such as the category and status of the PDT.
To define the General Details in a standard PDT

1 In the Process Definition Template form, click the General Details tab.
2 (optional) In the End User Displayed Name field, enter a name that you want to be
displayed to the end user if it is different from name in the Name field.
This name is displayed in the Process View of the Request Entry form.
3 Define the category.
You can select a category from the menu, for example, Generic. You can also enter
a new PDT category (for example, BMC Remedy Change Management, BMC
Remedy Incident Management, or Work Order). After you save the PDT, you can
select these categories from the Category menu. If multi-tenancy is enabled, not all
categories are available to all managers.
4 Specify the status (for example, Active).
5 (optional) Add a version number.
To use the Work Info and Used By areas on the General Details tab, see:
“Checking use of this PDT by other PDTs and SRDs” on page 97
“Adding work information to the PDT” on page 97
Adding work information to the PDT

You can add work information to the PDT regarding tasks performed on the PDT.
For example, you might track a PDT’s progress by recording the steps you took to
implement it. The work information for each task is shown in the Work Info
History area on the Process Definition Template form.
To add work information to the PDT

1 In the Process Definition Template form, click the General Details tab if it is not
already in view.
2 In the Work Info area, click Create.
3 Enter the details of your work information record in the Summary and Notes
fields.
4 To add attachments to the record, right-click in the attachment table, and click
Add.
5 Click Save.
The Save operation adds your entry to the task’s work history. The Show field
enables you to filter specific work entries based on the type of activity shown in the
table.
6 To see a BMC Remedy AR System report of the activities you performed against
this task, click Report.
The Report Preview dialog box appears, to show the work information entries.
You can create BMC Remedy AR System reports by using the Report Selection and
Report Creator forms. Reports created using the Report Creator form
automatically create an entry to the Report form when submitted. See the
following documentation:
BMC Remedy User help
BMC Remedy Action Request System BMC Remedy Mid Tier Guide
7 To show all entries for work information history, click View.
8 Click Save.
Checking use of this PDT by other PDTs and SRDs

After you create the PDT, you can check how many SRDs and PDTs are using it.
To check the use of this by other PDTs or SRDs

1 In the Process Definition Template form, click the General Details tab if it is not
already in view.
2 From the Show list in the Used By area, select Related Process Definition
Templates or Related Service Request Definitions.
The Used By table shows the title and status of the PDTs and SRDs that consume
this PDT.

Creating a quick launch PDT

The quick launch PDT launches a URL in another window. You might want to link
to another site that also lets users make requests, such as a link to your Human
Resources intranet site or an outside financial services site where employees can
check their retirement accounts.
When a user clicks a link created from a quick launch PDT a request is created and
is immediately closed.
You can then use these links to obtain usage statistics by a site by running a report.
To create a quick launch PDT

4 Click Create.
5 In the Name and Description fields, enter the PDT’s name and description.
6 Add a company to the PDT.
The company can represent internal groups or business units as well as external
vendors or customers. If you select Global, any user (including guests) can access
the PDT.
NOTE
PDTs can be used in a multi-tenancy environment.
7 From the Request Type list, select Quick Launch.

Quick launch request types launch a URL in another window and complete the
service request. These service requests do not require approval. In the PDT context,
the catalog manager must select quick launch AOTs.
See “Creating a quick launch SRD” on page 123. For more information about AOT
template types, see “About application object templates” on page 82.
8 Click the Standard Editor button to associate an application object or process to the
PDT.
Use the Add/Change Processes dialog box to add or remove quick launch AOTs.
9 Select a quick launch AOT from the list, and click Select.
10 Click the General Details tab in the Process Definition Template form.
About using the Service Catalog Manager Console to manage PDTs
11 Define the category.

You can select a category from the menu, for example, Generic. You can also enter
a new PDT category (for example, BMC Remedy Change Management, BMC
Remedy Incident Management, or Work Order). After you save the PDT, you can
select these categories from the Category menu. If multi-tenancy is enabled, not all
categories are available to all managers.
12 Specify the status (for example, Active).
13 (optional) Add a version number.
14 Click Save.
About using the Service Catalog Manager

Console to manage PDTs
The Service Catalog Manager Console provides a dedicated workspace where you
can manage process definition templates (PDTs). From the Service Catalog
Manager Console, you can define the implementation process for each catalog
offering. The console enables you to easily create fulfillment processes.
For each Service Catalog offering, you can define a business process. You can reuse
these processes for multiple service requests. According to one Help Desk Institute
(HDI) study, “if end-to-end business processes have been mapped, it will be easier
and quicker to relate those end-to-end processes with supporting IT and other
business services.” The Service Catalog Manager Console of the BMC Service
Request Management module supports these best practices as defined by HDI.
Search criteria—Managing PDTs

Searching for PDTs from the Process View of the Service Catalog Manager Console
works similarly to searching for SRDs on the Request Definition View of the
Service Catalog Manager Console. (Select these views under Console Focus on the
left navigation panel.) The Search Criteria area on the top part of the console
enables you to specify search criteria. The search results table shows PDTs that
match the criteria specified in the Search Criteria area and the Company selected
at the top of the console. In this way, the Search Criteria area enables you to filter
the PDTs that appear in the search results table. (Leaving all fields blank results in
a search for all PDTs that you have permissions to view.)

About using the Company field to search for PDTs

The Company field filters the PDTs shown in the search results table, based on
company. The content of this list is tenancy-driven, subject to your access to
various companies. If you have permissions to view only a single company, only
that company appears in the list. Selecting Global shows only the SRDs that are
designated as “Global.” Clearing the field shows all records to which the user has
access. You can also use the Search Criteria filter at the top of the console to filter
which PDTs you see.
After you perform your search, the results appear in the search results table.
When using a browser, if there are more records than the system can show in the
table, use the arrow keys at the top corner of the table. If you are using BMC
Remedy User, place the pointer in the table, right-click, and choose Next or Prev to
see the next grouping of records.
Reviewing information in the Process tab

When you select a PDT from the search results table, the Process tab to the right of
the search results table shows all application object templates (AOTs) and nested
process definition templates (PDTs) associated with the selected PDT.
Figure 5-3: Process tab information
Reviewing SRDs related to the PDT

The Request Definition tab to the right of the search results table enables you to
view which SRDs the selected PDT is related to.

About using the Service Catalog Manager Console to manage PDTs
Figure 5-4: Request Definition tab information
Using the Visual Process Editor to view processes from the Service
Catalog Manager Console
In the Process View of the Service Catalog Manager Console, you can view AOTs
and PDTs attached to an SRD with the Visual Process Editor.
NOTE
You must have Request Catalog Manager permissions to perform the following
procedure.
To view processes in the Service Catalog Manager Console with the Visual
Process Editor
4 Perform a search to view a list of available processes.
5 Select a process from the Search Results list.
6 Click View.
The information shown in this window is read-only if the SRD is deployed. If the
SRD is offline or not deployed, you can modify the process objects.

Example of creating PDT

In the following example, you create two PDTs:
In the first PDT, you associate three AOTs to create a PDT that uses the output
from the change request as input to the work orders.
In the second PDT, you associate the change management PDT and the incident
AOT that consumes the output data (Categorization Tier 1) from the service
request as its input.
You can modify these values as needed for your own environment. See “Creating
a standard PDT” on page 91.
Change request PDT

Add the information to the change request PDT in the order listed in the table.
Tab Area or field Objects or values Function or description

General Details Description area Enter required information to Receives data input (Categorization
complete the PDT (for example, Tier 1 and Summary) from incident
Change_Mgt_PDT). PDT.
Note: Because the incident PDT
consumes the change request PDT,
you create the incident PDT in the
next section.
Process Details Visual Process AOT1 Create three AOTs—AOT2 and
Editor AOT2 AOT3 run in parallel below AOT1.
AOT3 AOT2 and AOT3 receive input from
AOT1.
Process Details Define Properties AOT_CM Select AOT_CM, AOT_W01, and
panel AOT_WO1 AOT_W02 from the Name menu.
AOT_WO2
Process Details Define Variables cmV1_opcat_input Create four variables that are used
panel cmV1_opcat_output for input to AOT_CM and output to
cmV1_summary_input AOT_WO1 and AOT_WO2.
cmV1_summary_output
Process Details Map Data panel Operational Categorization Map input to output for AOT_CM.
Tier 1 field—Map The cmV1_opcat_input and
cmV1_opcat_input as Input cmV1_summary_input variables
and cmV1_opcat_output as receive their input from the incident
Output PDT.
Summary field—Map
cmV1_summary_input as
Input and
cmV1_summary_output as
Output

Example of creating PDT

Process Details Map Data panel Summary field—Map Map input for AOT_WO1.
cmV1_summary_input as Input The cmV1_summary_input variable
receives its input from the AOT_CM
PDT.
Note: You do not need to map an
output variable for this work order
AOT.
Process Details Map Data panel Operational Categorization Tier Map input for AOT_WO2. This PDT
1 field—Map cmV1_opcat_input has no output.
as Input The cmV1_opcat_input variable
receives its input from the AOT_CM
PDT.
Note: You do not need to map an
output variable for this work order
AOT.
Figure 5-5: Change request PDT
To test this PDT, create a test SRD to make sure the inputs and outputs function as
expected. See “Creating an SRD that tests the Change PDT” on page 171.

Incident request PDT

Add the information to the incident request PDT in the order listed in the table.

General Details Description area Enter required information Receives data input (Categorization
to complete the PDT (for Tier 1 and Summary) from service
example, request.
Incident_Mgt_PDT.
Process Details Visual Process Editor AOT Create one AOT and create one PDT
PDT below it—they run sequentially.
PDT receives input from AOT.
Process Details Define Properties panel AOT_IM Select AOT_IM and
Change_Mgt_PDT Change_Mgt_PDT from the Name
menu.
Process Details Define Variables panel imV1_opcat_input Create four variables that are used
imV1_opcat_output for input and output with AOT_IM.
imV1_summary_input
imV1_summary_output
Process Details Map Data Panel Operational Map input to output for AOT_IM.
Categorization Tier 1 The imV1_opcat_input and
field—Map imV1_summary_input variables
imV1_opcat_input as receive their input from the service
Input and request.
imV1_opcat_output as
Output
Summary field—Map
imV1_summary_input as
Input and
imV1_summary_output
as Output
Process Details Map Data Panel Map imV1_opcat_output Map input for Change_Mgt_PDT.
as Input. You only need to map input
Map variables:
imV1_summary_output imV1_opcat_output >
as Input. cmV1_opcat_input
imV1_summary_output >
cmV1_summary_input
Note: You do not need to map output
variables for this change
management PDT.

Dynamic data flow—mapping data between applications
Figure 5-6: Incident request PDT
After you learn about the function of SRDs in the application, you can link this PDT
to a standard SRD. See “About building SRDs that use dynamic data flow” on
page 171 and “Creating an SRD that uses the Incident PDT” on page 172.
Dynamic data flow—mapping data between

applications
When you set output variables from a fulfillment application, the value that is used
is the internal representation of the data. For example, if you retrieve data from a
selection field on the fulfillment application, the data that is stored is the selection
value (not the label). When you map this data to another fulfillment application, the
field in which the data is passed to interprets the data and shows the data, based
on the type of field you have mapped to.

The following example of a selection field clarifies how data is passed from one
fulfillment application to another fulfillment application. Imagine that your
application includes a Priority field with these selection labels and values:
Critical/1, High/2, Medium/3, Low/4.
If you mapped the data from this selection field to a character field on another
fulfillment application, you see the selection values (1, 2, 3, 4). In this case, the
data that appears is the internal representation of the data (not the selection
labels that appear).
If you mapped the data from this selection field to another selection field on the
fulfillment application (which contained the same labels and values), you see
the correct labels (Critical, High, Medium, Low).
If you mapped the data from this selection field to a date field on the fulfillment
application, the data appears as a date (most likely, an invalid date).
About building PDTs that use dynamic data

flow
The following scenario illustrates how to build PDTs that use dynamic data flow.
This simple scenario creates the following BMC Service Request Management
objects:
Two work order templates
One change management template
One incident management template
Four AOTs
Two PDTs
The following figure illustrates how these BMC Service Request Management
objects are used in the dynamic data flow. The Categorization Tier 1 value of a
service request (its “data”) serves as the input and output value for the fulfillment
applications.

About building PDTs that use dynamic data flow
Figure 5-7: Dynamic data flow from SRD to PDTs
SRD
DATA:
Category Tier 1
DATA
Incident_Mgt_PDT
AOT_IM:
Input/Output:
Category Tier 1
DATA
Change_Mgt_PDT
Input/Output:
Category Tier 1
DATA
Change_Mgt_PDT
AOT_CM:
Input/Output:
Category Tier 1
DATA
DATA
AOT_WO_1 AOT_WO2
Input: Input: Detailed
Description Description
DATA DATA
Dynamic data flow is useful when passing data between applications. For
example, the first part of the new employee process is an ID work order to your
Human Resources application. Human Resources types the new ID into a field in
the work order and marks it complete. Next, a new badge work order goes to
Security. The ID entered in the first work order is mapped to a field in the second
work order so that Security knows which employee ID the new badge is created
for.


Chapter
6 Creating service request

definitions
Before you can create service request definitions (SRDs), you must create an
application object template (AOT) for each step in a process and a process
definition template (PDT) for each process in a service request.
SRDs are created by the Service Catalog Manager to define service offerings, which
are communicated to users through the service catalog and shown on the Service
Request console.
NOTE
You must have the Service Catalog Manager permission to create SRDs.

Service request definition life cycle (page 110)
How SRDs are related to Atrium Service Catalog (page 111)
Creating SRDs—Overview (page 114)
System SRDs shipped with the application (page 115)
Creating a standard SRD with the Service Request Definition form (page 116)
Creating a quick launch SRD (page 123)
Adding a PDT to an SRD (page 125)
About adding questions and mapping variables and service request fields
(page 128)
Adding a service CI to an SRD (page 136)
Setting approvals for the service request (page 138)
Associating SRDs with packages (page 140)
Selecting entitlement information for an SRD (page 141)
Adding work information to SRDs (page 144)
Setting approvals for an SRD (page 146)
Defining service targets for an SRD (page 152)
Adding surveys to an SRD (page 156)
Managing SRDs (page 158)
Deploying SRDs (page 168)

About building SRDs that use dynamic data flow (page 171)
Miscellaneous configuration (page 173)
How activity log information is passed (page 184)
Viewing statistics of searched terms on the Request Entry console (page 184)
Setting Service Catalog Manager Console preferences (page 186)
Service request definition life cycle

The Service Catalog Manager Console contains a set of service request definitions
(SRDs) that define the business process for fulfilling the service. An SRD is a type
of service offering that is communicated to users through the Service Catalog
Manager Console. Each entry or record is a specific Service Catalog Manager
Console offering.
An SRD has various states to indicate its position in the life cycle. By default,
approval is required for certain state transitions, for example, to move an SRD
from Request for Approval to Deployed. Notifications might be sent at certain
points in its life cycle to alert users that certain events have occurred.
Generally, an SRD starts in Draft mode and becomes visible for selection by service
requesters when it is in Deployed state and within the specified effective dates.
After the end effective date, the Service Catalog Manager can re-enable the SRD by
resetting the effective dates. After an SRD is in Closed state, it cannot be deployed
and becomes inaccessible to the service requesters.
The following diagram shows the life cycle of an SRD entry. See “Deploying SRDs”
on page 168.

How SRDs are related to Atrium Service Catalog
Figure 6-1: SRD life cycle
How SRDs are related to Atrium Service

Catalog
When you create an SRD in BMC Service Request Management, the SRD is
translated to a requestable offering (RO) in Atrium Service Catalog. This makes
SRD information (and their relationship to services and service offerings) available
to other consumers. Users can browse the entire service catalog in one location.
An RO is part of a service offering (SO), which defines a specific agreement
between a service provider and a customer for a service. Each SO defines a level of
service for a price: it combines the service (utility), a service level target (warranty),
add-on options, and requestable offerings.

All technical and business services must have at least one service offering. For
example, an IT organization offers different service offerings, or levels, for a
database server (Gold, Silver, and Bronze) based on response times. Each SO also
costs a different amount based on the service level target. A customer selects
among the different database and operating system options for the service and
then selects the Silver offering, which has a service level target of a 10-minute
response.
Each SO can have one or more ROs. Like a service offering, an RO defines a specific
agreement between the provider and customer that combines the service (utility)
and a service level target (warranty) at a specified price or cost. The RO defines
what requests and transactions can be submitted about a service offering. These
might be requests to deliver or implement an instance of the service offering, or
they might be requests for changes, requests for fixing issues, and so on.
The Atrium Service Catalog has a hierarchy of services as shown in Figure 6-2.

How SRDs are related to Atrium Service Catalog
Figure 6-2: Example of a service model
Service: ERP
Service: ERP
Type: Business Type: Business
Service Offering Service Offering

Name: ERP – Silver Name: ERP – Gold
Requestable: No Requestable: Yes
Provider: IT Support Provider: IT Support
Desc: Med. Demand Service Desc: High Demand Service
Service Level Target Service Level Target
Type: Turnaround Type: Turnaround
Desc: 5 hours Desc: 2 hours
Type: Response Time Type: Response Time
Desc: 8 min 80% of time Desc: 5 min 80% of time
Type: Availability Type: Availability
Desc: 99.99% Desc: 99.999%
Req. Offering Req. Offering

Name: Reset Password Name: ERP Gold Service
Desc: Change password Desc: Provide ERP Gold
Provider: IT Support Provider: IT Support
Type: Turnaround Type: Turnaround
Target: 5 Days Target: 1 Day
Req. Offering
Requestable: Yes
Name: Reset Password
Provider: IT Support
Service Level Target
Type: Turnaround
Target: 1 hour
To summarize, the service model includes these elements:

Service (Business or Technical)—A high-level service that defines the “utility.”
A service is made up of service offerings.
Service level target (optional)—Target that defines the “warranty.” Targets
define the key performance indicators (KPIs) that measure the performance of a
service offering.
Service offering—A service that an IT organization makes available to its users.
Service offerings are associated with service levels (such as Gold, Silver, and
Bronze) and the warranty defined by those service levels. Aspects of a service
offering that can be requested by users are specified by delivery (one-time) and
transactional (ongoing) requestable offerings.

Requestable offering—An aspect of a service offering that can be requested by

users. BMC Cloud Service Management enables two general types of
requestable offerings:
Delivery requestable offerings, through which users request the
implementation of a service
Transactional requestable offerings, through which users request additional
functionality of a service.
Creating SRDs—Overview
To create SRDs, you must perform the following steps.

1 Use one of the following methods to create the SRD: “Managing SRDs” on page 158
Use the Service Request Definition form (the “traditional” “Using the Service Request Designer”
method). on page 189
Use the Service Request Designer.
Note: The Service Request Designer is a simple wizard that creates
basic SRDs, with minimal or no training required. Users can
make new services available in minutes., but you can still use
the “traditional” method to create SRDs.
2 Select one of the service request definition (SRD) types: “Creating a standard SRD with the
Standard SRD Service Request Definition form” on
Quick Launch SRD page 116
“Creating a quick launch SRD” on
Note: You cannot combine PDT and SRD types. For example, you page 123
must use a standard PDT with a standard SRD.
3 Add the PDT to the SRD. “Adding a standard process template to
an SRD” on page 125
Note: You cannot combine PDT and SRD types. For example, you
must use a standard PDT with a standard SRD. “Adding a quick launch process
template to an SRD” on page 127
4 Add questions, text, or service request fields to the SRD. “About adding questions and mapping
variables and service request fields” on
Note: This is not applicable for quick launch SRDs.
page 128
5 Set approvals for the service request. “Setting approvals for the service
request” on page 138
6 Add entitlements to the SRD. “Selecting entitlement information for
an SRD” on page 141
7 Add work information for the SRD. “Adding work information to SRDs” on
page 144
8 Define SRD approvals. “Setting approvals for an SRD” on
page 146
Note: This is not applicable for quick launch SRDs.
9 Define service targets for the SRD. “Defining service targets for an SRD” on
page 152
Note: Service targets are available only if you have BMC Service
Level Management installed.

System SRDs shipped with the application

10Add a business service to the SRD. “Adding a service CI to an SRD” on
page 136
11Add a survey to the SRD. “Adding surveys to an SRD” on
page 156
12Localize the SRD. “Localizing SRDs” on page 338
13Deploy the SRD to your user community. “Deploying SRDs” on page 168
The SRD automatically appears as a service in the Request Entry
console.
System SRDs shipped with the application

The application ships with three system SRDs to support the reverse creation of
service requests from fulfillment applications. Each SRD comes with its
corresponding system PDT and AOT. Without these PDTs and AOTs, the service
request cannot be created correctly.
SRD title SRD type PDT name AOT name

Work Order Work Order—The system SRD for Process Template Work Work Order
Request work orders is automatically installed Order
with the application.
Change Change Request—The system SRD for Process Template sample Change Sample
Request change requests is included with BMC Change
Remedy Change Management.
The system SRD for change requests is
installed only when BMC Remedy
Change Management is present.
Service Desk Incident—The system SRD for Process Template sample Incident Sample
Incident incidents is included with BMC Incident
Remedy Incident Management.
The system SRD for incidents is
installed only when BMC Remedy
Incident Management is present.
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.
NOTE
Summary records created for the BMC Remedy IT Service Management Requester
Console are automatically converted to SRDs when the application is installed.

The following fields on the system SRDs are locked and cannot be edited.
Field name on Service Characteristics

Request Definition form
Status The system SRD status is always Draft, so that it never
appears on the Request Entry console.
Description Includes 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 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 Cannot change the process.
tab)
Reopen Request The default setting of Reopen Fulfillment Process cannot
be changed.
Business Service (Definition Cannot add a business service.
tab) The name of this field is Business Service in Work Order
Management and Service in BMC Remedy Change
Management and in BMC Remedy Incident Management.
Approval Type (on the Specifies whether the request created from this SRD needs
Service Request tab) approval and who must approve the request.
Creating a standard SRD with the Service

Request Definition form
The standard SRD must include the following features:
Standard request type—The service catalog is typically a comprehensive set of
“requestable” standard services.
You can also create a quick launch SRD, which adds URLs to the catalog. This
type of SRD does not require approval. See “Creating a quick launch SRD” on
page 123.
Defined integration to the fulfillment application, such as a work order or a
change template.

Creating a standard SRD with the Service Request Definition form
Complete the information required on the Service Request Definition form to

submit it for approval. Bold field labels indicate that a value is required. However,
the more information you provide, the greater the chances are that the SRD will not
be rejected as pending further information.
IMPORTANT
For a complete list of steps to create an SRD, see “Creating SRDs—Overview” on
page 114.
To create a standard SRD

1 Open the IT Home Page, and select Service Request Management > Service
2 Click Console Focus in the left navigation pane, and click Request Definition.
3 Click Create in the Request Definition View in the Service Catalog Manager
Console.
NOTE
Some of the fields in the Service Request Definition form are prefilled—for
example, the Status is set to Draft. The Service Request Definition ID is generated
automatically when the SRD is saved.
In the Draft state, a yellow stoplight appears in the Service Request Definition form
above the Status field. The yellow stoplight alerts you that the SRD is pending (that
is, the SRD is not deployed or not online).
4 Complete the fields at the top of the window:
Field Name Description

Version (optional) Define the version level of the SRD, as you
manage the development, test, and production life cycle,
for example, 00.80 for Beta, or 01.00 for first roll out to
customers.
Company Specify the company the SRD is tied to. The user must
belong to this company to see the SRD. If the SRD is
Global, all users have access to it.
Note: If guest users must be able to access the SRD, select
Global.
Locale (optional) Specify the locale to deliver the SRD in the
language that is the most useful to your users.
You can deliver localized SRDs to different users,
simultaneously, in multiple languages with different
display properties.
See “Localizing SRDs” on page 338.


Title Enter a descriptive title for the SRD record.
If you want to enter the greater than (>) or less than (<)
sign in the Title field, use encoded text (&gt for >, and
&lt for <); otherwise, browsers will interpret the greater
than and less than signs as valid HTML markup if the
title is included in a URL.
Level (optional) Select the service level for the SRD, for example,
Gold, Silver, or Bronze. The SRM administrator
configures these levels for you. See “Defining service
targets for an SRD” on page 152.
Description Enter a detailed description of the SRD.
Note: Only 255 characters can be shown in the Request
Entry console. Any text greater than 255 character is
indicated by ellipsis points (...), although you cannot
access this text in the Console.
In addition, you can enter any value that can be read by a
browser. For example, you can enter the URL of your
company or the URL for a form on the web. The web
page, form, or interpreted code appears in the
Description field when requesters access the SRD.
For example, you could add the following Oracle®
JavaScript® snippet:
<a href="#" onClick="window.open('http://
www.bmc.com', 'win'); return false">
Keywords (optional) Enter aliases (keywords) used to search for
SRDs in the Request Entry console.
Requesters can enter these keywords when they search
for services in the Request Entry console.
Status The status is set to Draft.
Note: Leave the Status set to Draft until you are ready to
submit the SRD record for approval.
Status Reason (optional) Define why an SRD is in its state.
Status reasons are specific to the SRD state. For example,
the only choice you can enter if the SRD is in the Pending
state is More Information.
Leave this field blank until you are ready to submit the
SRD record for approval.


Instructions (optional) Enter any instructions that you want requesters
to view. Requesters see your text in the Provide
Information stage when they are requesting a service in
the Request Entry console.
You can enter any value that can be read by a browser.
For example, you can enter the URL of your company or
the URL for a form on the web. The web page, form, or
interpreted code appears in the Description field when
requesters access the SRD.
For example, you could add the following JavaScript
snippet:
Note: If you do not define any instructions in the SRD, the
Instructions field is not shown in the Request Entry
console.
Navigation Categories— Define the SRD record by selecting its Category 1 type,
Category 1 for example, Hardware.
Navigation Categories— (optional) Further define the SRD record by selecting
Category 2 category tiers 2 and 3.
and Category 3
5 Complete the fields on the Definition tab:
Section Field Name Description

SRD Details Request Type Select Standard.
The Standard request type must be linked to a standard
type PDT. A standard PDT contains processes that result
in the instantiation of fulfillment requests.
See “Creating a standard PDT” on page 91.
Advanced Interface Form (optional) Select an alternate set of questions to appear in
See “Adding an advanced interface form to an SRD” on
page 165.
Process Template (optional) Specify the PDT to include with the SRD. You
can also associate questions with the SRD.
Note: A standard SRD requires a standard PDT, and quick
launch SRD requires a quick launch PDT.
See the following sections:
“Adding a standard process template to an SRD” on
page 125
“Adding a quick launch process template to an SRD”
on page 127
“About adding questions and mapping variables and
service request fields” on page 128


SRD Details Reopen Request (optional) Select Reopen Fulfillment Process or Create
(continued) New Work Order.
Selecting Reopen Fulfillment Process:
Restarts the previous fulfillment process, if the
process resulted in only one process step, such as a
single incident or change request, that has not been
closed.
Creates a Work Order, if the process resulted in
multiple process steps, such as a combination of a
change request and a work order in sequence.
Selecting Create New Work Order always creates a
Work Order.
Expected Cost (optional) Cost budgeted for this SRD. Cost can be linked
to service targets.
Price (optional) Actual price of this SRD.
To select a currency other than the default currency that
appears in the Price field, select a currency from the Price
field’s drop-down list. This is the currency that appears
on the SRM Request Entry console and the service
request.
When a user submits a request from a Delivery SRD, the
service offering price is passed to the fulfillment
application. If the request is added to the cart or saved as
a draft, the administrator for the Atrium Service Catalog
can change the price in the Atrium Service Catalog, and
the price is reflected on the SRD. After the request is
submitted, the price can no longer be changed.
Note: For consistency, make sure that the currency for the
price in the SRD and the corresponding service offering
(in the Atrium Service Catalog) are the same. If service
requests in the cart on the Request Entry console are
shown with different currencies from each other, the
total price is calculated based on the currency ratios.
For information about configuring currency ratios, see
the BMC Remedy AR System Action Request System
Turnaround Time (optional) Define turnaround time for this SRD in Hours,
Days, Months, or Years. Turnaround time is used to
calculate the expected completion date of the SRD.
Note: To calculate the expected completion date
accurately, business hours and holidays must be
configured. For information about configuring
business hours and holidays, see “Configuring
business hours and holidays” on page 61.
Account Number (optional) Enter an account that this SRD will be billed
against, for example, Accounting or IT.


SRD Details System Request (optional) Select Yes to show this SRD as one of the System
(continued) Requests in the Request Entry console.
If you select Yes, the SRD becomes a “Popular Service”
on the Request Entry Console.
Request Catalog Company Select the catalog manager’s company from the list.
Manager You use this field with SRD approvals. See “Configuring
approvals” on page 217.
Name Select the catalog manager’s full name from the list.
You use this field with SRD approvals. See “Configuring
Effective Dates Start Date (optional) Enter the date that this SRD goes online.
and Times After the SRD is approved and deployed, it becomes
available online after the date you enter here. See
“Deploying SRDs” on page 168.
End Date (optional) Enter the date that this SRD is no longer
available.
The SRD record automatically changes to an Expired
Offering status after the end date is reached. You can
always reset this end date when it reaches the expired
state.
Customer First Name (optional) Use auto-fill to enter the SRD customer’s first
name.
Press ENTER to view additional information about the
customer.
Last Name (optional) Use auto-fill to enter the SRD customer’s last
name.
Press ENTER to view additional information about the
customer.
Service Catalog Service (optional) Select an Atrium Service Catalog service to
Information which you want to link the SRD.
Click the Search Catalog icon to open the Atrium Service
Catalog and create a new service.
Click the Search icon to open the CI Relationship Search
form, and search for a service.
If you do not select a service, the default global service is
applied after you save the SRD.
Note: When you create an SRD, a requestable offering is
automatically created in Atrium Service Catalog.
For more information, see “How SRDs are related to
Atrium Service Catalog” on page 111.


Service Catalog Service Offering (optional) Select an Atrium Service Catalog service
Information offering to which you want to link the SRD.
(continued) If you do not select a service and service offering, the
default global service and service offering are applied
after you save the SRD.
Offering Type Select the type of offering for the service:
Delivery—The SRD (Requestable Offering) is used to
activate the Service Offering (for example, initially
setting up the equipment to use a phone service). Users
pay an activation fee only once.
You can have only one Delivery SRD for each service
offering.
Transactional—An SRD (Requestable Offering) used
to make a request which is associated with a Service
Offering (for example, phone service, internet, and so
on), or an SRD used to make any other request.
You can have multiple Transactional SRDs for each
service offering.
Create Business Process (optional) Works with the Service field if you properly
configured the SRM Request Definition Settings form.
See “Defining service request definition settings” on
page 173.
If the Create Business Process check box is selected (the
default) and you have related a service CI to the SRD, the
SRD automatically creates the process that works with
the service CI.
6 Select a Process Template (PDT).

See “Adding a standard process template to an SRD” on page 125.
7 Map questions and variables to the SRD.
See “About adding questions and mapping variables and service request fields” on
page 128.
8 Click the Service Requests tab, and set the approvals for the service request that the
user will submit from this SRD.
See “Configuring approvals” on page 217.
9 (optional) Click the Entitlements tab, and set entitlements for the SRD.
See “Selecting entitlement information for an SRD” on page 141.
10 (optional) Click the Work Info tab, and enter work information for the SRD.
See “Adding work information to SRDs” on page 144.

Creating a quick launch SRD
11 (optional) Click the Approvals tab, and set approvals for the SRD.
See “Setting approvals for an SRD” on page 146.
12 Click Save.
The SRD is created in Draft status. You cannot move the SRD to a different state
(for example, Pending or Deployed) until you define a start date and the SRD is
approved.
Creating a quick launch SRD

You can create a quick launch SRD that opens a URL in another window. The
service request generated from a quick launch SRD does not require an approval,
unlike the other SRDs predefined in the service catalog.
During the definition phase, you associate a quick launch SRD with a quick launch
process definition template (PDT) that launches a URL in another window. You
might want to link to another site that also lets users make requests, such as a link
to your Human Resources intranet site or an outside financial services site where
employees can check their retirement accounts. Make sure you complete the
information required on the Service Request Definition form. Bold field labels
indicate that a value is required.
During the execution phase, this results in a “quick launch” service request when
the SRD is instantiated.
TIP
For a complete list of steps to create an SRD, see “Creating SRDs—Overview” on
page 114.
To create a quick launch SRD

The Request Definition View appears in the Service Catalog Manager Console.
3 Click Create.
The Service Request Definition form appears.
NOTE
Some of the fields are prefilled—for example, the Status is set to Draft. The Service
Request Definition ID is generated automatically when the SRD is saved.
In the Draft state, a yellow stoplight appears in the Service Request Definition form
above the Status field.
The yellow stoplight alerts you that the SRD is pending (that is, the SRD is not
deployed or not online).

4 Enter the following information:
Field name Description

Company Specify the company the SRD is tied to. The user must
belong to this company to see the SRD. If the SRD is
Global, all users have access to it.
Title Enter a descriptive title for the SRD record.
If you want to enter the greater than (>) or less than (<)
sign in the Title field, use encoded text (&gt for >, and
&lt for <); otherwise, browsers will interpret the greater
than and less than signs as valid HTML markup if the
title is included in a URL.
Description Enter a detailed description of the SRD.
In addition, you can enter any value that can be read by a
browser. For example, you can enter the URL of your
company or the URL for a form on the web. The web
page, form, or interpreted code appears in the
Description field when requesters access the SRD.
For example, you could add the following HTML
snippet:
<a href="http://www.bmc.com"
target="_blank">BMC</a>.
When embedding HTML, you must use the
target="_blank" code; otherwise, the link tries to
open inside the field but fails. Using the _blank targets
opens to a new window, outside the Request Entry
console.
Status The status is set to Draft.
Note: Leave the Status set to Draft until you are ready to
submit the SRD record for approval.
Navigation Categories— Define the SRD record by selecting its Category 1 type,
Category 1 for example, Hardware.
Request Type Select Quick Launch.
The Quick Launch request type must be linked to a Quick
Launch type PDT. A quick launch PDT contains an AOT
that points to a URL. It does not require approval to be
created by a requester.
See “Creating a quick launch PDT” on page 98.
Request Catalog Manager Select the catalog manager’s company from the list.
Company The contents of this field with SRD approvals. See
“Configuring approvals” on page 217.
Request Catalog Manager Enter the catalog manager’s full name.
Name You use this field with SRD approvals. See “Configuring
For information about the other fields at the top of the form and on the Definition
tab, see “To create a standard SRD” on page 117.

Adding a PDT to an SRD
5 Select a Process Template (PDT).

See “Adding a quick launch process template to an SRD” on page 127.
6 Click the Service Requests tab, and set the approvals for the service request that the
user will submit from this SRD.
7 (optional) Click the Entitlements tab, and set entitlements for the SRD.
See “Selecting entitlement information for an SRD” on page 141.
8 (optional) Click the Work Info tab, and enter work information for the SRD.
See “Adding work information to SRDs” on page 144.
9 (optional) Click the Approvals tab, and set approvals for the SRD.
See “Setting approvals for an SRD” on page 146.
10 Click Save.
The SRD is created in Draft status. You cannot move the SRD to a different state
(for example, Pending or Deployed) until you define a start date and the SRD is
approved.

When you create an SRD, you must associate one of the following types of PDTs to
is:
Standard (See “Adding a standard process template to an SRD” on page 125.)
Quick Launch (See “Adding a quick launch process template to an SRD” on
page 127.)
Adding a standard process template to an SRD

The PDT defines the business process for the service request definition. You must
associate the PDT with the service catalog record before it can be used to specify
dependency relationships. When a service request is submitted, the specified
relationship (between the catalog offering and the related backend templates)
determines which backend application requests are created and in what order. No
backend application requests are created if the service catalog does not have the
process template defined.
Use the Process Template field to associate a registered PDT instance or the Work
Order instance (for backend applications that are not using templates) to the SRD
record.

To add a standard process to an SRD

1 Open an SRD.
a Open the IT Home Page, and select Service Request Management > Service
b Click Console Focus in the left navigation pane, and click Request Definition.
c Perform an SRD search.
For types of searches you can use, see “Managing SRDs” on page 158.
d From the list of matching SRD records in the search results table, open the record
to modify.
2 Under the Process Template field, click Select.
3 From the list of available or registered process templates in the Service Request
Definition form, select one standard process to associate with this SRD entry.
You cannot select and add multiple processes to the SRD.
NOTE
PDTs must be active before you can select them.
4 Click Select, and then click Save.
Using the Visual Process Editor to view a process

template attached to the SRD
You can view process templates attached to the SRD with the Visual Process
Editor.
To view the process template attached to an SRD

1 Open an SRD.
to modify.
2 Under the Process Template field, click View.
The Visual Process Editor appears in read-only mode if the SRD is deployed and
online. If the SRD is offline or not yet deployed, you can modify the process objects.
Here you can view (and sometimes modify) the PDTs and the AOTs that are
instantiated with the SRD.

Figure 6-3: Visual Process Editor window
3 Click Close.
Adding a quick launch process template to an SRD

The PDT defines the quick launch process for an SRD. When a service request is
submitted, the specified relationship (between the catalog offering and the quick
launch PDT) determines which URL is launched.
To add a quick launch process to an SRD

1 Open an SRD.
c Perform an SRD search in the Request Definition View.
to modify.
2 Under the Process Template field, click Select.
The Service Request Definition dialog box for selecting quick launch PDTs
appears.

3 From the list of available or registered PDTs, select one process to associate to this
SRD.
You cannot select and add multiple processes to the SRD.
NOTE
PDTs must be active before you can select them.
4 Click Select.
The dialog box closes and the process appears in the Process Templates field.
5 Click Save.
6 To view the process, see “Using the Visual Process Editor to view a process
template attached to the SRD” on page 126.
About adding questions and mapping

variables and service request fields
The Question Management form enables you to add questions to the SRD and map
variables to the questions. Users are prompted to answer these questions when
they select this SRD in the Request Entry console. When they submit their service
request, their responses are pushed back to the fulfillment application. You can
associate an unlimited number of questions from the Questions Library to the SRD.
This list of questions is unique for each SRD.
In addition, the Question Management form shows you the list of process variables
for the SRD. You can map the source of the data for the variables (for example, a
question on the SRD or a field on the Service Request form). This form also shows
you a list of fields on the Service Request form to which you can map. The same
type of source data that was mapped for variables can be mapped to the service
request (SR) fields (for example, mapping a question response to a field on the
Service Request form).
NOTE
To associate questions to the SRD, you or your SRM administrator might have
configured questions as described in “Creating questions to use with SRDs” on
page 203. You can also dynamically add a question to the Questions Library. In the
Question Management form, click Add Question instead of selecting a question
from the Question Text list. When you create the new question, you can add it to
the Questions Library by clicking Update Library.

When a PDT uses an AOT, and then an SRD uses that PDT, the target data
associated with the AOT is rolled up to the variables on the PDT, and then to the
SRD. These are the variables mapped on the Question Management form for the
SRD. When the target data definition is changed at the AOT level, the rollup
automatically occurs at the PDT level but not at the SRD level. As a result, any
subsequent changes on the target data association at the AOT level requires you
reselect the PDT in the SRD and remap of the target data at the SRD level.
Adding questions to an SRD

The following procedure describes how to add questions to an SRD. The questions
you add here are available when you map variables.
For more information about creating questions, see “Creating questions to use
with SRDs” on page 203.
To add questions to an SRD

1 Open an SRD.
to modify.
2 After you enter a PDT in the Process Template field, click the Questions &
Mappings button under the Process Template field.
3 In the Question Management form, create questions to ask your users.
a Click Questions in the navigation tree.
b Click Add Question.
c Select New Question from the navigation tree.
d Define the Question Text.
Alternatively, you can select a question from the Select From Library list, and go
to step g. (For more information about creating questions in the Questions
Library, see “Creating questions to use with SRDs” on page 203.)
If you want to enter the greater than (>) or less than (<) sign in the Question Text
field, use encoded text (&gt for >, and &lt for <); otherwise, browsers will
question text is included in a URL.
e Select a question format (for example, Text or Menu).

f (optional) In the Category field, select or enter the category that the question will
be classified with.
NOTE
You can use this field to select or enter information to categorize questions in the
Questions Library. Then, you receive lists of questions by category instead of a
single long list of questions when you select a question from the library in the
Question Management form (which you can open from an SRD). You can
categorize questions for each fulfillment application or any other grouping that
works for your organization.
g Specify whether the question is Required or Hidden.

h Based on the question format, specify the question details.
For example, a Text question requires that you define the Default Response, the
Number of Text Rows, and the Limit Input Length.
i Click Apply to create your question.
j (optional) Click Add Condition to dynamically define additional questions that
appear in the context of the answer. (For more information, see “Adding branch
conditions to questions” on page 132.)
k (optional) Click Update Library to add the question to the Questions Library.
NOTE
When you add a question to the Questions Library, conditions added to the
question are not stored with the question in the Questions Library.
4 Specify the order in which the questions will appear in the SRD (when it appears
in the Request Entry console) by selecting the question and clicking the Up and
Down buttons.
5 To remove a question from the list of available questions, select it from the
navigation tree and click Delete.
6 To map variables to questions, click the Variable Mapping tab.
See “Mapping variables” on page 133.
7 To map questions to fields on the service request form, click the SR Field Mapping
tab.
See “Mapping service request fields” on page 135.

Restrictions in creating questions

Be aware of the following restrictions when creating questions.
Creating required or hidden questions—The question requirements must match
the data targets you map, as described in “Mapping variables” on page 133. For
example, because the Description field is required, the question should be
required as well.
When the user’s answer to a question is pushed to a required variable, specify
this question as required. For example, if you want a user to enter the urgency
of a change request, make sure to specify that Urgency question is required.
If a user ignores the question and submits the request, the fulfillment
application generates an error (which you must troubleshoot later).
If you hide the question, this option enables you to impact the fulfillment
process, without requiring any response from the user. Hidden fields work in
the following ways:
The question and response are visible in the Request Details of the service
request, but are not visible to the average user.
The question and response do not show up in the Summary view in the
Request Entry console.
If you hide the question, make sure that you enter a default response.
Do not hide Date/Time, Date, or Time fields.
Entering default values—Creating a default value overrides any defaults your
SRM administrator had previously configured.
Be careful about the variables that are exposed to users. An attempt to create a
work order from the SRD will fail if a user enters the wrong values, for example,
the Priority field in a work order has a value other than Critical, High, Medium, or
Low.
WARNING
To prevent CAI mapping errors on text questions, determine the right value to
enter in the Limit Input Length field to on the Question Management form. If you
are passing the values from a text question from BMC Service Request
Management to a fulfillment application (for example, BMC Remedy Incident
Management), make sure you set the proper field length values. Otherwise, errors
might appear in the CAI events trying to create records in the fulfillment
applications, because data from one of the fields in the service request is too long
(for example, trying to pass 128 characters to a field that only accepts 100
characters).

Adding branch conditions to questions

Based on how users answer a question, you can add branch conditions to an
additional set of questions. For example, if your Level 1 question format is a radio
button with values of Laptop, Desktop, or Server, and a user selects Server, you can
ask additional questions (Level 2 questions).
Laptop (Level 1 Question)
Desktop (Level 1 Question)
Server (Level 1 Question)
Linux (Level 2 Question)
UNIX® (Level 2 Question)
Windows (Level 2 Question)
You can create branch conditions for radio buttons, check boxes, and static menus.
These question formats provide a table for you to select which question triggers the
condition. (You cannot create branch conditions for text, date/time, range, or
query menus.)
NOTE
Only one level of conditional questions is supported. If the question uses check
boxes, you can have a condition for single or multiple check box options. For
multiple options, you must specify each combination as a separate condition.
To add branch conditions to questions

1 On the Questions tab of the Question Management form, select a Level 1 question
(for example, a radio button question with the values of Laptop, Desktop, and
Server).
2 Click Add Condition.
3 In the navigation tree, select New Condition to create the branch condition.
4 Select the value from the condition table (for example, Laptop).
5 Click Apply.
The condition is renamed in the navigation tree.
6 Continue these steps until you have created your conditions for other values (for
example, Desktop and Server).
7 After you create your branch conditions, select the condition from the navigation
tree (for example, Server), and click Add Question.
This action creates a New Condition Question record under the condition record
in the navigation tree.

Mapping variables
This section describes how to map variables to the questions that you added to the
SRD.
You can map multiple questions to the same variable. For example, the user’s
answer in the Description field on the Request Entry console can be pushed to the
Description field data target in the Change Management, Incident Management,
and Work Orders fulfillment templates.
To map variables to questions you defined for the SRD

1 On the Question Management form, click the Variable Mapping tab.
2 Select one of the variables.
3 In the Mapping Details area, complete one of the following steps:
Select the Question option, and choose one of the questions you previously
defined.
Make sure that the available questions you select will map to the intended data
targets. For example, the question (“What kind of chair do you want?”)
corresponds to the Description data target. If not, you must create a question.
Specify whether the question must be answered by the answer (select User
Displayed Response) or the data is internal (select Internally Represented
Response). To understand the restrictions for these options, see “Question
format restrictions” on page 134.
Select the Text option, and enter the text that you want entered in the
corresponding field in the fulfillment application.
When entering a string in the Text field, do not use quotation marks; otherwise,
no text will appear in the Service Request form, and the data will not be pushed
to fulfillment application. (This occurs because of the way quotation marks are
used in the workflow that parses the mapping.)
Select the SR Field option, and select a field from the SR Field list.
Click Advanced Mappings to concatenate multiple inputs.
You might select this option if you want to map multiple questions to the same
variable. For example, the user’s answer in the Description field on the Request
Entry console can be pushed to the Description field data target in the Change
Management, Incident Management, and Work Orders fulfillment templates.
(See “Concatenating multiple inputs” on page 135.)
4 Click Apply.
5 Map other variables as needed.
6 Close the Question Management form.
7 Save the SRD.

Question format restrictions

The following table shows the question format restrictions that apply when you
are mapping data. You can map question data as follows:
User Displayed Response—User enters answer to the question from the Provide
Information panel on the Request Entry console as input.
Internally Represented Response—Data is passed internally as input (the stored
values or BMC Remedy AR System internal representation for Date, Time, or
Date/Time fields).
Either—Both User Displayed Response or Internally Represented Response
options map data correctly to the fulfillment application.
Question format Fulfillment field type How to map data (User Comments
Displayed, Internally
Represented Response, or
Either)
Text Character Either Either choice maps data
correctly.
Radio Button, Character User Displayed Response
Check Box, Static Selection Field Internally Represented When the internal value is used,
Menu Response the Stored Values defined for
the question is passed to the
fulfillment application. The
stored values must match those
of the selection field on the
fulfillment form.
Query Menu Character Either
Date Date Internally Represented
Response
Character User Displayed Response
Date/Time Not applicable Not supported
Time Not applicable Not supported
Date/Time Date/Time Internally Represented
Response
Date
Time Time Internally Represented
Response
Range Character Either
Integer Either

Mapping service request fields

This section describes how to map data to fields on the service request form.
(Mapping data to the service request form is optional.)
To map service request fields

1 On the Question Management form, click the SR Field Mapping tab.
2 Select one of the fields.
3 In the Mapping Details area, select one of the following options:
defined.
Make sure that the available questions you select will map to the intended data
targets. For example, the question (“What kind of chair do you want?”)
When entering a string in the Text field, do not use quotation marks; otherwise,
no text will appear in the Service Request form, and the data will not be pushed
to fulfillment application. (This occurs because of the way quotation marks are
used in the workflow that parses the mapping.)
Click Advanced Mapping to concatenate data into one SR field. (See
“Concatenating multiple inputs” on page 135.)
4 Click Apply.
5 Map other fields as needed.
7 Save the SRD.
Concatenating multiple inputs

On the Variable Mapping tab and the SR Field Mapping tab, you can concatenate
multiple inputs (for example, questions, text, or values from service request fields)
to the same variable or a field on the Service Request form. You would do this primarily
if you needed to piece together the user’s response into one data target. For
example, you can concatenate three questions to one variable, or concatenate
values from several SR fields into one SR field.

Several advanced options are available for mapping the source of the value.
Question—Value comes from a question response.
Text—You can map text as the source of the data for the target data items. You
must enter a default value.
SR Fields—You can map service request fields on the Service Requests form as
the source of the data. For example, this functionality is useful if you wanted to
push the quantity and total price of a service request to a work order.
You also use this functionality with advanced interface forms. See “Creating and
using advanced interface forms” on page 345.
Line Break—Adds a line break to the mapping.
To concatenate multiple inputs

1 On the Question Management form, click the Variable Mapping tab or SR Field
Mapping tab.
2 Select one of the variables or fields.
3 In the Mapping Details area, click Advanced Mapping, or click Edit (if you selected
a mapped variable.
4 In the Edit Advanced Mapping dialog box, combine questions, text, and service
request fields for the mapping.
a Select a question, text, SR Field, or Line Break.
b Click Add to Mapping.
c Add another question, text, SR Field, or Line Break.
d If you make a mistake, click Clear to start over.
5 Click Apply.
6 Click Save.
8 Save the SRD.
Adding a service CI to an SRD

A configuration item (CI) in the Atrium Service Catalog is an instance of an entity
that is part of your environment and has configurable attributes specific to that
instance. These entities can be physical (such as a computer system), logical (such
as an installed instance of a software program), or conceptual (such as a service).
When you create an SRD, you can integrate it with a service CI that is part of your
environment and has configurable attributes, such as criticality to the business and
the cost of interruption of service. For example, if you are creating an SRD for new
employees, you would need business services that create passwords, purchase
new hardware and software, provide network access, and so on.

Adding a service CI to an SRD
NOTE
The service that a requester selects in response to a question takes precedence over
a service specified in the Work Order template or in the SRD. (The service specified
in the SRD takes precedence over a service specified in a Work Order template.)
To pass the service as a user’s response to backend application entries, you must:
Include the following target data in the application object template:
Business Service (for Work Order) or Service CI (for Incident and Change)
CI_ReconID
Define variables to the target data on the PDT.
Create a question on the SRD.
Create a query menu based on the BMC.CORE:BMC_BusinessService form.
Select Name for Display Label and ReconciliationIdentify for Actual Value.
Map the question to the variable for Business Service or Service CI as User
Displayed Response.
Map the same question to the variable for CI_ReconID as Internally
Represented Response.
Selecting service CIs for an SRD

This section provides detailed instructions about searching for configuration items
and relating them to an SRD.
To select CIs for an SRD

1 Open an SRD.
to modify.
2 Click the Search button next to the Service field.
3 Complete the search criteria tabs on the CI Relationship Search form, and click
Search icon.
Search results appear in the table.

4 Select a CI from the search results table, and click Select.

The CI Relationships Search form closes, and the name of the CI appears in the
Service field.
5 Select the Create Business Process check box (selected by default) if you want the
SRD to automatically create the business process that works with the business
service CI.
Otherwise, clear the Create Business Process check box.
This action works only if the Service Request Definition Settings form is properly
configured. See “Defining service request definition settings” on page 173.
Setting approvals for the service request

On the Service Request Definition form, you can set the approvals required for the
service request that a user submits.
To set approvals for the service request

1 Configure the approvals for BMC Service Request Management.
2 Open an SRD.
to modify.
3 Click the Service Request tab.

Setting approvals for the service request
4 From the Approval Type list, select one of the following options:
None—No approval chain record is associated with the service request when it
is submitted.
Manager—Enables you to specify how high you want to go in the management
approval chain. For example, if you use 1 (the system default), the chain extends
only to the user’s manager. If you enter 2, the next level in the management
chain must approve the upgrade, and so on. The maximum number of approval
levels is 5.
When you select Person, an Assignment Option field appears with a Use
Request Manager check box. If you select the check box, any ad hoc approval
process associated with the SRD uses the requester’s manager as the first
approver, instead of the named person. This functionality requires the
requester’s manager to be defined in the requester’s People record.
Person—Enables you to send the service request for approval to any user
defined in the People form. Click Select to search for any user available in the
People form.
Group—Enables you to send the service request for approval only to group
members with Request Approver roles.
Custom—Enables you to use a custom approval chain (not one of the approval
chains installed with the application). This custom approval chain definition
must have a Selection Criteria that matches the requestable service. For
information, see “Approvals for service requests” on page 219.
When you select Custom, an Assignment Option field appears with a Use
Request Manager check box. If you select the check box, any ad hoc approval
process associated with the SRD uses the requester’s manager as the first
approver. This functionality requires the requester’s manager to be defined in
the requester’s People record.
5 Click Save.

Associating SRDs with packages

To organize SRDs, you can group them into a “package” and create an entitlement
rule for that package. This is useful when you use multi-tenancy, where you are
managing SRDs for more than one company.
For more information about entitlement and packages, see “Configuring packages
and entitlements” on page 239.
To associate an SRD with a package

1 Open the SRD.
to modify.
2 Click the Package tab.
Packages that are related to the Company for this SRD are listed in the Available
Packages table.
3 To filter the packages listed in the Available Packages table, enter a term (from the
package name) in the Search field, and press Enter.
4 To associate a package, select it from the Available Packages table, and click Add.
You can also drag packages from the Available Packages table to the Associated
Packages table.
5 To view a package, double-click it.
6 Click Save.

Selecting entitlement information for an SRD

The service request catalog provides flexible entitlement control. Users can view
and create only the services they are entitled to receive. For example, you could
create an entitlement that any employee in the sales division, as negotiated under
the employee’s contract, has access to both silver and gold levels of service for a
specific request.
In general, configuring entitlements depends on the user, role, group, location,
categorization, and service level (gold, silver, bronze, and so on) attributes. Any
combination of these attributes can be required to determine if a user can view and
access the SRD. Users with “on behalf of” permission for another user can see all
the SRDs that the other user is entitled to. You can also attach People entitlements
to a particular SRD. For example, the “Purchase an iPhone” SRD applies only to
the Executive Management or the Technical Writers group.
You can manage entitlements independently of a specific SRD so that you can
easily handle any “global” entitlements.
You can also specify the services that users are entitled to receive based on their
location. For example, you might specify that all Service Catalog Managers are
entitled to the IT request category, except those in the Hong Kong location. Another
example of entitlement based on location is that you could specify that all users in
the Paris location are entitled to the French retirement category of requests.
Guest users can select generic services for which guests are entitled.
To add entitlements to your SRD, entitlement definitions for people and SRDs
must first be configured. See “Configuring packages and entitlements” on
page 239.
To select entitlement information for an SRD

1 Open an SRD.
to modify.
2 Make sure that the status of the SRD is offline.
You cannot add entitlements to SRDs that are online. For information, see “Taking
an SRD offline” on page 169.
3 Click the Entitlements tab.
4 If you are creating an SRD, click Refresh to make any default entitlements appear.

5 Click Add New Rule or Modify.

The Entitlement Rule dialog box appears.
6 To create an entitlement rule, perform the following steps:
a Select the people qualification.
NOTE
The content of the SRD Qualification Name field is preselected and cannot be
modified. To define an entitlement rule with a more generic SRD qualification, the
Service Catalog Manager must have access to the Entitlement Management option
in the Application Administration Console. See “Configuring packages and
entitlements” on page 239.
b (optional) Select the Exclusion Rule check box.

You use this Exclusion Rule check box to deliberately prevent groups or persons
from accessing the SRD. Otherwise, you are assuming that the groups or
persons you select are entitled to use the SRD.
For example, to specify that EMEA (Europe, Middle East, and Asia) can use the
current SRD, you would select or create Location – EMEA rule as the People
Qualification, and then you would not click the Exclusion Rule check box.
c Click Save.
7 Save the changes to your SRD.
The rule appears in the Entitlement Rules table.
8 If you are modifying an SRD, return the SRD to online mode.
Modifying entitlement rules

You can view the entitlement rules as needed.
NOTE
To modify an entitlement rule, you must have access to the Entitlement
Management option through the Application Administration Console.
To modify entitlement rules

1 Open an SRD.


to modify.
2 Change the status of the SRD to Offline.
You cannot add entitlements to SRDs that are online.
4 Click Modify.
5 In the Entitlement Rule dialog box, view the People and SRD qualifications as
needed.
6 Close the Entitlement Rule dialog box, and return the SRD to online mode.
Creating People qualifications

You can further qualify which People groups can view entitlements. For example,
you can create an entitlement that the Software Group in Northern California is
entitled to view the SRD. You can even create an SRD that one person is entitled to
view, for example, the CEO of your company.
To create People qualifications

1 Open an SRD.
to modify.
3 Click Add New Rule.
4 Under the People Qualification Name field on the Entitlement Rule dialog box,
click View or Create.

5 In the People Qualification for Entitlement form, create or edit the following
People qualifications:
Name Description
Company Entitles one specific company to view the SRD.
AR Username Entitles one person to view the SRD.
Click the Add button to open the People Search form. Select
the appropriate user record, and click Select.
Entitlement Group Entitles one specific group to view the SRD.
Location Entitles a specific location to view the SRD, defined by any
combination of region (North America), site group (Northern
California), or site (Sunnyvale).
Advanced Qualification Enables you to define an advanced entitlement qualification.
When you select this option, the Advanced Qualification
Builder appears. Select field names by clicking either the
Fields From or the Fields From Current Form buttons, and
selecting from the list. Select a qualifier, type in the
Qualification field to add values, and then click Select.
You can pick only one option from the People Qualification Definition form.
6 (optional) Click the System Details button to view read-only information about the
creator of the entitlement and when it was created.
7 Click Save.
Adding work information to SRDs

You can add work information to an SRD. The work information appears in the
Work Info tab on the Service Request Definition form. Use this feature to add work
information regarding tasks performed on the SRD. For example, you can track an
SRD’s progress by recording the steps you took to implement it in the work
history.
To add work information to an SRD
1 Open an SRD.
to modify.
2 Click the Work Info tab.

Adding work information to SRDs
3 (optional) Modify the work information type.

4 From the Source list, select the source of this information.
Information sources can include, for example, email, system assignment, or the
Web.
5 Enter the details of your work information record in the Date, Summary, and Work
Info Notes fields.
6 To add attachments to the entry, click Add.
See “Adding attachments to a Work Info entry that is attached to an SRD” on
page 145.
7 From the Locked list, select Yes or No to lock the log.
8 Select the view access:
Internal enables only users in your organization to see the entry.
External enables everyone with access to the system to see the entry.
9 When you have finished updating, save your changes.
The Save operation adds your entry to the SRD’s work history. The Show field
enables you to filter specific work entries based on the type of activity that appear
in the table.
10 To see a report of the activities you performed against this SRD, click Report.
11 To see all entries for work information history, click View.
12 Save the SRD.
Adding attachments to a Work Info entry that is attached to an SRD

The following procedure describes how to use a browser client to add an
attachment to a Work Info entry that is attached to an SRD. The steps for using a
browser client to add attachments are slightly different from the steps for using
BMC Remedy User.
To add attachments to a Work Info entry that is attached to an SRD

1 Open an SRD.
to modify.


Use this tab to enter, view, or delete any attachments for this SRD.
3 To add an attachment:
a Click Add.
b Browse to the document to attach, and click OK to add the attachment to the
SRD entry.
You can add a maximum of three attachments.
4 To view an attachment:
a Select the attachment from the Attachment table, and click Display.
b Select the attachment and open it. You can also save it to your computer before
opening it.
c View the attachment and close it when you are finished.
5 To delete an attachment, select it from the Attachment table, and click Delete.
6 Save the SRD.
Setting approvals for an SRD

On the Service Request Definition form, you can set the approvals required for the
SRD before it is deployed. If you do not set approvers for an SRD, it is
automatically deployed.
When the SRD approval process (Service Request Definition - Ad Hoc) is enabled,
by default the Service Catalog Managers approve any SRDs they are responsible
for. BMC Service Request Management is fully integrated with the BMC Remedy
Approval Server for business, technical, and financial approvals.
See the BMC Remedy Action Request System BMC Remedy Approval Server Guide.
Defining SRD approvals

The approval engine determines the list of SRD approvers—by default, the Service
Catalog Manager must approve the SRD when it moves to the Request for
Approval state.
The Service Catalog Manager can also define additional approvers who must
approve the SRD before it can be deployed. For example, you can specify that the
customer must first review and approve the SRD before it is deployed to the
organization.
NOTE
For information about SRD approvals if you disabled the Service Request
Definition - Ad Hoc process and activated the Service Request Definition - Level
process, see “Creating individual mappings to work with level-type approval
processes” on page 225.

To define SRD approvals

1 Configure the approvals for BMC Service Request Management.
2 Open an SRD.
to modify.
3 Click the Approvals tab.
4 Specify if you want the approval engine to determine the approvers list.
This is the default setting.
The SRM administrator can choose to bypass the approval server in the Service
Request Definition Settings configuration form. See “Defining service request
definition settings” on page 173.
5 To include an individual approver in the Approvers list, select the Individuals
check box, and select any combination of Customer, Catalog Manager, or Service
Request Coordinator.
Here you are defining whether the Customer, Service Catalog Manager, or Service
Request Coordinator must approve the SRD before it can be deployed.
For the Customer required to approve the SRD, see the Definition tab of the
SRD.
For the Catalog Manager required to approve the SRD, see the Definition tab of
the SRD.
NOTE
If the name of the Request Catalog Manager on the Definition tab is the same as the
creator of this SRD, only one approval signature is created. Multiple signatures are
not required.
For the Service Request Coordinator required to approve the SRD, see the
Coordinator Company and Coordinator Group defined in the Service Request
tab of the SRD.
The following example illustrates how you can add a customer to the approval
list. This individual must approve the SRD before it can be deployed.

Figure 6-4: Customer added to approve SRD
6 To add an ad hoc approver, perform the following actions:

a Click Add.
b In the Add Approvers dialog box, specify an individual or group.
c Enter the full name of the individual or group.
d Click Save.
The Add Approvers dialog box is closed and you return to the Service Request
Definition form.
e Click Refresh.
The individual or group is added to the approvers list.
7 Save your changes to the SRD.
8 To view approvers by the SRD approval state, select an approval state from the
Show menu, for example, Pending.
The Approvers list then refreshes with the current list of approvers who must
approve the SRD before it can be moved to the next approval state.
NOTE
Adding an individual or ad hoc approver causes the Set using Approval Engine
flag to be set, and the approval engine will be used to determine any additional
approvers.

Adding alternate approvers

From the Alternate Approvers tab of the People form, the Service Catalog Manager
can add people to approve SRDs that are pending your approval (for example, to
add another Service Catalog Manager as an alternate approver while you are on
vacation).
NOTE
You can only configure alternate approvers for yourself.
To add alternate approvers for people

tab.
2 From the Application Settings list, choose Foundation > People > People, and click
Open.
3 From the People form, search for yourself.
4 Select your record, and click the Alternate Approvers tab.
5 Click Update Alternate Approvers.
6 To locate the alternate approver, click Search from the The Alternate Approvers
form.
7 In the People Search form, select the alternate approver, and click Select.
8 Enter the start date and the end date.
9 In the Notify Alternate field, select whether to notify the alternate approver.
10 In the Covering field, select whether this is an alternate for all approvals or only
for a specific process.
11 If you selected Specific Process in the Covering field, select the applicable process
in the Process field.
12 Click Add.
Submitting SRDs for approval

Before submitting the SRD record for approval, make sure that it contains all the
required information. You cannot modify the SRD after the approval process
begins.
To submit an SRD for approval

1 Search for any records that are in draft mode:
a Open the Service Catalog Manager Console.
b Select Draft from the Status field.
c Enter any optional search criteria.
d Click Search.

2 Select the SRD and click View.

The SRD appears in the Service Request Definition form.
3 To start the approval process, change the SRD’s status to Request for Approval.
The Cancel Approval button appears in the Service Request Definition form next
to the Status field. The yellow stoplight alerts the Service Catalog Manager that the
SRD is not yet online.
4 Click Save.
Viewing the approval process

You can view the approvers for a service catalog category and the approval
process before the record is approved.
If there are multiple approvers and levels of approvers, the SRD’s offering status
does not change to Approved until all the approvers have approved it.
However, you can view the Approvers tab for the SRD record and see where it is
in the approval process.
To view the approval process

3 Search for an SRD.
See “Managing SRDs” on page 158.
a From the Status menu, select the Request for Approvals state.
b Click Search.
A list of SRDs that are pending approvals appears.
4 Select the SRD from the Search Results table, and click View.
5 Click the Approvals tab.
A list of the approvers required to approve the SRD appears.
Approving SRDs
By default, the Service Catalog Manager approves (or rejects) SRDs. When an SRD
moves from the Draft state to Request for Approval, the Service Catalog Manager
must approve it before it can move to the Deployed state, so that users can access
it to request services.
If the Service Request Definition - Level process is enabled and the Service Request
Definition - Ad Hoc process is disabled, you must configure approver mappings
with a specific company, categories, and phase.

NOTE
By default, an SRD requires approval by a Service Catalog Manager who has the
functional role of the SRD Approver assigned to the SRD.
By default, SRDs require approval by the Service Catalog Manager who created
them. This requirement is defined in the SRD:ServiceRequestDefinition form for
the Service Request Definition - Ad Hoc process.
To approve SRDs by using the Service Catalog Manager Console

2 Perform one of the following actions:
In the left navigation pane, choose Console View > Needs My Approval.
Enter search criteria (for example, all SRDs with Request for Approval status)
and click Search.
Requests needing your approval appear in the search results table.
3 Select an SRD, and click Approve or Reject.
When you refresh the table, the SRD you just approved no longer appears. In
addition, the SRD automatically moves to the Deployed state (if the default
approval process configuration record for SRDs is enabled).
4 Search for the SRD you just approved.
The Take Offline button and the green stoplight appear in the Service Request
Definition form above the Status field.
The green stoplight alerts you that the SRD was deployed and users can access it
in the Request Entry console.
WARNING
If you take the SRD offline and then modify it, the SRD does not require additional
approval for redeployment. If you make major changes to the SRD’s functionality,
the SRD cannot be submitted for re-approval.
To approve SRDs by using the Approval Console

2 In the left navigation pane, choose Other Applications > Approval Console.

3 In the Approval Console, enter search criteria (for example, who you are acting on
behalf of) and click Search.
Requests needing your approval appear in the Approval Requests table.
4 Select the approval request, and click Approve or Reject.
The SRD is automatically set to the Deployed state. The SRD is available to users
from the catalog. Users can view the service request definition in the Request Entry
console and browse or search for it.
Defining service targets for an SRD

BMC Service Level Management can set goals and monitor service requests to
make sure that the correct level of service is being provided. You can set optional
milestones and related actions to make sure that the goals are met.
IMPORTANT
This option is available only if you have BMC Service Level Management installed.
The Service Catalog Manager must have SLM Manager or SLM Config
permissions to access the Service Target Wizard.
See also “Configuring service targets” on page 155.
To create a service target for an SRD

1 Open an SRD.
to modify.
To create a new SRD, see “Creating a standard SRD with the Service Request
Definition form” on page 116 or “Creating a quick launch SRD” on page 123.
2 Click the SLM tab.

3 Select a goal from the Goal list.

The Goal list contains a selection of predefined templates for service targets that
define specific goals.
The options are:
Service Request Total Time—This goal sets a time to complete the request after
it is submitted.
Service Request Process Time—This goal sets a time to complete the request
after it is approved.
Service Request Approval Time—This goal sets a time to approve the request
after it is submitted.
4 Click Create.
The Service Target Wizard appears.
Some fields in the Step 1 tab are automatically filled; for others, you can enter or
change the criteria.

Title The title assigned to the service target. The title consists of the SRD
number -Service Request title- SLM ID number.
Description Enter an optional description of what the service target does.
Goal Type The goal type you selected in step 3 on page 153.
Goal and Cost
Hours The number of hours and minutes before the service target is
Minutes considered “missed.”
Business Schedules
Business Entity Select a business entity that specifies the times when you do not
want the service target to be measured, for example, during a
holiday when the company is shut down.
5 Click Next to move to Step 2.

In Step 2, you can create milestones and actions that will ensure that your service
target meets its goal. For example, if 75 percent of the time has elapsed and the
request is incomplete, you can send a reminder to the manager.
6 To select a milestone, click Add beneath the Milestones table.
7 In the Create New Milestone dialog box, select a milestone (for example, Service
Request - 100% of goal) and click OK.
The milestone is listed in the Milestones table.
8 To select the action that occurs at the selected milestone, click Add (below the
Actions table).
9 Create New Action dialog box, select an action (for example, Service Request warn
request manager) and click OK.
The action is listed in the Actions table.

10 Select more milestones and actions if applicable.

11 Click Finish.
A dialog box appears, asking if you want to build the rules for the service target.
This creates the workflow so that the service target can be deployed.
12 Click an option to build the rules. You have the following choices:
Yes—The application builds the rules immediately.
No—The application does not build the rules at this time. You can build the
rules later by opening the SLM console at the Service Targets tab. The service
target that was not built is listed with a build status of “Needs to be Built.” Select
your service target and click the Build button.
After the rules are built, your service target is created and associated with your
SRD.
13 Click Refresh to view service targets in the Current Service Targets table that are
associated with the service request.
14 Save your service request and associated service targets.
Associating service targets with an SRD

Click the Advanced link on the Service Levels tab if you are familiar with the BMC
SLM application and want to create custom or complex service targets. This link
opens the SLM Console and is enabled only if you have the following permissions:
SLM Config
SLM Manager
SLM Unrestricted Manager
Associating a service target with an SRD

1 Open an SRD.
to modify.
To create a new SRD, see “Creating a standard SRD with the Service Request
Definition form” on page 116 or “Creating a quick launch SRD” on page 123.
2 Click the SLM tab.

3 Click Relate.
4 In the Searching for Service Targets form enter the search criteria to retrieve the
service target, and click Search.
The service targets are listed in the Search Results column.
5 Select the service target and click Relate Selected Record.
The service target is listed in the Current Service Targets table on the Service Levels
tab.
You can relate multiple service targets to a single SRD.
6 Save your SRD.
For more information about the subsequent flow for the service request, see
“Service request definition life cycle” on page 110.
For more information about creating templates and business entities, see the
BMC Service Level Management Configuration Guide.
For more information about creating service targets and creating agreements,
see the BMC Service Level Management User’s Guide.
Configuring service targets

If you have BMC Service Level Management installed, you can use the three goals
for service targets, which are shipped with the BMC Service Request Management
application:
Service Request Total Time—This goal sets a time to complete the request after
it is submitted.
Service Request Process Time—This goal sets a time to complete the request
after it is approved.
Service Request Approval Time—This goal sets a time to approve the request
after it is submitted.
These goals have been created in the BMC Service Request Management
application as templates. You can override any of these settings using the
Configure Service Target Defaults form.
To configure service targets defaults

tab.
2 From the Applications Settings list, choose Service Request Management > Service
Level Management > Service Target Defaults, and click Open.

3 From the Configure Service Target Defaults form, you can customize the service
targets by selecting a service target and entering information in the following
optional fields:
Field Description
Applies To The application that the service target applies to, in this case it
is Service Request.
Goal Type Select from the BMC Service Request Management goal types
that are shipped with the application:
Service Request Approval Time
Service Request Process Time
Service Request Total Time
Status Select the status of the service target:
Enabled—The service target is saved.
Disabled—The service target cannot be attached to any new
requests; however, the measurements continue for any
exiting requests.
Invalid—The service target is no longer in operation.
Hours The time in which the request must have a response. After this
Minutes time the service target is considered missed.
Impact Cost The estimated costs per minute to the business if the service
target is missed.
Business Entity The periods when the service target measurements are
suspended (for example, during a holiday when the company
is closed).
Measurement Template Predefined templates that specify when the measurements
start and finish.
4 Click Save.
For more information about creating templates and business entities, see the
BMC Service Level Management Configuration Guide.
For more information about creating service targets, see the BMC Service Level
Adding surveys to an SRD

Use the Search for Surveys form to select survey questions for your requesters.
Surveys give the Service Catalog Manager or Business Analyst an indication of
customer satisfaction levels and how the service desk is performing.
NOTE
You can add a survey to the SRD only if surveys are enabled in the Request
Preferences form. See “Defining behavior rules for surveys” on page 177.

Adding surveys to an SRD
To select surveys
1 Open an SRD.
to modify.
If a default survey was created, its name appears.
3 To exclude a survey from this SRD, select Disabled from the Status menu.
4 To create a custom survey for this SRD, select Custom from the Configuration
field.
Otherwise, the default survey is included with the SRD.
5 Click Select.
6 In the Search Survey form, select the company to which this survey applies, or
select Global to make this survey available to all companies.
7 To create a survey, click Create.
8 In the Configure Survey form, enter a name for your survey.
9 Click Save.
The dialog box closes and you are returned to the Search Survey form.
10 Click Manage Questions.
The Manage Questions form appears.
11 To create or modify questions in your survey:
a Specify a locale, if your questions must be localized, for example, en_US.
b Specify the numerical sequence, for example, 1.
c Define the question.
d Click Add or Modify.

Managing SRDs
Service Catalog Managers use the Service Request Definition form to manage an
SRD and track its progress from Draft to Deployed. You can use this form to
associate the SRD with PDTs, business service CIs, approvals, and service targets.
Before you begin searching, creating, or modifying information in the Service
Request Definition form, you must understand the information relationships
involved in the different areas of this form, for example, the information that is
required to create the SRD.
About modifying SRDs

When you create an SRD, you keep it in the Draft state until you are ready to
submit it for approval. Before submitting the SRD for approval, you or someone in
your group can open the record and add or modify information.
You cannot modify an SRD record after you have submitted it for approval. If you
modify it after it is approved, the SRD record must go through the approval
process again. This process is not automated. You must manually resubmit the
SRD for approval. SRDs can be approved only before they reach the Deployed
state.
Searching for SRDs

You can perform different types of searches in the Service Catalog Manager
Console.
Use the Console View options in the left navigation pane to view only SRDs that
are associated with you through your login ID or group ID (for example, SRDs
created by you, assigned to you or to your support group, and so on) and that
meet your specific search criteria.
Execute this type of search from the Search area near the top of the console. See
“About using the Company and Console View to search for SRDs” on page 159.
You can view SRDs according to specific search criteria, regardless of their
associations to people or groups. The top part of the console enables you to
specify search criteria, while the search results table shows SRDs in different
states, based on your query. The Search Criteria area enables you to filter the
SRDs you see in the search results table. Leaving all fields blank results in a
search for all SRDs that the user has permissions to view.

Managing SRDs
About using the Company and Console View to search for

SRDs
You can further change the table’s contents by using the Company and Console
View options in the left navigation pane of the console to see only, for example, all
SRDs that need approval. The Company and Console View options let you sort
SRDs by the following criteria:
Option Action
Company Filters the SRDs shown in the search results table based on
company. The content of this list is tenancy-driven, subject to
your access to various companies. If you have permissions to
view only a single company, only that company appears in
the list. Selecting Global shows only the SRDs that are
designated as “Global.” Clearing the field shows all records
to which the user has access.
Myself Narrows search to only SRDs that you manage.
Customer Organization Used especially in multi-tenancy environment. Enables you
to select a different BMC Service Request Management
organization and view the SRDs the organization manages.
Other Person Enables you to select a different BMC Service Request
Management user and view the SRDs that user manages.
All Searches for all SRDs regardless of the Service Catalog
Manager.
Needs My Approval Shows SRDs that are not deployed because you have not yet
approved them.
Coming Up... Enables you to view SRDs that will become visible to users
in a certain number of days (the default is 5). You can
configure the number of days in your application settings.
Coming Down... Enables you to view SRDs that will no longer be available to
users in a certain number of days (the default is 5). You can
configure the number of days in your application settings.
Using search criteria to search for SRD records

After selecting criteria by which to filter the list of SRDs, you can choose to view
more details than are provided in the Details section. You can directly open the
SRD record.
To search for SRD records


3 In the Search Criteria area, specify criteria to search upon.

For example, from the Status list in the Search Criteria area, select a status by which
to view SRDs.
The options are:
Draft—These SRDs are in Draft mode and have not been submitted for
approval.
Pending—These SRDs were submitted for approval and are pending approval.
An SRD goes to Approved status when all the approvers have approved it.
Request for Approval—These SRDs must be approved before they can be used
in the catalog.
Deployed—These SRDs are available to users from the Service Catalog.
Expired—These SRDs have expired and are no longer available from the
Catalog. When the end date specified for an SRD has passed, the SRD record
automatically sets to the Expired status.
Closed—These SRDs are not available from the Catalog. You have to manually
set the SRD status to Closed.
Rejected—These SRDs are not available in the Catalog because they were
rejected for various reasons.
4 Click Search.
A list of SRDs that match the selected status appears.
5 Select the SRD you want to view, and click View.
The record opens in the Service Request Definition form.
If the record is not pending approval, you can modify the record. See “Setting
approvals for an SRD” on page 146.
Changing the SRD image

After you have created an SRD, you can specify which image appears in the
Request Entry console. For example, the SRM administrator might have used the
default light bulb image for the SRD. As the Service Catalog Manager, you now can
use a different image.
NOTE
You can define the image only when the Service Request Definition form is in New
mode or taken offline.
For more information, see “Configuring service request image definitions” on

page 174.

Managing SRDs
To configure which image appears in the Request Entry console

1 Open an SRD.
to modify.
2 Click the Functions link in the left navigation pane, and click Change Image.
3 In the Browse for Service Details dialog box, specify a different SRD image to be
visible to users.
4 Click OK, and save the SRD.
You must save the SRD to save the image settings.
Configuring visible fields in the Request Entry console

After you have created an SRD, you can specify which fields are hidden or visible
to users during the various stages of a request. For example, you can specify that
your users can see the expected completion date of their request during the
Provide Information stage.
NOTE
You can define visible and hidden fields only when the Service Request Definition
form is in New mode or taken offline.
To configure which fields are visible in the Request Entry console

1 Open an SRD.
to modify.
2 Click the Functions link in the left navigation pane, and click Show/Hide Fields.

3 In the Show/Hide Options form, specify which fields in the SRD should be visible
to users:
Section Field Description

Review a service Turnaround Time Defines turnaround time for this SRD in Hours, Days,
Enables the Service Catalog Months, or Years. Turnaround time is used to calculate
Manager to select which the expected completion date of the SRD.
SRD fields to show in the Note: To calculate the expected completion date
Request Entry console accurately, business hours and holidays must be
during the Review stage. configured. For information about configuring
Price Actual price of this SRD.
Provide Information Expected Completion Date when the user can expect the request to be
Enables the Service Catalog finished.
Manager to select which Date Required Date when the user requires the request to be finished.
SRD fields appear in the Phone Phone number of the user.
Request Entry console
during the Provide Email Email address of the user.
Information stage. Attachment Enables users to add an attachment to the service
request.
Instructions Instructions that you want requesters to view.
Requesters see your text in the Provide Information
stage when they are requesting a service in the Request
Entry console.
Quantity Number of SRD ordered.
View a Request Service Coordinator Name of service request coordinator overseeing the
Enables the Service Catalog request.
Manager to select which Price Actual price of this SRD.
SRD fields appear in the
Approvals Shows the Current Approvers section, which includes
a More Info link that allows users to see the approvals
during the Summary stage.
for a request.
Request Details Expected Completion Date when the user can expect the request to be
Enables the Service Catalog finished.
Manager to select which Date Required Name of the user requesting the service.
SRD fields appear on the
Phone Phone number of the user.
Request Details dialog box.
Email Email address of the user.
Price Price of the SRD.
Service Coordinator Name of the service request coordinator overseeing the
request.
Quantity Number of service requests ordered.
Approvals Current approvers for the service request.
End User Process View Shows the Process View tab on the Request Details. If
you clear this field, the Process View tab is hidden from
users who do not have Service Request User or SRM
Administrator application permissions. This option is
selected by default.

Managing SRDs

You must save the SRD to save the Show/Hide field settings.
Managing service request notifications

You can configure the states when notifications for the service request are sent to
application administrators and users, based on the SRD. For example, you can
specify that, when the service request is approved, the user is notified.
By default, notifications are not sent to the requester of an action. For example, take
the Notify End User On Submit action. When Mandy Manager submits a request,
she is not notified because she performed the action. But if she requests a service
on behalf of Fred User, Fred (but not Mandy) receives a notification that the
request was submitted.
NOTE
You can define notifications only when the Service Request Definition form is in
New mode or taken offline.
For information about the architecture and configuration of notifications, see the
BMC Remedy IT Service Management Notification Engine Guide. For a list of BMC
Service Request Management notification events, see the BMC Service Request
Management Release Notes.
To manage notifications
1 Open an SRD.
to modify.

2 Click the Functions link in the left navigation pane, and click Manage
Notifications.
By default, the following actions trigger notifications:
Notify End User on Submit
Notify End User on Cancelled
Notify End User on Complete
Notify End User on Pending
Notify Assignee on Assignment
Notify Approver on Waiting Approval
3 Select or clear additional event states that trigger a notification.
4 Click OK, and save the SRD to save your notification settings.
Viewing the SRD audit log

Service Catalog Managers can use the audit log to view the history of certain fields
on the SRD, such as Status, Service Catalog Manager, Service Request Approval,
Cost, Business Service CI, Turnaround Time, Account Number, and Status Reason.
They can also view the notification trail.
NOTE
This information is read-only. You can view it only when the Service Request
Definition form is in Modify mode.
To view the audit log

1 Open an SRD.
to modify.
2 Click the Functions link in the left navigation pane, and click View Audit Log.
3 To view notification audits, click the Notification Audit tab on the View Audit Log
form.
4 Select a notification from the list that appears in the table, and click View.

Managing SRDs
Defining SRD customer information

You can modify specific customer information for your SRD. The SRD “customer”
is the person requesting that the SRD be added to the service catalog. Customers
are by default required to approve the SRD before it can be deployed. See
“Approving SRDs” on page 150.
To define customer information

1 Open an SRD.
to modify.
2 Click the Details link under the Customer First Name and Last Name fields.
3 On the Request Customer Information form, add or modify customer information.
For example, in a multi-tenancy environment, you can change the company or
organization as needed. You can click Clear to remove all customer information.
Adding an advanced interface form to an SRD

You can add an advanced interface form to an SRD. You have the option of
including an advanced interface data entry screen instead of the default window
used in the Request Entry console for completing details.
The following three advanced interface template forms are installed with Service
Request Management by default:
Password Reset (SRS:AdvancedInterface_PasswordReset)
Without Backend Mapping
(SRS:AdvancedInterface_WithoutBackendMapping)—Some advanced
interface fields already provided
With Backend Mapping (SRS:AdvancedInterface_WithBackendMapping)—
Form with tabs to hold advanced interface data fields and mapped data fields
Your application administrator might have added others.
See also the detailed steps in “Creating SRDs with advanced interface forms” on
page 354.

To add an advanced interface form to an SRD

1 Open an SRD.
to modify.
2 In the Advanced Interface Form field, select an advanced interface form.
3 Click Save.
This advanced interface form is added to the SRD.
Viewing metrics about an SRD

You can view the following types of metrics about an SRD:
Request frequency
Recent request count
Last requested
To view metrics about an SRD

1 Open an SRD.
to modify.

Managing SRDs
3 Perform any of the following actions:

Specify if the service request needs approval.
Add a service request coordinator group.
You can select which coordinator group is assigned to work on the service
request. The service request coordinator group includes a list of members. By
default, the application selects (in the round-robin method) from the list which
member of the group will be assigned to work on the service request.
Add a survey. See “Adding surveys to an SRD” on page 156.
4 View the read-only metrics.
The Request Frequency field shows you the number of times a service request was
created using this SRD. The information is updated when a service request is
created using this SRD.
NOTE
The Survey Enabled field shows that no survey can be sent for this company. The
option is based on the Request Preferences form setting. See “Defining behavior
rules for surveys” on page 177.
5 Click Save.
Adding an attachment to an SRD

To include more information in your SRD, you can add an attachment to it.
To add an attachment to an SRD

1 Open an SRD.
to modify.
3 Under Attachment, click Add, and browser for the file to attachment.

Deploying SRDs
You must perform the following steps to deploy an SRD and make it available to
users:
Step 1 Create the SRD and keep it in the Draft state until you are ready to submit it for
approval.
Step 2 Make sure the Start Date is up-to-date. Otherwise, the SRD will not be online.
Step 3 Make any necessary changes to the SRD until it is ready for approval, and change
the status of the SRD to Request for Approval. When you save the SRD, the
approval process starts.
Step 4 In the approval cycle, the following stages might occur:
SRD is approved—You are ready to deploy it.

Approver needs more information—Status is set to Pending and the Status
Reason is set to More Information. You must provide the information to the
approver, which means modifying the SRD and resubmitting it for approval.
SRD is rejected—When an approver rejects the SRD, the Status is set to Rejected.
The Service Catalog Manager can move the SRD to the Draft state and resubmit
it for approval later.
After the SRD is approved, set its status to Deployed to make it available to
users.
If the SRD requires approval and is approved by all the specified approvers, it is
deployed automatically.
NOTE
After you deploy the SRD, it might not be immediately visible to users because it
has not reached the Start Date and become online.
To deploy an SRD
1 Open the SRD.
to modify.

Deploying SRDs
2 Work the SRD through its various states until you reach the Deployed state.
The Take Offline button and the green stoplight appear in the Service Request
The green stoplight alerts you that the SRD is deployed and is in the correct date
range.
3 Click Save.
The SRD record is online and available to users from the catalog. Users can view
the service request definition in the Request Entry console and browse or search
for it.
Taking an SRD offline

If needed, you can temporarily take an SRD offline, for example, for testing how
an SRD functions in the Request Entry console, or you must modify it for some
reason. The red stoplight alerts you to the SRD status.
In addition, an SRD might be offline because its end date expired.
To take an SRD offline

3 Search for an SRD, select it, and click View.
4 Click the Take Offline button.
The Turn Online button and the red stoplight appear in the Service Request
The red stoplight alerts you that the SRD is no longer deployed and users cannot
access it in the Request Entry console.
5 Click Save.
The SRD record is no longer available to users from the catalog.

Restoring the SRD to the online state

If an SRD was manually taken offline, you can manually restore the SRD to the
online state by clicking the Turn Online button. If a deployed SRD has expired, you
can manually restore the SRD to the online state by resetting the end date.
To return the SRD to the online state

3 Search for the SRD, select it, and click View.
The Turn Online button and the red stoplight appear in the Service Request
4 Click the Turn Online button.
The green stoplight alerts you that the SRD is redeployed.
5 Click Save.
The SRD record is available to users from the catalog.
Resetting the date of an expired SRD

The following procedure describes how to reset the date of an expired SRD
To reset the date of an expired SRD

3 Search for the offline SRD, select it, and click View.
4 In the End Date field, open the calendar.
5 Enter a date, and click Save.
The green stoplight appears, alerting you that the SRD is deployed.

About building SRDs that use dynamic data flow
About building SRDs that use dynamic data

flow
The following scenario illustrates how to build SRDs that use dynamic data flow.
It builds on your expertise in creating standard SRDs, adding questions to SRDs,
and deploying the SRD. You can modify these values as needed for your own
environment. See “Managing SRDs” on page 158.
Creating an SRD that tests the Change PDT

This test SRD uses the Change PDT (Change_Mgt_PDT) that you created in “Change
request PDT” on page 102. The service request that you submit should successfully
pass the contents of the Summary and Operational Categorization Tier 1 fields as
output to the change request. When you complete the change request, the change
request should pass its output to the two work orders.
Area, tab, or field Tab or field Value Function or description

Header Company Enter required
Title information to complete
Navigation Categories the SRD (for example,
(and so on) Dynamic_SRD.
Service Request Approval Type None by default You can temporarily disable service
Approval tab request approval for testing
purposes.
Approvals tab Set using Approval Selected by default. You can temporarily disable SRD
Engine approval for testing purposes.
Definition tab Request Type Standard
Effective Dates and Times Enter a start date.
Process Template Select the change request
PDT (for example,
Change_Mgt_PDT).
Questions & Add Question 1 Click Questions.
Mappings 2 Click Add Question.
3 After you enter all the
following information,
click Apply.
4 Click Next to go to the
next page of the
wizard.
Question Text Categorization Tier 1
Summary
Question Format Text


Category Local SRMS
Variable Question 1 Select question (for
Mapping example,
Categorization Tier 1).
2 Click Apply.
3 Click Close.
Creating an SRD that uses the Incident PDT

This SRD uses the Incident PDT that you created in “Incident request PDT” on
page 104. This procedure assumes that the test SRD you previously created
successfully passes the output from the change request to the two work orders.
The service request that you submit should successfully pass the contents of the
Summary and Operational Categorization Tier 1 fields as output to the incident
request. When you complete the incident request, the incident request should
passes its output to the change request. When you complete the change request,
the change request should pass its output to the two work orders.

Header Company Enter required
Title information to complete
Navigation Categories the SRD (for example,
(and so on) Dynamic_SRD.
Service Request Approval type None by default You can temporarily disable service
Approval tab request approval for testing
purposes.
Approvals tab Set using Approval Selected by default. You can temporarily disable SRD
Engine approval for testing purposes.
Definition tab Request Type Standard
Effective Dates and Times Enter a start date.
Process Template Select the incident
request PDT (for
example,
Incident_Mgt_PDT).
Questions & Add Question 1 Click Questions.
Mappings 2 Click Add Question.
3 After you enter all the
following information,
click Apply.
4 Click Next to go to the
next page of the
wizard.
Question Text Categorization Tier 1
Question Format Text

Miscellaneous configuration

Category Local SRMS
Variable Question 1 Select question (for
Mapping example,
Categorization Tier 1).
2 Click Apply.
3 Click Close.
The following sections describe miscellaneous configuration steps for surveys, cart
display, service requests, Request Entry console behavior, and so on.
Defining service request definition settings

Use the Service Request Definition Settings form to specify the default behavior of
service request definitions.
To define service request definition settings

tab.
Advanced > Service Request Definition Settings, and click Open.
The Service Request Definition Settings form appears.
3 Select the company to which these settings apply.
For global SRD settings, select -Global- as the company.
4 In the Use Approval Server field, enter Yes (the default) to use the Approval Server
to determine the approvers of the SRD.
If you enter No, the Approval Server is bypassed. In this case, approvers are based
on the selections on the Service Request Definition form.
5 In the Hot List Interval field, specify how long metrics are kept to determine the
top-used SRD over the given period of time.
The “Hot List” services are the most requested services in the Request Entry
console. These services are listed in the Popular Services view of the Request Entry
console. For more information, see the BMC Service Request Management User Guide.
6 In the Top Hot List Request field, specify the top number of SRDs that appear on
7 (optional) From the Business Process Sandbox Dataset list, specify the sandbox
dataset.

IMPORTANT
If multiple sources of data provide updates to the Atrium Service Catalog, you
must specify a sandbox dataset.
When a service is related to the SRD and the SRD is deployed, the process is
created in the Atrium Service Catalog. For more information, see the BMC Atrium
CMDB documentation.
8 (optional) Specify the Reconciliation Job Name.
This job runs the appropriate reconciliation job with the selected sandbox dataset.
You must use reconciliation rules to move the data to production.
IMPORTANT
If you change the production or sandbox datasets on this form, in the
Reconciliation Engine you must update the underlying reconciliation rules “BMC
Asset Management – Sandbox” to use the new datasets. Without this change, the
data cannot be reconciled to the new production or sandbox datasets.
9 Click Save.
Defining SRD levels

The SRM administrator can create entries for “levels” of service (for example,
Gold, Silver, or Bronze) You can also modify these service levels for different
locales.
To define SRD levels

tab.
2 From the Application Settings list, choose Service Request Management > SRD
Level > SRD Level, and click Open.
3 (optional) From the SRD Level dialog box, select a new locale (for example, fr_FR).
4 Enter a new level, for example, Pewter.
5 Select the status, for example, Enabled.
6 Select the company to which this level applies, or select -Global- to make this level
available to all companies.
7 Click Save.
Configuring service request image definitions

Use the Service Request Images form to view, modify, replace, or add (for proof of
concept) images used in the application consoles and forms. For example, you can
replace the default advanced_48.jpg file that is used in the Request Entry console
with a different image that better suits your organization or your locale.

NOTE
You can include any standard graphic format used with HTML code, (for example,
.gif, .png, or .jpg graphics). You can even use animated GIF images. Generally,
the smaller the image, the better the performance.
To configure service request image definitions

tab.
2 From the Application Settings list, choose Service Request Management > Request
Entry Management > Service Request Image Configuration, and click Open.
3 To create an image, perform the following steps from the Service Request Images
form:
a Specify a company.
b Right-click inside the attachment field, and select Add.
c Add the image.
d Enter the image name and the image file name.
e Click Save.
You can now use this image in the Request Entry console as needed (for example,
when you create a navigational category).
4 To replace an image, perform the following steps:
a Open the Service Request Images form in Search mode.
b Search for a record.
c From the results lists, select an image name.
d Right-click the image inside the attachment field, and select Delete.
e Right-click inside the attachment field, and select Add.
f Add the image.
g Click Save.
For more information, see “Managing SRD images” on page 175.
Managing SRD images

After creating SRDs and adding images to your company or organization, you use
the Service Request Management Image Management form to relate these images
to your SRDs. For example, if you added a default image, you can map your SRDs
to show this image in the Request Entry console. You can also map multiple SRDs
to one image.
You can relate different images for different locales for each SRD. For example, you
can relate one image appropriate for the en_US locale, and a different image
appropriate for the fr_FR locale.

To manage SRD images

tab.
Entry Management > Service Request Definition Image Management, and click
Open.
The Service Request Management Image Management form appears. Select an
SRD by using the various search criteria (for example, narrowing down your
choices by company, locale, or status).
3 Specify a company or -Global- for all companies.
The SRDs created for the specified company appear.
4 (optional) Specify the locale (for example, es_ES).
The SRDs created with the specified locale appear.
5 Specify the SRD status (for example, Deployed).
6 In the table on the left of the form, select the title for an SRD for which to add or
change an image.
The title’s default image (if it has one) appears below the Service Request
Definition title list.
7 Select an image from the image name list.
The image appears below the Images list.
8 To associate the title with the image, click Relate, or click Remove to delete the
association.
Configuring survey questions

Use the Search Survey form to set up survey questions for your requesters. Surveys
give the Business Service Manager an indication of customer satisfaction levels
and how the service desk is performing.
You can configure BMC Service Request Management to automatically send a
survey for a specific company or select Global to make the survey available to all
companies when a service request is resolved.
NOTE
You must have the SRM Administrator permission to access this form from the
Custom Configuration tab. However, the Service Catalog Manager can create
questions “on the fly” in the Search Survey form when working with an SRD (in
the Service Request tab).

To configure survey questions

tab.
2 From the Application Settings list, choose Service Request Management
> Advanced > Survey Configuration, and click Open.
3 From the Search Survey form, select the company to which this survey applies, or
5 From the Survey Configuration dialog box, enter a name for your survey.
6 Click Save.
7 From the Search for Survey form, click Manage Questions.
The Manage Questions dialog box appears.
8 From the The Manage Questions dialog box, perform these steps to create or
modify questions in your survey:
a Specify a locale, if your questions must be localized (for example, fr_FR).
b Specify the numerical sequence.
c Enter the question.
Defining behavior rules for surveys

Use the Surveys tab in the Request Preferences form to set up behavior rules for
surveys on a per-company basis.
To define survey rules

tab.
Advanced > Preferences, and click Open.
3 From the Request Preferences form, click the Surveys tab.
4 Select -Global- or the specific company to which this rule applies.
5 (optional) Enter a description.
6 In the Status field, select Enabled if you want this categorization entry to be
available to users; otherwise, select a different status.

7 Define survey rules:

Enable Survey—Select Yes if you want requesters to receive surveys after their
requests have been resolved.
Last Surveyed Days—Select the number of surveys that are sent to a user each
day.
Enter 0 to specify that the survey is sent every time a service request reaches the
Completed status. Enter 1 (the default setting), for example, for the survey to be
sent once every 24 hours when a service request reaches is completed.
TIP
Do not send too many surveys to users.
8 Click Save.
Configuring request entry preferences

Use the Request Entry tab on the Request Preferences form to configure rules for
To configure request entry preferences

tab.
Advanced > Preferences, and click Open.
3 From the Request Preferences form, click the Request Entry tab.
4 Select the company to which these preference apply.
6 In the Status field, select Enabled if you want this categorization entry to be
available to users; otherwise, select a different status.
7 Click the Request Entry tab.
8 In the Search Suggestions field, select one of the following options to control what
appears as users type in the Search field on the Request Entry console:
Display Suggestions—Lists suggestions from commonly used search terms.
Hide Suggestions—Does not list suggestions, but maintains statistics on terms
used in searches that users perform.
Hide Suggestions and Disable Statistics—Does not list suggestions and does not
maintain statistics on terms used in searches that users perform.
For more information, see “Viewing statistics of searched terms on the Request
Entry console” on page 184.

9 In the Show Cart field, select Yes if you want requesters to see the cart, or select No
to hide the cart.
NOTE
If you hide the cart, the Cart icon on the Request Entry console, the Add to Cart
button, and underlying cart functionality is hidden from users.
10 In the Service Categories Sort field, you can change the display order of the
navigation categories on the Request Entry console.
Sort Order—Shows navigational categories in the Request Entry console as they
are defined in the Category Management form (default). For more information,
see “Configuring navigational categories” on page 65.
The top-down order in the Category Management form is how the categories are
ordered in the Request Entry console. The sorted categories are based on your
entitlements. For example, if Mary Mann from Calbro Services is not entitled to
view Calbro Software, the Request Entry console starts with Phones as the first
category, then Software, Hardware, and so on.
Only categories used in deployed SRDs appear in the Request Entry console. To
continue the example, if Phones is not used in an online SRD, Mary Mann would
only see Software, Hardware, and so on, in the Request Entry console.
Alphabetical—Shows navigational categories in alphabetical order. The
alphabetical sort starts with upper-case letters from top left to top right (for
English and other Latin-based languages), and top to bottom. Sorting then starts
with lower-case letters, left to right.
11 In the Submit Confirmation field, select one of the following options:
None—Does not display a confirmation note when a request is submitted.
Accessibility Users—Displays a confirmation note only for users configured as
accessibility users. For information about configuring accessibility users, see the
BMC Service Request Management User’s Guide.
All Users—Displays a confirmation note for all users when a request is
submitted.
12 In the Category Title & Icon Default Behavior field, select the behavior of
Category 1 links.
The following selection values specify which actions execute if you click either the
icon or the title of a navigational category in the Request Entry console.
List Related Services—The icon and title performs the List Related Services
function, and the List Related Services link is hidden on the Request Entry
console. If you click the icon or title, a list of services relating to that navigational
category appears. If there are subcategories, the Browse Sub-Categories link
appears if subcategories exist. You might see situations where subcategories
appear for some Category 1 links, but not for others.

Browse Subcategories—The icon and title perform the Browse Subcategories

function, and the Browse Sub-Categories link is hidden on the Request Entry
console. If you click the icon or title, the subcategories related to that
navigational category appear.
If you select the Browse-Subcategory option, you have the added option of
hiding or showing the List Related Services link.
Hide List Related Services Link—This suboption appears only when you select
Browse Subcategories. Select No to show the List Related Services link.
13 (optional) In the Price Display Option field, select an option for displaying the price
for a service in the Request Entry console.
The following options are available:
Display for All SRDs—Displays the price for all SRDs for the company that is
selected on this Request Preferences form (see step 4).
If you select this option, it takes precedence over the options selected in the
Show/Hide Options form for an individual SRD. See “Configuring visible fields
in the Request Entry console” on page 161.
Hide for All SRDs—Does not display the price for any SRDs for the company
that is selected on this Request Preferences form (see step 4).
If you select this option, it takes precedence over the options selected in the
Show/Hide Options form for an individual SRD. See “Configuring visible fields
in the Request Entry console” on page 161.
Based on SRD Configuration— Displays the price as defined in the SRD. (On
the BMC Service Request Management form, choose Functions > Show/Hide
Fields to set the price.) This option is available for backward-compatibility
purposes.
(clear) (the default)—Displays the price as defined in the SRD. Clearing the field
has the same result as choosing the Based on SRD Configuration.
If you are using BMC Cloud Service Management, select (clear). The Service
Offering price for an enablement Requestable Offering and the Service Offering
prices for transactional Requestable Offerings will be retrieved from Atrium
Service Catalog and displayed on the Request Entry console.
If you do not create a record in the Request Preferences form for a company, the
Price Display Option for the Global company is used.
14 Click Save.

Configuring service request HTML definitions

The Service Request HTML form enables you to view and modify the underlying
HTML definition code used in the BMC Service Request Management consoles
and forms. For example, you can modify the text, the spacing of table cells,
background colors, and so on, of the Summary window that appears in the
You should be familiar with HTML before editing these files.
To configure service request HTML definitions

tab.
Advanced > Service Request HTML Configuration, and click Open.
3 From the Service Request HTML form, click the Search button.
4 From the results list, select the record for your locale for one of following Text Tag
names:
Text Tag name Definition

ConsoleSummary Shows a summary in the Request Entry console.
JavaScriptLib Inserts a block of JavaScript code into the document
header.
RQCBCDetails Shows Broadcast Details.
RCOSRDetails Shows a Request Summary in the Service Request
Coordinator Console.
SCMPDTSRDDetails Shows PDT details in the Service Catalog Manager
Console.
SCMSRDDetails Shows SRD details in the Service Catalog Manager
Console.
SRDDetails Shows SRD Description in the Request Entry
console.
SRSBusMgrRequestSummary Shows a Service Request Summary in the Service
SRSQuestionDetails Shows questions in the Request Details dialog box
that appears after clicking the Request Details button
from a console.
SRSRequestDetails Shows Request Details in the Request Details dialog
box that appears after clicking the Request Details
button from a console.
SRSRequestDetailsQuestions Shows Request Details and Questions in the Request
Details dialog box that appears after clicking the
Request Details button from a console.
SRSSRCActivityLogDetails Formats a table section for displaying Activity log
details.
SRSSRCActivityLogDetailsEntries Formats each Activity log entry in a table row.

5 Modify the information as needed (for example, change the background color or
the summary text).
6 (optional) Add locale information to the HTML code.
For example, you can use the fr_FR locale to localize this content for your French
audience. This content appears in French when users log into the BMC Remedy AR
System server with the fr_FR locale.
7 (optional) To see the effects of your changes to the HTML code, click Preview
HTML.
8 Click Save.
Defining default Request Entry console preferences

The Console Default Preference form allows you to update the default preference
record for the Request Entry console. You can configure the appearance and use of
the Request Entry console for your end users.
To define the default Request Entry console preferences

tab.
Entry Management > Default Console Preference, and click Open.
3 From the Initial Console View field in the General Console Information area of
Default Preferences form, select whether the Popular Services, Service Categories,
or the Submitted Requests view appears when the Request Entry console opens.
The default setting is Popular Services. When you click the Home button in the
Request Entry console, you return to the view that you specify here.
4 Modify the default search criteria for My Requests when the Request Entry console
is opened:
a From the Show field, select if service requests with a particular status should
appear.
For example, you might want to show only service requests with a draft status.
The default setting is All Open Requests.
b From the Recently Closed field, select the number and unit criteria for requests
closed since the user last logged in.
For example, you might want to show requests that were closed in the last five
days. If the application is accessed infrequently, you enter a higher number, (for
example, requests closed in the last two weeks or two months).
5 From the Broadcast Defaults area, specify when users are alerted with a broadcast
alert popup window.
The default is Never. However, users might want to be prompted when they open
the Request Entry console or when a new broadcast occurs.
6 Click Modify, and click Close.
You must close and re-open the Request Entry console for the changes to appear.

Configuring service request query exclusions

You can configure the Request Entry console to ignore frequently used words
(such as and, the, where, and so on). The console can also be configured to exclude
specific words from the search.
BMC Service Request Management installs by default a list of U.S. English words
(with the en_US locale) to exclude. You can also create a localized exclusion list.
NOTE
Query exclusions are applied based on an exact match by locale.
If full text search (FTS) is enabled, the Request Entry Console will use the FTS
Ignore Words list to exclude words from end user searches. If FTS is not enabled,
the Request Entry Console will use the BMC Service Request Management
Exclusion List to exclude words.
You may want to review the FTS Ignore Words as it is extensive. For more
information, see the BMC Remedy Action Request System Configuration Guide.
To configure service request query exclusions

tab.
Entry Management > Service Request Search Exclusion String, and click Open.
3 To modify the list of terms to exclude, perform the following actions from the
Service Request Query Exclusions form:
a Click the Search button from a browser, or click the New Search toolbar icon in
BMC Remedy User.
b Select a record and modify it as needed by adding additional words to exclude
(for example, because).
c Make sure the list begins and ends with a semicolon.
d Click Save.
4 To create a localized exclusion list, follow these steps:
a Specify the status.
b Specify the locale (for example, fr_FR).
c Add the words to exclude (for example, mais, parce que, or Pérégrin).
d Make sure the list begins and ends with a semicolon.
e Click Save.

How activity log information is passed

When end users and backend application users update the activity log on a service
request or a backend request, the following scenarios can occur:
When an end user updates the activity log of a service request, these new work
notes are passed to all open backend requests related to the service request
(except those with a status of Closed, Completed, or Canceled.) Work notes will
not be passed to backend requests that have not yet been opened.
If a user adds work notes to a service request that is not currently in progress
(for example, the service request’s status is Draft, Waiting for Approval,
Rejected), no backend requests exist. Then, after the initial backend requests are
created, all work notes from the service request are sent to those backend
requests.
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 user can add a work note (for
example, to indicate the reason for reopening). That work note is passed to the
backend request that is reopened. 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.
Viewing statistics of searched terms on the

The SYS:SearchTermsStatistics form (Figure 6-5) keeps statistics about searched
terms for each company. When a user enters a search term on the Request Entry
console, and search results are returned (or not returned), the
SYS:SearchTermsStatistics form is updated.
NOTE
You must have AR System administrator permissions to view this form.

Viewing statistics of searched terms on the Request Entry console
Figure 6-5: SYS:SearchTermsStatistics form
The SYS:SearchTermsStatistics form contains the following fields:

Company—The name of the company for the user who used the search term in
the search.
Search Term—The text of the search term (for example, request a new
laptop).
Locale—The locale of the user who used the search term. This field’s values
follow these rules:
For every locale (except pt_BR or zh_CN), the value of the field contains only
the first two letters of the locale. For example, for de_DE, the value is de.
For pt_BR or zh_CN, the value is the same as the locale (for example, pt_BR).
A $NULL$ (empty) locale value is allowed and can be used as a fallback
mechanism.
Primary tag—The area to which the search term applies (that is,
REQUEST_ENTRY_CONSOLE).
Secondary tag—A specific description (if needed) of the area to which the
search term applies (for example, SEARCH_FIELD).
Total Successful Searches—The number of times the search term returned
results for the users at the company.

Current Unsuccessful Searches—The current number of times the search term

did not return any results for a user.
You can reset this field. (The Total Unsuccessful Searches field records all of the
unsuccessful search attempts.) After the search term has been successful the first
time, resetting the Current Unsuccessful Searches field raises the search term
rank. Resetting the field is helpful when you add a service (such as “replacing a
tuner”). If users were searching for “replace tuner,” but there was no service, the
ranking would be low. When you add the “replacing a tuner” service, you
would reset the Current Unsuccessful Searches field so that the search term
receives a ranking value of 1, and it appears on the suggestion list.
Total Unsuccessful Searches—The total number of times the search term did
not return any results for the users at the company.
Search Term Ranking—The current search term rank. The higher the rank,
statistically the more users will see results when using this search term; hence,
the term is more useful. Each unsuccessful search lowers the rank. Each
successful search raises the rank.
The rank is calculated with the following formula:
“Total Successful Searches” – “Current Unsuccessful Searches”
This calculation can be zero or a negative or positive value. Search terms with a
negative or zero value are never displayed in the suggestion list on the Request
Entry console.
Setting Service Catalog Manager Console

preferences
When the Service Catalog Manager Console opens, you can determine:
Default console settings.
Service request and process defaults, along with console settings, in the Service
Catalog Management Console.
To set the Service Catalog Manager Console preferences

1 In the Service Catalog Manager Console, choose Functions > Preferences.
2 In the Application Preferences dialog box, click the Service Catalog Management
tab.
3 Modify the default search criteria for the Request Definition View and Process
View as needed.
For example, you might want to show SRDs with a certain status, for example,
Draft, by default in the Request Definition View.

Setting Service Catalog Manager Console preferences
4 Specify the Console Settings:

a In the Startup Screen field, select if the Request Definition View (default) or the
Process View appears as the Console Focus.
b In the Coming Up Window field, select the number of days to view SRDs that
will become visible to users (the default is 5).
c In the Coming Down Window field, select the number of days to view SRDs that
will no longer be visible to users (the default is 5).
5 Click Save.
You must close and re-open the Service Catalog Manager Console for the changes
to be shown.


Chapter
7 Using the Service Request

Designer
The Service Request Designer provides an easy-to-use wizard interface for Service
Catalog Managers and Business Analysts to create or modify requestable services
(SRDs).
For more details about creating SRDs, see “Creating service request definitions” on
page 109.
NOTE
You must have the Service Catalog Manager permission to create SRDs.

Overview of the Service Request Designer (page 190)
Starting the Service Request Designer (page 191)
Completing the Description section (page 192)
Completing the Fulfillment Process section (page 194)
Completing the Approvers section (page 197)
Completing the Entitlements section (page 198)
Completing the Options section (page 199)
Completing the Deployment section (page 200)

Overview of the Service Request Designer

The Service Catalog Manager or the Business Analyst can use the Service Request
Designer to specify the definitions, processes, entitlements, approvals, and so on
for a requestable service (SRD). The requestable service is a type of service offering,
communicated to users as a service request through the Request Entry console.
From start-to-finish, the Service Request Designer steps you through the process of
adding the following functions to your requestable service:
Service request description (for example, company, title, graphic, and so on)
Service categories
Service request details hidden or visible to users
Notification sent to users
Fulfillment process used by the requestable service (including quick launch
PDTs)
Questions and mappings added to the requestable service
Service request approvers
Packages and entitlements
NOTE
The Service Request Designer does not support adding a survey to an SRD or
specifying an SRD as a System Request in the Request Entry console. To perform
these tasks, you must use the Service Request Definition form.
Figure 7-1: Service Request Designer

Starting the Service Request Designer
NOTE
Some functionality in the Service Request Designer requires advanced permissions
for you to access. For example, for Request Catalog Managers to access the Manage
Categories button on the Description - Details panel, they must have SRM
Administrator permission. The Manage Processes button requires Request Catalog
Manager permission and the Manage Entitlements button requires Entitlements
Administrator permission.
If the stage requires validation, the Service Request Designer validates it in the
creation of a requestable service, before you can advance to the next panel. Not all
stages require validation (for example, the Options stage or the Entitlement stage).
Clicking the Next button advances you to the next step of the wizard after you
have passed validation. You can click the Back button to return to earlier stages in
the process.
You should have already created the underlying application templates, AOTs, and
PDTs that you want to use in the requestable service.
NOTE
If you are a Business Analyst, you can create SRDs only by using the Service
Request Designer, and you can view only SRDs that you created. Also, you cannot
view SRDs that have a status of Cancelled or Expired. Request Catalog Managers
can create SRDs by using the Service Request Designer or the Service Request
Definition form, and can view all SRDs. For information about creating SRDs by
using the Service Request Definition form, see “Managing SRDs” on page 158.
Starting the Service Request Designer

To start the Service Request Designer
1 In the IT Home Page, under the BMC Service Request Management heading, click
the Service Request Designer link.
2 On the Start panel, create or modify the requestable service.
To modify requestable services to which you have access, click Modify. You can
filter the search results by entering a search string and then clicking Search.
3 Click Next.
4 Go to “Completing the Description section” to continue the procedure.

Completing the Description section

To complete the Description section
1 On the Description - Details panel, enter or specify the following information:
Field Description
Company (required) Specify the company the requestable service is tied to. The user
must belong to this company to see the requestable service. If the
requestable service is Global, all users have access to it.
Note: If guest users must be able to access the SRD, select Global.
Title (required) Enter a descriptive title for the requestable service.
If you want to enter the greater than (>) or less than (<) sign in the
Title field, use encoded text (&gt for >, and &lt for <); otherwise,
browsers will interpret the greater than and less than signs as valid
HTML markup if the title is included in a URL.
Description Enter a detailed description of the requestable service.
(required)
Note: Only 255 characters can be shown in the Request Entry
console. Any text greater than 255 character is indicated by
ellipsis points (...), although you cannot access this text in the
Console.
In addition, you can enter any value that can be read by a browser.
For example, you can enter the URL of your company or the URL
for a form on the web. The web page, form, or interpreted code
appears in the Description field when requesters access the
requestable service.
For example, you could add the following JavaScript snippet:
Category Specify the category type that applies to the requestable service (for
example, Telecommunications Services > Conference Calling >
Conference Call Setup).
2 Click the Manage Categories button to create or modify a category.

You can view this button only if you have SRM Administrator permissions. For
more information about using the Category Management window, see
“Configuring navigational categories” on page 65.
3 Click Next.

Completing the Description section
4 On the Description - Additional panel, enter or specify the following information:
Field Description
Instructions Enter instructions that you want requesters to view. Requesters see
your text in the Provide Information stage when they are
requesting a service in the Request Entry console.
Keywords Enter aliases (keywords) used to search for requestable services in
Requesters can enter these keywords when they search for services
in the Request Entry console.
Cost Enter the cost budgeted for this requestable service. Cost can be
linked to service targets.
Price Enter the actual price of this requestable service.
To select a currency other than the default currency that appears in
the Price field, select a currency from the Price field’s drop-down
list. This is the currency that appears on the SRM Request Entry
console and the service request.
When a user submits a request from a Delivery SRD, the service
offering price is passed to the fulfillment application. If the request
is added to the cart or saved as a draft, the administrator for the
Atrium Service Catalog can change the price in the Atrium Service
Catalog, and the price is reflected on the SRD. After the request is
submitted, the price can no longer be changed.
Note: For consistency, make sure that the currency for the price in
the SRD and the corresponding service offering (in the Atrium
Service Catalog) are the same. If service requests in the cart on the
Request Entry console are shown with different currencies from
each other, the total price is calculated based on the currency
ratios. For information about configuring currency ratios, see the
BMC Remedy AR System Action Request System Configuration
Guide.
Turnaround Time Define turnaround time for this requestable service in Hours or
Days. Turnaround time is used to calculate the expected
completion date of the service request.
Note: To calculate the expected completion date accurately,
business hours and holidays must be configured. For
information about configuring business hours and holidays, see
“Configuring business hours and holidays” on page 61.
Level Select the service level for the requestable service (for example,
Gold, Silver, or Bronze) as configured by the application
administrator. See “Defining SRD levels” on page 174.
Image Specify which image appears to users in the Request Entry console.
Advanced Interface If you want to use an advanced interface form, specify it in this
Form field.
If you select an advanced interface form, the Fulfillment Process –
Questions panel will not be available. (Questions and advanced
interface forms are mutually exclusive.)

Field Description
Service (optional) Select an Atrium Service Catalog service to which you
want to link the SRD.
If you do not select a service, the default global service is applied
after you save the SRD.
Note: When you create an SRD, a requestable offering is
automatically created in Atrium Service Catalog.
For more information, see “How SRDs are related to Atrium
Service Catalog” on page 111.
Service Offering (optional) Select an Atrium Service Catalog service offering to
which you want to link the SRD.
If you do not select a service and service offering, the default global
service and service offering are applied after you save the SRD.
Offering Type (optional) Select the type of offering for the service:
Delivery—The SRD (Requestable Offering) is used to activate
the Service Offering (for example, initially setting up the
equipment to use a phone service). Users pay an activation fee
only once.
You can have only one Delivery SRD for each service offering.
Transactional—An SRD (Requestable Offering) used to make a
request which is associated with a Service Offering (for example,
phone service, internet, and so on), or an SRD used to make any
other request.
You can have multiple Transactional SRDs for each service
offering.
5 Click Next.
6 Go to “Completing the Fulfillment Process section” to continue the procedure.
Completing the Fulfillment Process section

7 On the Fulfillment Process - Process panel, select a process and then click Apply.
Your choice appears as the current fulfillment process. If you change your mind,
you can select a different process from the table and click Apply.
You can also filter the processes shown in the table by entering a search term and
then clicking Search.
To create or modify a process, click the Manage Processes button.
You can use this button only if you have Request Catalog Manager permissions.
For more information about using the Process Definition Template form, see
“Creating a standard PDT” on page 91.
8 Click Next.

Completing the Fulfillment Process section
9 On the Fulfillment Process - Questions panel, create or add questions to the

requestable service.
a Click Questions in the navigation tree.
b Click Add Question.
c Select New Question from the navigation tree.
d Define the Question Text.
Alternatively, you can select a question from the Select From Library list, and go
to step g. (For more information about creating questions in the Questions
Library, see “Creating questions to use with SRDs” on page 203.)
field, use encoded text (&gt for >, and &lt for <); otherwise, browsers will
question text is included in a URL.
e Select a question format (for example, Text or Menu).
f (optional) In the Category field, select or enter the category that the question will
be classified with.
NOTE
Questions Library. Then, you receive lists of questions by category instead of a
single long list of questions when you select a question from the library in the
Question Management form (which you can open from an SRD). You can
categorize questions for each fulfillment application or any other grouping that
works for your organization.
g Specify whether the question is Required or Hidden.

h Based on the question format, specify the question details.
For example, a Text question requires that you define the Default Response, the
Number of Text Rows, and the Limit Input Length.
i Click Apply to create your question.
j (optional) Click Add Condition to dynamically define additional questions that
appear in the context of the answer. (For more information, see “Adding branch
conditions to questions” on page 132.)
k (optional) Click Update Library to add the question to the Questions Library.
NOTE
When you add a question to the Questions Library, conditions added to the
question are not stored with the question in the Questions Library.

l Specify the order in which the questions will appear in the SRD (when it appears
in the Request Entry console) by selecting the question and clicking the Up and
Down buttons.
m To remove a question from the list of available questions, select it from the
navigation tree and click Delete.
10 Click Next.
11 Go to “Completing the Fulfillment Process section” to continue the procedure.
12 On the Fulfillment Process - Mappings panel, map the variables you created in the
PDT to questions, text, or Service Request form fields.
NOTE
You do not see this panel if you select a Quick Link PDT or if you select a PDT that
does not have any target mappings associated with it.
a Select one of the variables.

b In the Mapping Details area, complete one of the following steps:
defined.
Make sure that the available questions you select will map to the intended
data targets. For example, the question (“What kind of chair do you want?”)
Click Advanced Mappings to concatenate inputs. (See “Concatenating
multiple inputs” on page 135.)
13 Click Next.
14 (optional) On the Fulfillment Process - Service Request Field Mappings panel, map
fields on the Service Request form to questions, text, or other Service Request form
fields.
a Select one of the fields.
b In the Mapping Details area, select one of the following options:
defined.
Make sure that the available questions you select will map to the intended
data targets. For example, the question (“What kind of chair do you want?”)

Completing the Approvers section
Click Advanced Mapping to concatenate data into one SR field. (See
“Concatenating multiple inputs” on page 135.)
c Click Apply.
d Map other fields as needed.
15 Click Next.
16 Go to “Completing the Approvers section” to continue the procedure.
Completing the Approvers section

To complete the Approvers section
1 On the Approvers panel, select who must approve the service request when it is
submitted.
NOTE
When creating a requestable service using the Service Request Designer, the
default approval process of Set Using Approval Engine is used for approving the
requestable service. If you use the Service Request Definition form to create
requestable services, more options are available for approving the requestable
service.
In the Approval Type field, choose one of the following:

is submitted.
Manager—Enables you to specify how deep you want to go in the management
levels is 5.
defined in the People form. Click Select to search for any user available in the
People form.

Custom—Enables you to use a custom approval chain (not one of the approval
chains installed with the application). This custom approval chain definition
must have a Selection Criteria that matches the requestable service. For
information about approval chains, see “Approvals for service requests” on
page 219.
NOTE
Approvals for the SRD use the default approval process, which is determined by
the Service Request Definition form. See “Defining service request definition
settings” on page 173.
2 Click Next.
3 Go to “Completing the Entitlements section” to continue the procedure.
Completing the Entitlements section

To complete the Entitlements section
1 (optional) On the Packages panel, associate one or more packages with the SRD:
a To associate a package, select it from the Available Packages table, and click
Add.
You can also drag and drop packages from the Available Packages table to the
Associated Packages table.
Packages that are related to the Company for this SRD are listed in the Available
Packages table.
b To filter the packages listed in the Available Packages table, enter a word or
string in the Search field, and press Enter.
2 Click Next.
3 On the Entitlements panel, select which users are entitled to view and request the
service.
Add or remove entitlements to the requestable service as needed. See “Selecting
entitlement information for an SRD” on page 141.
4 Click the Manage Entitlements button to create or modify an entitlement.
You can view this button only if you have Entitlements Administrator permission.
For more information, see “Configuring packages and entitlements” on page 239.
5 Click Next.
6 Go to “Completing the Options section” to continue the procedure.

Completing the Options section
Completing the Options section

To complete the Options section
1 On the Hide/Show Details panel, select which items are visible to users when they
request this service.
Section Field Description

Review a Service Turnaround Time Defines turnaround time for this requestable service in
Hours, Days, Months, or Years in the Review a Service
stage. Turnaround time is used to calculate the expected
completion date of the service request.
Note: To calculate the expected completion date
accurately, business hours and holidays must be
configured. For information about configuring
Price Actual price of the service request.
Provide Information Expected Completion Date when the user can expect the request to be finished.
Date Required Date when the user requires the request to be finished.
Phone Phone number of the user.
Email Email address of the user.
Attachment Enables users to add an attachment to the service
request.
Instructions Instructions that you want requesters to view.
Requesters see your text in the Provide Information
stage when they are requesting a service in the Request
Entry console.
Quantity Number of items for the request, such as the number of
items in a purchase request.
View a Request Service Coordinator Name of service request coordinator overseeing the
request.
Approvals Shows the Current Approvers section on the Request
Entry console. This section lists the approvers for the
selected request and includes a More Info link that
allows users to see the approvals for the request.
Additionally, the Approvers tab becomes visible on the
Request Details form.
Request Details End User Process View Shows the Process View tab on the Request Details form.
If you clear this field, the Process View tab is hidden
from users who do not have Service Request User or
SRM Administrator application permissions.
2 Click Next.

3 On the Notifications panel, specify the states when notifications for the service
request are sent to users.
By default, the following actions trigger notifications:
Notify End User on Complete
Notify End User on Pending
Notify Assignee on Assignment
Notify Approver on Waiting Approval
You can add additional states (for example, Notify End User on Submit).
4 Click Next.
5 Go to “Completing the Deployment section” to continue the procedure.
Completing the Deployment section

To complete the Deployment section
1 On the Submit Service panel, enter the service deployment start and expiration
dates.
2 Select the company and name of the Request Catalog Manager to review the
service request.
Specify the user with Request Catalog Manager permissions who must first review
and approve the requestable service before it is deployed to the organization.
By default, these fields are set to the user creating the requestable service. Before
submitting the requestable service, make sure that you set these values to that of a
Request Catalog Manager.
NOTE
When the Company field is populated, the menu attached to the Name field
consists of all users belonging to the selected Company, not just Request Catalog
Managers. Therefore, when creating the requestable service, you must know who
your specific Request Catalog Manager is, and populate these fields correctly.
3 (optional) In the Reopen Request field, select Reopen Fulfillment Process or Create
New Work Order.
Selecting Reopen Fulfillment Process:
Restarts the previous fulfillment process, if the process resulted in only one
process step, such as a single incident or change request, that has not been
closed.
Creates a Work Order, if the process resulted in multiple process steps, such
as a combination of a change request and a work order in sequence.
Selecting Create New Work Order always creates a Work Order.

Completing the Deployment section
4 (optional) To build the SRD in stages, enter all the required information, and click
Save.
You can edit the SRD as needed before submitting it for approval.
5 If you are sure that you are finished with the details of your SRD, click Submit.
After it is submitted, no further updates are permitted to the requestable service
until the approval process is complete. When it is approved, the requestable
service is deployed.
6 Click Save.


Chapter
8 Creating questions to use

with SRDs
You must create questions for users to answer when submitting service requests.
You can store these questions in a Questions Library. This section discusses the
types of questions you can create.
About creating questions to use with SRDs (page 204)
Defining text questions (page 205)
Defining radio button questions (page 206)
Defining check box questions (page 207)
Defining range questions (page 208)
About menu questions (page 209)
Defining date and time questions (page 215)

About creating questions to use with SRDs

You can create questions that can appear in various formats (for example, check
boxes, menus, or radio buttons). You can also include branching options with your
questions. For example, you can create “dynamic” questions that show various
options based on answers provided to other questions. In addition, you can add
conditions to SRD questions that enable you to dynamically define additional
questions that appear in the context of the answer.
In the Questions Library form, you can define a set of questions that a user is
prompted to answer when creating a service request from the SRD. A user’s
answers to these questions enable the business service manager and task
implementers to get more information about the service request.
NOTE
When you add or update a question in the Questions Library, conditions added to
the question are not stored with the question in the Questions Library.
You map the questions you create to AOTs and PDTs. When an application
instance occurs, the responses are pushed to the corresponding fields of the
application instance form. A user’s responses are pushed to the application
instance for a particular AOT. For information about creating questions to use with
custom applications, see Integrating BMC Service Request Management with Custom
AR System Applications white paper.
You can define the following types of questions, with various branching options:
Text (see page 205)
Radio buttons (see page 206)
Check boxes (see page 207)
Status menu (see page 209)
Query menu (see page 210)
Dynamic query menu (see page 213)
Range (see page 208)

Defining text questions
Defining text questions

Text questions appear in the Request Entry Console as a single or multiple row text
field.
To define text questions

tab.
Application Configuration > Define Questions Library, and click Open.
3 In the Question Text field on the Questions Library form, enter a question for users.
You can enter up to 254 characters.
field, use encoded text (&gt for >, and &lt for <); otherwise, browsers will interpret
the greater than and less than signs as valid HTML markup if the question text is
included in a URL.
NOTE
If you are passing the values from a text question from BMC Service Request
Management to a fulfillment application (such as BMC Remedy Incident
Management), make sure you set the proper field length values. Otherwise, you
might see errors in the CAI events trying to create records in the fulfillment
applications. This can occur when data from one of the fields in the service request
is too long. For example, trying to pass 254 characters to a field that only accepts
100 characters. For more information, see the troubleshooting tips section in the
BMC Service Request Management User’s Guide.
4 In the Question Format field, select Text.

5 (optional) In the Category field, select or enter the category that you want to apply
to the question.
Questions Library. Then, when you select a question from the library in the
Question Management form (which you open from an SRD), you receive lists of
questions by category instead of one long list of questions. For example, you might
categorize questions for each backend application.
6 In the Number of Text Rows field, specify how many lines are used in your
question.
If you enter 1, the Text field appears in the Request Entry form as a single-line
input field. If you enter 2, the Text field is two rows in height, and so on.

7 In the Limit Input Length To field, specify the amount of characters that a user can
enter.
This field is important for fulfillment application mapping if the fields are limited
in input length. The field will accept a maximum of 3600 characters. (The
maximum is limited to 1000 characters on Chinese, Japanese, and Korean views.)
By default, for a single-line question, users can enter as many as 128 characters. For
questions with an undefined number of rows or multiple rows, the limit is 3600.
8 Click Save.
Defining radio button questions

Radio button questions appear in the Request Entry Console as single selectable
buttons.
NOTE
You can create as many radio buttons as you need for each question.
To define radio button questions

tab.
included in a URL.
4 In the Question Format field, select Radio Buttons.
to the question.
6 In the Displayed Value field, enter the value that appears to users (for example,
Accounting).
7 In the Actual Value field, enter the value stored in the database.
8 Click Add.

Defining check box questions
9 Repeat step 6 through step 8 for each option you want to add.
10 Click Save.
Defining check box questions

Check box questions appear in the Request Entry Console as multiple selection
check boxes. Users can select as many check boxes as needed.
To define check box questions

tab.
included in a URL.
4 In the Question Format field, select Check Boxes.
to the question.
Accounting).
7 In the Stored Value field, enter the value stored in the database.
8 Click Add.
10 Click Save.

Defining range questions

Range questions appear in the Request Entry console as a slider bar where users
move the slider left or right to indicate their answer.
TIP
When specifying a range of values for a range question, specify a range that covers
a maximum of 20 discrete values. To allow users to enter a wider range of values,
use a text question type.
To define range questions

tab.
3 In the Question Text field on the Questions Library form, enter a question for users
(for example, Quality of Food).
included in a URL.
4 In the Question Format field, select Range.
to the question.
6 In the Minimum Label field, enter the value that appears to users (for example,
Low).
7 In the Minimum Value field, enter the smallest range value (for example, 1).
8 In the Maximum Label field, enter the value that appears to users (for example,
High).
9 In the Maximum Value field, enter the largest displayed value (for example, 10).
10 Click Save.

About menu questions

You can create the following types of menus:
Static—Shows a menu from which users can select values. For more
information, see “Defining static menu questions” on page 209.
Query—Shows a menu users based on data from a form in the application.
Menu values shown on the Request Entry console can depend on answers by a
user to a previous question. For example, you can use the Query Builder to select
a value from Questions Library field ('Status' = <Restaurant Status>).
A query menu inserts a menu on the Request Entry console that queries other
forms in the system and lists values that users can select from. Query menus
depend on their underlying data. You must select the field from the form that
the data will come from.
When you are creating a service request definition (SRD), you can even build a
dynamic menu that has multiple dependencies. This type of menu uses the
answers to multiple questions to retrieve data ('Status' = <Restaurant
status> AND 'Modified Date' => <Date and Time>).
For more information, see “Tips on constructing query menus” on page 213 and
“Defining dynamic query menus” on page 213.
IMPORTANT
Users must have access to the form that is being queried. If you select the
HPD:Help Desk form, but users do not have permissions to access it, the query
menu does not show any data.
Defining static menu questions

You can create static menu questions that provide a simple menu of options to
users.
To define static menu questions

tab.
included in a URL.
4 In the Question Format field, select Menu.

to the question.
6 In the Menu Type field, select Static.
Accounting).
8 In the Stored Value field, enter the actual value stored in the database (for example,
Calbro Accounting).
9 Click Add.
11 Click Save.
Defining query menu questions

You can create query menu questions that insert a menu on the Request Entry
console that queries other forms in the system and lists values users can select
from.
To define query menu questions

tab.
included in a URL.
to the question.
6 In the Menu Type field, select Query.
7 In the Form Name field, select a form (for example, AP-Sample:Restaurant).

8 In the Display Label field, enter the name of a character field that appears on the
form (and not a selection drop-down list).
9 In the Actual Value field, enter the name of a character field that appears on the
form, (and not a selection list), that represents the value stored in the database.
10 To define a qualification, click Query Builder to open the Query Qualification
Builder.
If you do not create a qualification, the query menu shows all restaurant records
from the AP-Sample:Restaurant form.
For more information, see “Building a query in the Query Qualification Builder”
on page 211.
TIP
To restrict the number of records returned from your query menu in the Request
Entry console, use the Query Builder to qualify your search. For example,
'Status' = "Active" returns a manageable subset of possible records.
11 Click Save.
Building a query in the Query Qualification Builder

To build a query the Query Qualification Builder, enter information in the
Qualification field by using the following fields. (You cannot manually edit the text
in the Qualification field.)
Fields on Selected Form—Select a field from the list. (Qualifications support
only fields storing data as strings.)
Question—Select a question, and user’s response will be used in the
qualification.
Text—Enter the text you want included in the qualification. Then, from the
menu next to the Text field, select the option that corresponds to the type of text
you want to enter:
Text—Enables you to enter text.
Integer—Enables you to enter numerals that are treated as integers.
Finally, to enter the text, click Add.
Syntax buttons—Click on the appropriate button to enter syntax.
Keywords—Select a keyword from the list.
As you select the options, they are entered in the Qualification field.
Click the Undo button to undo your actions. (You can undo only the last action.)
Click Clear to delete the entire qualification and start over.

Testing query menus

Use the following steps to test your static query menu.
NOTE
This procedure assumes that you already know how to create application
templates, AOTs, PDTs, and SRDs.
To test query menus

1 Create a work order template.
2 Create an AOT that registers the work order template. This example adds the
Detailed Description field to the target data.
3 Create a PDT that consumes the AOT.
4 Create and deploy an SRD.
5 Request the service from the Request Entry console.
6 Choose the static query menu in the Provide Information panel, and select an item.
Figure 8-1: Static query menu displayed in service request
When you select a restaurant (for example, Le Chef) and submit the request, this
value is entered to the Detailed Description field in the work order.

Tips on constructing query menus

Make sure your users have the correct permissions to access information. The
list of forms in the Form Name field shows all forms that include data, regardless
of multi-tenancy or permissions. As a result, requesters must have access to the
form selected from the Form Name field for the question to work. For example,
if you select CHG:InfrastructureChange from the Form Name field, but a user
who is logged in to the Request Entry console does not have Change User
permissions, no data appears on that menu for that user.
Select the form that contains the set of values you need to view. If your form has
a list of unique values for a field, you can construct a query menu question to
return those values from the query. If you cannot find a form that returns
desired the values from a dynamic query, you must create it.
Select a character field from a primary form that has one value for each record
(a one-to-one relationship). Avoid using join forms because these typically have
one-to-many relationships and appear in the Request Entry console as duplicate
entries.
When you query the AP-Sample:Restaurant form to retrieve a list of restaurants,
for example, the query returns all the records. Each record is for a different
restaurant name, and so there is no duplication.
Defining dynamic query menus

If you are creating a query menu while creating a service request definition (SRD)
(as described in Chapter 6, “Creating service request definitions”), you can create
a dynamic query menu, which is an extension of a query menu. You can create a
question that depends on the answer to a previous question. For example, after
you select a restaurant, you select the cost of that restaurant.
NOTE
You cannot define dynamic query menus (that is, menus with dependencies) from
the Questions Library. You can define dynamic query menu dependencies when
defining a question for a specific SRD only.
To avoid circular results, do not create a dynamic query menu that depends on the
answer of another question, which similarly requires an answer from the original
question. For example, Question 1 should not depend on the answer to Question 2
if Question 2 requires an answer from Question 1.

To define dynamic field menus

1 Open an SRD.
For the types of searches available, see “Searching for SRDs” on page 158.
to modify.
2 After you enter a PDT in the Process Template field, click the Questions &
Mappings button under the Process Template field.
See “Adding a PDT to an SRD” on page 125.
3 On the Question Management form, click Add Question.
4 In the Question Text field, enter a question for users.
included in a URL.
to the question.
7 From the Menu Type list, select Query.
8 From the Form Name field, select the form from which to show the answers (for
example, AP-Sample:Restaurant).
9 From the Display Label field, select the field associated with the form.
10 A default value is entered in the Menu Label field.
11 (optional) Edit the Actual Value field.

Defining date and time questions
12 To construct a qualification:
a Click Query Builder.
b Using the fields and buttons in the dialog box, enter a qualification in the
Qualification field.
From the Question drop-down list, you can select a question that is already
defined in the SRD. The data you retrieve depends on the response to the
question you select in the Question field.
For example, you might define a question (Restaurant Location) that uses a
dynamic query menu. The menu queries the Restaurant Locations form with
this qualification:
'Restaurant' = <Restaurant Example>
The menu for the Restaurant Location question will list all locations for the
restaurant specified in the preceding Restaurant Example question. Without a
qualification, all locations are listed, regardless of the restaurant selected.
c Click Select.
NOTE
Do not add dynamic query menu questions to the Questions Library.
Defining date and time questions

Date and time questions appear in the Request Entry Console as a calendar field
next to the response field for user selection.
To use custom date formats in answers to questions in service requests, users must
enter the custom date/time format on the Locale tab on the AR System User
Preferences form. (The administrator can also set the date format.) Both date and
time must be included and separated by a semicolon:
date; time
For example:
yyyy/MM/dd; HH:mm
For more information about setting user preferences, see the BMC Remedy Action
Request System Configuration Guide.

To define date and time questions

tab.
included in a URL.
to the question.
5 In the Question Format field, select Date/Time, Date, or Time.
6 Click Save.

Chapter
9 Configuring approvals
This section describes how to configure approvals for service request definitions
(SRDs) and service requests. Configuration tasks are performed from the
Application Administration Console.
NOTE
You must have the SRM Administrator permission to configure BMC Service
Request Management approvals.

Approvals and the Approval Server (page 218)
Creating individual and group approvers (page 218)
Approvals for service requests (page 219)
Approvals for SRDs (page 230)
Configuring the Request ID link in Approval Central (page 238)

Approvals and the Approval Server

The approval process configuration data for managing service requests and SRDs
are tightly integrated with the BMC Remedy Approval Server. The Approval
Server is shipped with BMC Remedy AR System and should be installed on the
same computer as BMC Service Request Management.
Creating individual and group approvers

Before you configure the approval process, you must ensure that the approvers are
defined in the system. When defining approvers, remember these tips:
You can add individuals or support groups as approvers.
Group approval requests are sent only to group members with the Request
Approver or SRD Approver roles.
If an individual approver is needed, only people defined in the People form can
be chosen as approvers.
To create individual and group approvers

tab.
2 From the Application Settings list, choose Foundation > People > People, and click
Open.
3 In the People form, enter the person’s information.
4 To include the person as a group approver, define the person as a member of the
Support Staff.
5 In the Application Permissions area of the Login/Access Details tab, give the
person the required BMC Service Request Management permissions (for example,
Service Request User).
NOTE
The minimum requirement in BMC Service Request Management to approve
service requests is being registered as a user in the People form. Users with this
level of access can view service requests in the Request Entry console, but they
must use Approval Central to approve them.
6 To include the person as a group approver, in the Functional Role Update tab of
the Update Support Group Membership and Roles form for support groups, give
the person the Request Approver or SRD Approver support roles.

Approvals for service requests
7 Add any other permissions as necessary.

For more information, see:
“Creating individual mappings to work with level-type approval processes” on
page 225
“Creating group mappings to work with level-type approval processes” on
page 227
BMC Remedy IT Service Management Configuration Guide
8 Click Save.

After you create individual and group approvers, you can set approvals for service
requests. To use the default approval processes that are configured for BMC
Service Request Management, select the one of the following Approval Type
options on the Service Request tab when creating an SRD:
is submitted.
Manager—Enables you to specify how high you want to go in the management
levels is 5.
defined in the People form.
For more information, see “Setting approvals for the service request” on page 138.
To set up custom approval processes, you must create a custom approval chain
(See “Configuring a custom approval chain” on page 219.) Then, choose Custom
from the Approval Type field on the Service Request tab when creating an SRD.
This option uses the custom approval chain you create.
Configuring a custom approval chain

For service requests, you can create a custom approval chain to chain different
kinds of approval processes together so that they occur one after the other in
sequence. For example, you can configure an approval chain so that a service
request must be approved first by the user’s manager, and then it moves up the
chain to the second approval process (for example, the level approval process so
that a mapped approver must approve the service request when it reaches Waiting
Approval status).

You can configure BMC Service Request Management so that one service request
uses a particular approval chain, but another service request uses a different chain.
You can set workflow actions that occur when a particular result is returned from
an approval process:
Set Fields action—You can set values to fields on the application request (using
a “Set Fields” action).
Next Process action—You can add another approval process, including up to
five total processes in a chain.
Furthermore, you can run multiple actions for a particular approval result. For
example, you might set certain field values in the service request and run another
approval process in the approval chain.
To configure a custom approval chain

tab.
2 Choose Service Request Management > Approval > Approval Chains, and click
Open.
3 From the Approval Chains form, click Create.
The following approval chains are installed with BMC Service Request
Management:
SRM:Request_Mgmt Chain 1_SYSTEM
SRM:Request_Individual_SYSTEM
SRM:Request_Group_SYSTEM
To ensure that default approval processes work properly, do not modify these
approval mappings.
4 In the Name field on the Approval Chain Definition form, enter a name for the
approval chain.
6 From the Form Name list, select SRM:Request.
7 In the Company field, select -Global-, or select a specific company that will use this
approval chain.
This name maps to the name specified in the Company field on the Delivery tab of
the SRD.

8 Select a Status.
Leave the status Offline until you are ready to deploy it; otherwise, you might see
unexpected results. Then, set the status to Enabled so that the approval chain can
be executed.
9 In the Selection Criteria field, enter a qualification for the service requests you want
the approval chain to apply to:
a Click the browse button (...) next to the Select Criteria field.
b In the Service Request Approval Selection Criteria dialog box, enter information
in the appropriate fields.
You can enter values in the fields. For example, if you enter Facilities in the
Category 1 field, the approval chain applies to all of the service requests in the
Facilities navigation category.
You can also enter a qualification to narrow the criteria further. For example,
you might want to enter a qualification for a specific field.
c Click Select.
10 In the Order field, enter an order for the approval chain.
The Order field controls the order in which the approval criteria are evaluated for
a request.
Select 0 for the most restrictive selection criteria, and select successively higher
order values as the selection criteria becomes less restrictive.
The following is an example of selection criteria defined for a more restrictive to
less restrictive order:
Order Selection Criteria
0 ‘Status’ = “Waiting Approval” AND ‘SRD_Level’ = “Gold” AND
‘Price’ >= “1000.00
1 ‘Status’ = “Waiting Approval” AND ‘SRD_Level’ = “Gold”
2 ‘Status’ = “Waiting Approval”
11 To add a process to the approval chain:

a From the Process Name list under the Add Process panel (at the right), select a
process:
Service Request - Level—Uses approver mappings to determine approvers.
See “Creating approver mappings” on page 223.
Service Request - Management Chain—Uses a user’s management chain to
determine approvers.
Service Request - Ad Hoc—Specifies the initial approver as the manager of
the user who is requesting the service. It is up to the manager to specify the
next approvers before he or she approves the service request.
b If you select Service Request - Management Chain, enter the maximum number
of levels for approval.

c Click Apply.
The approval process is added to the chain with four possible approval statuses:
Approved
Rejected
Cancelled
Error
You can define an action for some or all of the possible statuses by adding
another process to the approval chain (step 12) or by adding a Set Fields action
(step 13).
12 To add another process to the approval chain:
a Select an approval status in the approval chain tree (for example, Approved).
b In the Add Process section, select a process from the Process Name list.
c Click Apply.
The process is nested under the approval status you selected.
13 To add a Set Fields action to the approval chain:
a Select an approval result in the approval chain tree (for example, Approved).
b Click the Add Set Fields Action panel header (on the right side), and click Apply.
c Select the new Set Field in the approval chain tree, and click Add.
d In the Set Field Value dialog box, select a field from the form (for example, select
the Status field or Status Reason field to enter information about the service
request).
e In the Value field, enter the value you want to set in the field.
f Click Save.
14 Click Save to save the approval chain.
15 If you created any Level approval processes, create approver mappings.
See “Creating approver mappings” on page 223.
16 To use the approval chain in an SRD, set the Approval Type to Custom on the
Service Request tab of the Service Request Definition form. (See “Setting approvals
for the service request” on page 138.)

Creating approver mappings

To use the Level approval processes for service requests and SRDs, you must
create approver mappings. As shipped, the default Service Request approver is the
requester’s manager, which is based on the requester’s manager information
defined in the People form. The default SRD approver is the Request Catalog
Manager.
Use the Approver Mappings form to set up individuals and support groups as
approvers for each approval phase of service requests or SRDs, based on the
approval process defined in the Approval Process Configuration form.
NOTE
Only default group chains, custom chains, and Service Request Definition - Level
rules use the information in the Approval Mappings form. (For information about
custom chains, see “Configuring a custom approval chain” on page 219.)
To set up approver mappings, complete these tasks:
Step 1 Map approvers to approval phases. See “Mapping approvers to approval phases
for level-type approval processes” on page 223.
Step 2 Create individual or group mappings:
Create individual mappings. See “Creating individual mappings to work with

level-type approval processes” on page 225.
Create group mappings. See “Creating group mappings to work with level-type
approval processes” on page 227.
Create inherent group mappings. See “Creating inherent group mappings” on
page 229.
Mapping approvers to approval phases for level-type

approval processes
The following procedure describes how to map approvers to approval phases for
Level approval processes.
To map approvers to approval phases

tab.
Approval > Approval Mappings, and click Open.
The Approver Mappings form appears in New mode. The Additional Mappings
area of the form is empty until you select an item in the Approval Indicator field.

3 Enter information in the following fields:
Field Action and description

Approval For Select the type of approver:
Individual—If you select this option, enter the individual’s last
name and press ENTER. The Approver ID (or login name) is
automatically completed. See “Creating individual mappings to
work with level-type approval processes” on page 225.
Group—If you select this option, the First Name, Last Name, and
Approver ID fields are replaced by Support Company, Support
Organization, and Support Group Name.
Select values for each field. The items that appear in the Support
Organization list depend on the option you select for Support
Company. The items that appear in the Support Group list depend
on the option you select for Support Organization. See “Creating
group mappings to work with level-type approval processes” on
page 227.
Inherent Group/Role—If you select this option, the Inherent Group
and Functional Role fields appear. See “Creating inherent group
mappings” on page 229.
Note: If you select the Group option, all people who belong to the
support group and have the Request Approver or SRD Approver
functional role are set up as approvers. By default, only one
approver in the group must sign off on the approval before it can
move to the next state, as described in “Creating group mappings to
work with level-type approval processes” on page 227. For
information about modifying the If Multiple Approvers setting in
the AP:Administration form, see the information about roles in the
BMC Remedy Action Request System BMC Remedy Approval Server
Guide.
First Name If you select Approval For Individual, this field appears.
Note: Enter part of first name of the approver and press ENTER to
quickly enter the approvers name.
Last Name If you select Approval For Individual, this field appears. Use auto-fill
to enter the approver’s last name.
Approver ID If you select Approval For Individual, this read-only field appears.
The Login ID of the approver automatically is included when you
select the approver.
Assignment Select Yes or No to indicate if the individual or group is available for
Availability the assignment.
Status Indicates the current status of the group or individual approving the
service request or SRD.
For the approver mapping to be available, select a status of Enabled.

Field Action and description

Approval Select which form this approver mapping will affect.
Indicator For BMC Service Request Management, select one of the following
options to create approver mappings:
Service Request
Service Request Definition
When you select either of these options, the Mapping Criteria tab
appears under Additional Mappings. This enables you to map the
approver to a category-cost combination.
Phase Company Phase company for this approver mapping.
This option maps the approval phase to the approver.
Phase Name When you select a phase name, the Phase Company field is
automatically filled.
Note: These phase name values are filled from the enabled approval
process configuration data in the Approval Process Configuration
form.
Level Specify the level of approval for the individual or group.
Description (optional) Enter a description for this approver mapping.
4 Click the Mapping Criteria tab to add additional criteria for navigation tiers, SRD
information, and so on.
The Individual or Group approver defined is used only for service requests and
SRDs matching this criteria.
5 Click Save.
Creating individual mappings to work with level-type

approval processes
This section describes how to configure individual approver mappings to work
with the application.
To create individual mappings to work with Level approval processes

1 (For SRD approvals only) Enable the Service Request Definition - Level phase.
a From the Application Administration Console, click the Custom Configuration
tab.
b From the Application Settings list, choose Foundation >Advanced Options >
Approval Process Configuration, and click Open.
c In the Approval Process Configuration form, search for the
SRD:ServiceRequestDefinition form name.
The two SRD approval process configuration records appear.
d Select the Service Request Definition - Ad Hoc approval configuration record,
and select Offline for the status.

e Select the Service Request Definition - Level approval configuration record, and
select Enabled for the status.
This enables you to select the Service Request Definition - Level phase when you
create an approver mapping.
f Save and close the form.
2 From the Application Administration Console, choose Service Request
Management >Approval > Approval Mappings, and click Open.
3 In the Approval For field, select Individual.
NOTE
To map an individual approver, you can select any individual who has a record in
the People form. It is not necessary to select a person with the SRD Approver
functional role (for example, Allen Allbrook). This example uses Ian Payment.
4 In the Approval Indicator field, select which form this approver mapping will
affect (for example, Service Request Definition).
5 In the Phase Name field, select which approval phase needs mapping in the
application (for example, Service Request Definition - Level).
6 Enter the remaining required information.
Depending on which mapping values you specify, different approvals are
generated.
When approver mappings are created, you do not need to enter values in all the
fields on the Approver Mappings form.
Individual approval is generated on the basis of the approver mapping values at
the top of the form and any optional values at the bottom of the form (for example,
if you enter a navigational category). Ian Payment is the approver for all Service
Request Definition - Level processes if none of the additional mapping values are
defined.
You can create multiple approver mappings. For example, you can configure a
different approver to approve SRDs that are “gold” level and cost over $500.00.
7 Save and close the form.
For SRDs, if you have not created any other approver mappings, when an SRD is
promoted to the Request for Approval state, the SRD cannot be deployed until the
individual you set in this procedure approves the request.
In addition, you can create a multiple-level approver mapping—where both Allen
Allbrook and Ian Payment must approve the SRD before it can move to the next
state. Here you could set Allen Allbrook as 0 level and Ian Payment as 1. In this
example, Allen Allbrook must approve the SRD first. The Approval Server
generates a second approval for Ian Payment.

Creating group mappings to work with level-type

approval processes
This section provides an example of configuring group approver mappings to
work with BMC Service Request Management.
To create group approvers for SRDs, users must be members of the same support
group (for example, IT Hardware), and an approver must have the SRD Approver
functional role. When an SRD requires group approval, one group member must
approve the SRD before it can move to the next stage.
NOTE
When an approver list includes functional roles (for example, the SRD Approval
functional role), specific settings in the AP:Role form in the Approval Server
determine whether the role is expanded to individual signature-line records for
each member of the role, or a single signature-line record is created for the entire
role.
In the Approval Server integration with BMC Service Request Management, the
SRD Approval functional role maps to the SRD Approver role name in the Role
form. (Select AP:Administration from the IT Home page. From the Role tab, select
a role, and click View.) In the SRD Approver role, group approvals by default
require that only one member of the support group must sign the approval to move
the SRD to the next stage. For information about how the All Must Sign and If
Multiple Approver settings are used in the Approval Server, especially if you
require all members of a group to approve the request, see the BMC Remedy
Approval Server Guide.
To create group mappings to work with level-type approval processes

1 (For SRD approvals only) Enable the Service Request Definition - Level phase.
a From the Application Administration Console, click the Custom Configuration
tab.
b From the Application Settings list, choose Foundation >Advanced Options >
c In the Approval Process Configuration form, search for the
SRD:ServiceRequestDefinition form name.
The two SRD approval process configuration records appear.
d Select the Service Request Definition - Ad Hoc approval configuration record,
and select Offline for the status.
e Select the Service Request Definition - Level approval configuration record, and
select Enabled for the status.
This enables you to select the Service Request Definition - Level phase when you
create an approver mapping.
f Save and close the form.

2 From the Application Administration Console, choose Service Request

Management >Approval > Approval Mappings, and click Open.
3 In the Approval Mappings form, search for any individual mappings, and select
Offline for their status.
For the purposes of this example, do not combine individual and group approver
mappings.
4 To begin creating an approver mapping, select Group in the Approval For field.
5 Select a Support Company, Support Organization, and Support Group, and select
a support group that includes people with the SRD Approver functional role.
For example, the IT Hardware support group should include both Allen Allbrook
and Ian Payment.
affect (for example, Service Request Definition).
application (for example, Service Request Definition - Level).
8 Enter the remaining required information.
Depending on which mapping values you specify, different approvals are
generated.
When approver mappings are created, you do not need to enter values in all the
fields on the Approver Mappings form.
9 Click Save.
When an SRD is moved to the Request for Approval state, the SRD cannot be
deployed until the support group you set in this procedure approves the request.
To create a multiple-level group approver mapping, create another group
approver mapping for another support group, and set the Level setting to 1. After
the first support group (level 0) approves the SRD, the second level of approvers
(level 1) must approve the SRD before it can be moved to the next stage.

Creating inherent group mappings

You can select a group to be an Approval group, and then you can select a
functional role for the approval (for example, Request Approver). This
combination limits the individual approval entries to the Inherent Group.
To create inherent group mappings

tab.
Approval > Approval Mappings, and click Open.
3 In the Approval For field, select Inherent Group/Role.
The Approval Mappings form is redisplayed so that the fields to configure a group
mapping appear.
4 In the Inherent Group field, select a service request management group.
5 In the Functional Role field, select one of the functional roles defined for service
request management (for example, Request Approver).
Make sure that you select an inherent group that includes people with the
functional role.
affect (for example, Service Request).
application (for example, Service Request - Level).
When you select a phase name, the Phase Company field is automatically
populated.
8 Do not create any other mappings for now.
For example, let the Level field setting remain as 0.
9 Save the approver mapping.
If you disabled the individual approver mappings and you did not modify the
default approval configuration settings, the service request cannot be moved from
the Waiting Approval status until this inherent group/role approves the request.
NOTE
To create a multiple-level inherent group approver mapping, you could create
another inherent group approver mapping for another inherent group and set the
Level setting to 1. After the first inherent group (level 0) approves the service
request, the second level of approvers (level 1) must approve the service request
before it can be moved to the next stage.

Approvals for SRDs

This section discusses approvals for service request definitions (SRDs). It
introduces you to approval states and process types. Then, it describes the process
for configuring approvals for SRDs:
Step 1 Set whether to use the Approval Server to determine the approvers of the SRD.
(See “Defining service request definition settings” on page 173.)
Step 2 Create individual and group approvers. (See “Creating individual and group
approvers” on page 218.)
Step 3 (optional) Set up approval processes. (See “Setting up approval processes for your
company” on page 234.)
Step 4 (For Level approval processes only) Create approval mappings. (See “Creating
approver mappings” on page 223.)
Step 5 Set the approvers on the Approvals tab of the Service Request Definition form. (See
“Setting approvals for an SRD” on page 146.)
Approval states
To configure the flow of approvals, you must define what approval is required for
each state in the flow. The states of SRDs use the settings defined in Status and
Status Reason fields on the Approval Process Configuration form, which is
accessed from the Application Administration Console. (See “To set up an
approval process for your company” on page 235.)
When the Status and Status Reason fields for the SRD record matches the value
specified in the Begin column, the approval process is started. Whenever the Status
or Status Reason changes, the workflow searches the Approval Process
Configuration form to see if there are any approval mappings for the new Status
and Status Reason combination. If a mapping is found, the process name is
returned to the SRD, and the application command is issued to the Approval
Server to start the approval process.
When the approval process starts, the Status and Status Reason fields cannot be
modified. This prevents further changes to the SRD until the approver submit a
decision (approved or rejected).
Approval configuration records are mapped for SRDs by navigational categories,
price information, and so on.

Approvals for SRDs
Approval states are:

Begin—This state is an indicator to the Approval Server for starting the approval
process. For example, if you set up Pending as the Status and Approval as the
Status Reason for an SRD, the approval process does not start until the SRD
records Status and Status Reason fields match these values. The approval
process, for example, does not start when the SRD is in a Status of Draft.
Approved—Based on the rules set up in the Approval Server, if one or all
approvers have approved the SRD, the Approval Server changes the Status and
Status Reason fields values on the SRD record to match the values you
configure. At that time, the locked Status and Status Reason fields on those
records are unlocked and the requests go through the remainder of their life
cycle.
NOTE
The Approved state is based on rules set up in the Approval Server (in the Rule
Definition form). To access the Rule Definition form, select AP:Administration
from the IT Home page. From the Rule tab on the Approval Server Administration
form, select a rule, and click View. For more information about rules in the
Approval Server, see the BMC Remedy Approval Server Guide.
Rejected—Defines the values of the Status and Status Reasons fields for SRDs if
a record is rejected. For example, you might want to set the Status back to
Pending and the Status Reason to More Information if the SRD is rejected.
No Approvers—If the Approval Server does not find any of the mapped
approvers, the Status and Status Reason field values on the two forms are
changed to the values specified.
Approval state transitions

When a SRD moves from state to state, the default workflow queries the Approval
Process Configuration form to find out which approval process to use, and
executes it.
For example, when an SRD moves from the Draft state to the Service Request
Definition - Level phase, the Approval Server checks the approval process.
The Approval Server starts the approval process, and executes the rules in the
order of the approvers who are mapped to the approval phase.
The rules contain the qualifications that set up approvers for each phase of that
process, and create the approval detail and signature records for the SRD. If no
approvers are mapped to the process, the SRD moves to the next state. Figure 9-1
demonstrates this scenario.

Figure 9-1: SRD approval process
If you enabled the Service Request Definition - Level process, you must set up the
approvers using the Approver Mappings form (see “Creating approver
mappings” on page 223). This rule queries the form, using the appropriate criteria,
find the appropriate approvers, and add them to the SRD record as the approvers.
When the approver approves or rejects the SRD, the rules execute and set the next
status defined in the Approval Process Configuration form. (See “Approval states”
on page 230.) Based on the process type, the Approval Server continues until no
approvers are found for the process.
NOTE
You can configure additional processes for your company, as needed. For
example, you could create a process that SRDs require approvals when they reach
the Pending state. For more information, see “Setting up approval processes for
your company” on page 234.

Approvals for SRDs
Process types
BMC Service Request Management provides the following approval process types:
Ad Hoc
Level
These process types are used in the following default processes on the Approval
Process Configuration form:
Service Request Definition - Ad Hoc—The SYSTEM PHASE Ad Hoc approval
process for SRDs. This process provides routing authority to each approver
without requiring the administrator to create approver mappings for every
individual or role. The Service Catalog Manager is the first approver. This
person must specify the next approvers before he or she approves the catalog
offering.
By default, the status of this approval process is Enabled.
Service Request Definition - Level—Uses the data configured in the Approval
Mappings form to determine approvers. For more information, see “Creating
approver mappings” on page 223.
By default, the status of this approval process is Offline.
These “best practice” processes are based on sample data like companies and
support groups provided in the Foundation. There is no separate configuration
data for approvers. You can modify the sample processes, or inactivate them and
create approval processes and rules based on your business needs.
IMPORTANT
Do not enable both approval processes at the same time; otherwise, your approvals
will not work as described. If you want to modify the default approval settings,
enable only one approval process and set the other to Offline. (You can enable
multiple approval processes for service requests because approval chains can use
multiple approval processes. See “Approvals for service requests” on page 219.)
Company versus global approval processes

The default approval processes are designed for “global” use, and you should not
need to create additional approval configuration records.
If you need alternate process approval processes, create copies of these processes.
(Do not modify the default approval processes.) For detailed instructions, see
“Setting up approval processes for your company” on page 234.
Company-based approval processes that you create take precedence over global
approval processes. When an SRD reaches an approval phase, the Approval Server
first evaluates any company approval processes you have created and ignores the
global approval processes. If there are no company approval processes, the
Approval Server uses the global approval processes. Figure 9-2 demonstrates this
scenario.

Figure 9-2: Relationship between company records and global approval process
configuration
Setting up approval processes for your company

If you do not want to use the default approval processes, you create a copy of an
approval process (for example, the Service Request Definition - Level approval
process) and save it for your company. Then, the system automatically creates the
remaining approval processes for your company, based on the default global
settings. You can edit these approval processes as needed.
IMPORTANT
After you create company-specific approval processes, the global approval processes
are no longer functional for your company. As a result, if you disable the Service
Request Definition - Level approval process configuration record for your
company and an SRD reaches the Service Request Definition - Level phase, the
Approval Server skips the company Service Request Definition - Level approval
phase (because it is offline). The Approval Server also ignores the global Service
Request Definition - Level phase (even if it is enabled), and the service request
continues to the next state. To revert to the global processes, set all the company
approval process configuration records to offline.
You can have only one enabled approval process for global use or for each
company. For example, you might enable the Service Request Definition - Ad Hoc
approval process. You can create additional phase approval processes as needed,
but they must be offline or in another state (for example, Proposed).

Approvals for SRDs
In a multi-tenancy environment, you can combine approval processes as needed.

That is, you might decide Company A needs custom approval processes, but
Company B can use the default global processes.
Approval configuration records are mapped for SRDs using navigational
categories, price information, and so on, so you can configure several
configuration records for a category or company.
To set up an approval process for your company

tab.
2 From the Application Settings list, choose Foundation > Advanced Options >
3 In the Approval Process Configuration form, enter information in the following
fields:
Field name Location or tab name Action and description

Form Name Top of form Select a form from which requests are generated.
For BMC Service Request Management, select the
SRD:ServiceRequestDefinition form. (SRM:Request is listed
for legacy purposes. Do not use it for new process approvals.)
Note: When you select a form name, category and total cost
fields appear on the Additional Qualifications tab. You will
use these fields to map the approval configuration record to
the SRD categories for SRDs.
Company Top of form Select the company that will use this approval configuration
record.
This name maps to the name specified in the Company field
on the Delivery tab of the SRD record.
Note: BMC Service Request Management supports multi-
tenancy, which means that you can configure different
approval configuration records for different companies.
If you are defining an ad hoc approval, select Global. This
option makes sure that the service request goes to the Service
Catalog Manager of the SRD, who would either approve the
request or route it appropriately.
Status Top of form Select a status for the approval configuration record.
Select Enabled to execute this approval configuration record.
If the process should not be available in BMC Service Request
Management, select the appropriate status: Proposed, Offline,
Obsolete, Archived, or Delete.
Description Top of form (optional) Enter a description of this approval configuration
process.
Phase Name Approval Process tab Type or select a value to indicate at which phase of the request
this approval configuration record should be executed.
The phase name is associated with the company for which
this approval is being defined.

Field name Location or tab name Action and description

Process Name Approval Process tab Select the process that should be used for this approval
configuration record from the list of processes you
configured.
See “Company versus global approval processes” on
page 233.
Process Type Approval Process tab A preconfigured corresponding process type that appears
when you select the process name.
Impacts Approval Approval Process tab Select Yes or No to indicate whether this approval
Status configuration process impacts the approval status of the SRD.
Default Process Approval Process tab (optional) Select another process from the list.
Name In general, if no approvers are found for the Process Name,
the Default Process Name is checked, to see if any approvers
can be found.
If you clear the Default Process Name field, when the SRD
reaches the Service Request Definition - Level phase and
values did not match the Approver Mappings, the SRD will
not have any fallback processes to use. The SRD moves to the
next state.
Note: Do not select a process unless you specifically need one.
System Approval Approval Process tab (optional) To specify that no approvers can be mapped to this
Flag process on the Approval Mappings form, select Yes. This field
is blank by default.
Sort Order Approval Process tab (optional) If you have multiple approval configuration records
for a specific category, you can sort the execution order.
4 Click the Status Flow tab to set up the approval cycle for the specific service
catalog.
The states that appear in the Status menu lists are derived from the Status field of
the Service Request Definition form.
For example, an SRD starts in the Request for Approval state. The Begin column
indicates the state that starts the approval process.
If the SRD is approved, its Status changes to Deployed (as indicated in the
Approved column).
If the SRD is rejected, its Status changes to Rejected (as indicated in the Rejected
column). But you might decide instead that the SRD should move back to the
Pending state and that the Status Reason should be More Information, or the Status
might be Rejected and the Status Reason should be Cancelled.
You can set up the Status for an SRD if there are no approvers defined for it (for
example, Deployed, as indicated in the No Approver column).
For more information, see “Approval states” on page 230.

Approvals for SRDs
5 To create a status flow, follow these steps:

a For the Begin state, define a status and a status reason (optional).
This field specifies which status starts the approval process.
b For the Approved state, define a status and a status reason (optional).
If the SRD is approved, the Approval Server changes the status and status
reason values on the relevant form to the values you configure here.
c For the Rejected state, define a status and a status reason (optional).
If the SRD is rejected, the Approval Server changes the status and status reason
values on the relevant form to the values you configure here.
d For the No Approvers state, define a status and a status reason (optional).
If the Approval Server does not find any approvers, the Approval Server
changes the Status and Status Reason values on the relevant form to the values
you configure here.
NOTE
For more information about approval process states, see “Approval states” on
page 230.
6 Click the Additional Qualifications tab.

You can include other fields in a service request to qualify which approval process
to use for a particular request (for example, the Category 1 field or the Total Cost
of the SRD).

Configuring the Request ID link in Approval

Central
You can configure the Request ID link in Approval Central to allow approvers to
open the SRS:RequestDetails form and view information about the request they are
approving.
To configure the Request ID link in Approval Central

1 From the IT Home Page, and select Quick Links > Approval Administration
Console.
2 Click the Forms tab.
3 Select SRM:Request, and click View.
The AP:Form form appears with most of the fields completed.
4 From the Source ID Link Association field, select the Customize option
5 Complete the fields in the AP:Customize-SourceID dialog box that appears.
a In the Form Name field, enter SRS:RequestDetails.
The SRS:RequestDetails form is not in the list, so you must enter it manually.
b Leave the View Name field as is.
c From the Display Mode list, select Dialog.
d For Field 1, select Request Number, or enter $Request Number$.
e Click OK.
6 Click Save.
For more information, see the BMC Remedy Action Request Approval Server Guide.

Chapter
10 Configuring packages and

entitlements
Entitlement enables you to define which users can access service request
definitions (SRDs). Entitlements are defined using the Entitlement Console, and
added using the Entitlements tab of the Service Request Definition form.
You can group several SRDs into a “package,” and create an entitlement rule for
that package. This is useful when you use multi-tenancy, where you are managing
SRDs for more than one company.
Enterprise customers, or companies using multi-tenancy, should find entitlements
helpful in their organizations, so that users can view only the available services to
which they are entitled. Small or medium-sized companies might not need to add
this extra level of access control provided by entitlement.
NOTE
You must have the Entitlement Administrator or SRM Administrator permission
to configure entitlements.

Overview of configuring entitlement (page 240)
Creating packages (page 240)
Enabling entitlement (page 242)
Creating entitlement groups (optional) (page 243)
Creating entitlement rules (page 244)
Validating users (optional) (page 246)

Overview of configuring entitlement

The entitlement configuration process involves the following steps:
Step 1 Create packages.
Step 2 Enable entitlement. (See page 242.)
Step 3 Create entitlement groups (optional). (See page 243.)
Step 4 Create people entitlement definitions. (See page 244.)
Step 5 Add service request definition qualifications for entitlement. (See page 245.)
Step 6 Validate users (optional). (See page 246.)
Step 7 Select entitlement information to your SRDs. (See page 141.)
Step 8 Create on-behalf-of qualification rules for users (optional). (See page 58.)
To open the Entitlement Console, choose Service Request Management >

Entitlement > Entitlement Management from the Application Administration
Console. You can then open entitlement forms using links on the navigation pane.
Creating packages
To make entitlements for SRDs easier to manage, you can create packages, which
can contain one or more SRDs. You can relate only one company to each package.
For example, if you create a package for Calbro, you cannot relate Acme Company
to that package.
When you give a company access to a package, the company automatically has
access to all SRDs associated with the package.
To create a package
1 Open the IT Home Page, and click the Service Catalog Manager Console link.
2 Click the Functions link in the left navigation pane, and click Package
Management.
3 Click the plus sign (+) icon at the top of the Package Management window.
4 In the Name field, enter a name for the package.
Package names must be unique for a company. Do not enter a name that is the
same name as another package already created for the same company.
5 (optional) In the Description field, enter a short description of the package.

Creating packages
6 From the Company field list, select the company to which the package will be
related.
All global SRDs and all SRDs for the selected company are listed in the Available
Requestable Offerings (SRDs) table.
7 In the Package Group field, enter or select a package group for this package.
For the first package that you create, the list is empty and you must manually enter
the name of the group. For all subsequent packages, you can select an existing
group from the field’s menu list or manually type the name of a new group into
the field.
A package group can belong to only one company.
8 To associate an SRD with the package, select it from the Available Requestable
Offerings (SRDs) table, and click Add.
You can also drag packages from the Available Packages table to the Associated
Packages table.
To filter the SRDs listed in the table, enter a term (from the SRD name) in the Search
field, and press Enter.
NOTE
To prevent SRDs from multiple companies being added to a package, the
Company field is set to read-only after you add the first SRD. The Company field
remains read-only when you edit the package.
9 Click Save.
Editing packages
You can make changes to the packages that you create.
To edit a package
Management.
3 Select the package that you want to modify.
4 Click the pencil icon at the top of the Package Management window.
5 Modify the Name, Description, and Package Group fields as needed.
6 Add or remove SRDs as needed from the Selected Requestable Offerings (SRDs)
table.
7 Click Save.

Deleting packages
You can delete a package that you have created. When you delete a package, all
entitlement rules that reference the package are deleted.
To delete a package
Management.
3 Select the package you want to delete.
4 Click the minus (-) icon at the top of the Package Management window.
5 Click Yes to confirm that you want to delete the package.
6 Click Save.
Enabling entitlement
Before you enable entitlement, create rules for users to access their SRDs.
Otherwise, after you enable entitlement, users cannot access their SRDs. Before
you create entitlement rules, you might want to create a temporary entitlement
rule specifying Everyone in the People Qualification Name field so that everyone
can access their SRDs until you finish creating entitlement rules for all users.
Everyone is predefined and cannot be changed.
To enable entitlement
tab.
Entitlement > Entitlement Management, and click Open.
3 To enable entitlement, select the Enabled option from the Entitlement Console.
You can create entitlement groups and rules from this console.
4 In the Apply Entitlement Rules to Global SRDs field, specify whether entitlement
rules apply to global SRDs.
If you select No (the default), entitlement rules do not apply to global SRDs. All
users can request Global SRDs. The assumption here is that global SRDs are
intended for all users and should not be limited by multi-tenancy.
If you select Yes, any entitlement rules defined for SRDs also are either directly
or indirectly applied to global SRDs.

Creating entitlement groups (optional)
NOTE
You can still create exceptions if you use Advanced Qualifications when you create
entitlement rules for People or SRDs. In your environment, you might not want to
see global SRDs for one specific company, for example, a managed service
provider (MSP) vendor. For more information, see “Create people entitlement
definitions” on page 244 or “Adding service request definition qualifications” on
page 245.
Creating entitlement groups (optional)

Entitlement groups enable you to define standard entitlement definitions that you
can associate with specified groups of users.
TIP
As an alternative to setting up entitlement groups, you can create people
entitlement definitions by company, login ID, or location (region, site group, and
site).
To add an entitlement group

tab.
Entitlement > Entitlement Group Management, and click Open.
3 From the Entitlement Group Management form, click the Create button.
4 Select a company, and enter an entitlement group name and description.
5 Click Save.
6 To add a user to the group, select the entitlement group you just added, and click
the Add button under the Entitlement Group Users table.
7 In the People Search form, select a person to add to the group, and click Select.
The person you selected appears in the table.
NOTE
When you add users to an Entitlement Group, you must flush the Entitlement
Cache before the user can see any SRDs visible to the Entitlement Group. After the
cache is cleared, users must reopen the Request Entry console to see any changes.
For more information, see “Validating users (optional)” on page 246.

Creating entitlement rules

Entitlement rules associate people qualifications with service request definition
qualifications.
NOTE
To increase performance, entitlement rules are cached. Although the entitlement
cache is flushed when an entitlement rule is created or modified, users must
reopen the Request Entry console to see any changes.
Create people entitlement definitions

People qualification management enables you to group people together by
creating people entitlement definition that you can associate with specified
entitlement SRD rules.
To create people entitlement definitions

tab.
3 From the Entitlement Console, click the Create button (located under the table.)
4 From the Entitlement Rule form, select the Exclusion Rule option to exclude users
from access.
5 Click the Create button under the People Qualification Name field.
6 From the People Qualification for Entitlement form, select the status.
The default setting is Enabled.
7 Enter a name for the people qualification, such as:
Company—Company name
AR Username—Login ID
Entitlement Group—Entitlement group description
Location—Region, site group, site
Advanced Qualification—Description of the qualification
TIP
An advanced qualification lets you create exceptions with global SRDs. For
example, you might exclude global SRDs for one specific company, such as an MSP
vendor.
8 Select the Company, AR Username, Entitlement Group, Location, or Advanced

Qualification option, and select or enter a value.
9 Click Save.

Creating entitlement rules
Adding service request definition qualifications

SRD qualification management enables you to group SRDs together by creating
SRD entitlement definitions that you can associate with specified entitlement
people rules.
To add a service request definition qualification for entitlement

1 On the Entitlement Rule form, select a People Qualification Name you added
previously.
2 Click the Create button (located under the SRD Qualification Name field).
The SRD Qualification for Entitlement form appears.
3 From the SRD Qualification for Entitlement form, select the status.
The default setting is Enabled.
4 Enter a name for the SRD qualification.
5 Select one of the following options:
Category of SRD
SRD Level
Specific SRD
Specific Package
Advanced Qualification
6 For the option that you selected, perform one of the following steps:
Select one or more categories.
Select a specific SRD.
Enter or select an SRD level.
Select a package.
Enter an advanced qualification.
NOTE
An advanced qualification lets you create exceptions with global SRDs. For
example, you might exclude global SRDs for one specific company, such as an MSP
vendor.
7 Click Save.

Validating users (optional)

After creating entitlement rules and qualifications, you can validate user access to
SRDs. You can also use user validation to troubleshoot entitlement problems.
To validate users
tab.
3 From the left navigation pane of the Entitlement Console, click Other Functions >
User Validation.
4 On the User Entitlement Validation form, click the Select button.
5 From People Search form, select the user to validate, and click Select.
The matching entitlement groups, entitlement rules, and SRDS for the user appear
in the tables. Click View under a table to view more details.
6 To see the qualification for matching entitlement rules and SRDs, click the
Qualification Details link on the User Entitlement Validation form.
7 On the Entitlement Management Qualifications form, click the Help Text link to
see the information more clearly formatted.
NOTE
Although the entitlement cache is flushed when an entitlement rule is created or
modified, you can click the Flush Entitlement CACHE button on the User
Entitlement Validation form to force a flush of the cache. After the cache is cleared,
users must reopen the Request Entry console to see any changes.

Chapter
11 Using the Work Order

Management application
BMC Service Request Management includes the Work Order Management

fulfillment application, which provides basic facilities for assignment, status, work
info, and task management. The BMC Service Request Management integration
with Work Order Management enables you to create any generic work-order
process.
Work order manager (page 248)
Work order assignee (page 249)
The Work Order Management application (page 249)
Work Order form views (page 250)
The Work Order form (page 251)
Creating work orders (page 252)
Searching for work orders (page 258)
Adding or modifying a customer profile (page 261)
Selecting work order templates (page 264)
Viewing details of a service request associated with the work order (page 265)
Viewing the audit log (page 265)
Reminders (page 266)
Sending email messages and pages (page 267)
Work order life cycle—Status transitions (page 270)
Assigning work orders (page 274)
Fulfilling work orders (page 276)
Viewing truncated data in a work order (page 276)
Working with tasks as a request manager (page 277)
Working with tasks with work orders as an assignee (page 280)
Service targets in Work Order Management (page 291)
Creating service targets for a work order (page 293)
Configuring work order rules (page 295)
Updating assignment availability (page 296)

Updating your profile (page 297)

Setting Work Order Console preferences (page 297)
Work order manager

Work order managers are usually the heads of the functional groups that deliver a
particular service. For example, the manager in charge of facilities would be the
work order manager for all facility work orders, while the manager in charge of
telecommunications would be the work order manager for phone work orders. As
a result, if you create a service request for a new employee, your request would
create a work order to the facilities department for a new office, another work
order to the telecommunications department for a new phone, and so on.
In large companies, the work order manager’s main responsibilities usually
involve planning and oversight. But in small companies, the work order manager
can also function as the work order assignee who performs the tasks for the work
order. Work order managers are responsible for work order management (for
example, tracking the work order).
Work order manager activities and responsibilities include:
Synchronizing work orders with service requests
Creating tasks to use with work orders
Handling assignments
Monitoring support staff activity involved in implementing the work order
Planning word orders, which includes identifying, creating, and sequencing the
tasks that must be performed to accomplish the work order
Scheduling people and resources to implement each task
When a work order is created, it is automatically assigned to the appropriate work
order assignee according to its criteria. The supervisor group or individual can be
notified of assigned work orders by email, pager, or through BMC Remedy Alert.
Using the assignment engine, any tasks are automatically assigned to the
appropriate work order assignee.
In summary, the work order manager is responsible for the quality and integrity
of the work order management process.
The work order manager requires the following permissions and functional roles:
Work Order Master permission is required to access the Work Order Console
and work orders, and to access the Overview Console.
Work Order Config permission provides access to work order rules, task
templates, and work order templates.
Work Order Manager functional role is required to be assigned as the Work
Order Manager for individual work orders.

Work order assignee
Work order assignee

Work order assignees are responsible for planning and implementing assigned
work orders. They are usually people with specialized abilities in the support
department of larger organizations. The work order assignee might be working
actively on the work order, or coordinating the efforts of other groups or
individuals working on tasks, if necessary.
To work with tasks, you minimally need Task User permissions. For information
about other levels of task permissions required, for example, to create task
templates, see the permission model in the BMC Remedy Task Management System
Administrator’s Guide.
NOTE
Using the Task Management System (TMS) functionality is optional with work
orders. You can create work orders that do not use TMS tasks.
Assignee activities and responsibilities include:

Gathering appropriate information based on the work order assigned.
Providing status updates to requesters on request.
Plan the task schedule.
Executing the tasks that make up a work order.
Reviewing all completed tasks, if more than one work order assignee helped
complete the overall work order.
Determining requester satisfaction with the overall work order.
The work order assignee requires the following permissions and functional roles:
Work Order Master permission is required for access the Work Order Console
and to work order records, and to access the Overview Console.
Work Order Assignee functional role is required to be assigned as the Work
Order Assignee for individual work orders.
The Work Order Management application

To open the Work Order Management application, click the Work Order Console
link on the IT Home Page or use the URL provided by your administrator to access
the console directly. For more information, see “Opening application consoles” on
page 36.
The Work Order Console provides a dedicated workspace for managing work
orders. This console enables work order managers and work order assignees to use
Work Order Management to plan their days more effectively. The Work Order
Console optimizes the visual work space so that they can track work orders
quickly and efficiently.

Work Order form views

BMC Service Request Managementprovides the following ways to view the Work
Order form:
Best Practice view
Classic view
The system administrator configures the view that you see. The Best Practice view
is the default view. For a description of the Best Practice View, see “Best Practice
view” on page 250. For a description of the Classic view, see “Deploying the
Classic view” on page 250.
NOTE
When documenting procedures in this guide, if there is a difference between how
you do something in the Best Practice view and how you do it in the Classic View,
only the Best Practice method is described.
Best Practice view

The Best Practice view is an improved version of the Work Order form. In this
view, the fields most commonly used for resolving and for updating work orders
are immediately visible. You can access additional, less frequently used
functionality from the tabbed sections of the form or from the links in the
navigation pane.
The Best Practice view is recommended for all Work Order Management users,
regardless of their role. For information about Work Order Management roles, see
“Work order manager” on page 248.
Deploying the Classic view

The Classic view is the Work Order form as it appeared in previous releases of
Work Order Management. This view is provided for customers who are upgrading
from earlier versions of the application and who are not yet ready to adopt the Best
Practice view.
NOTE
To perform the following procedure, you must have Administrator permission.
To deploy the classic Work Order form view

tab.
2 Choose Foundation > Advanced Options > View Selection Framework - Deploy
View, and click Open.

The Work Order form
3 In the Company Mapping tab, select the Best Practice View User record, and click
Remove.
NOTE
Deleting this record impacts only the Work Order form. No other forms in BMC
Service Request Management include classic and best practice views.
4 In the Application Name field, select Remedy Service Request and Catalog System.
5 In the Role field, select Classic View User.
6 If necessary, change the sorting order number.
7 Click Add.
8 Close the form and then have users log into the application again.
The Work Order form

The Work Order form is used to manage a work order and track its progress from
initiation to completion. The Work Order form is also used to assign tasks to
different support groups.
Before you begin searching, creating, or modifying information in the Work Order
form, you must understand the information relationships among the different
areas of this form.
First, you must create assignment mappings to assign a work order to a support
group, to an individual, or to both. An individual in the support group must
assume the functional role of Work Order Assignee. Assignment mappings can be
created for work order assignees. For information about functional roles and
assignment mappings, see “User access to application consoles and functions” on
page 44 and “Creating assignment routing” on page 300.
The Work Order form provides an example of the level of integration in BMC
Service Request Management, as a work order can result due to an incident, a
modification to a configuration item, or a known error correction as a result of
problem investigation.

Figure 11-1: Reviewing work orders in the SRD architecture model
Work Order Management can be defined to fulfill service requests, similar to the
other fulfillment applications.
Creating work orders

The following procedure describes the basic steps for creating a work order in the
Best Practice view.
To create a work order

1 From the IT Home Page, choose Service Request Management > New Work Order.
The Work Order form appears, and a Work Order ID is automatically assigned to
it. The functionality you see varies according to which other applications are
installed (for example, BMC SLM).
The work order initially appears in Assigned status. To enable the work order from
Assigned status to be moved to its next status, enter information into the following
required fields.
2 (optional) Use a work order template to complete the contents of the work order.
Work order templates are especially useful in any work order that follows well-
defined methods for specific and repeated requirements. Work order templates do
more than simply fill out fields for you; they can also include tasks with the work
order. See “Selecting work order templates” on page 264.

3 Complete the Customer or Contact field on the new Work Order form.
For more information, see “Adding or modifying a customer profile” on page 261.
If the customer record uses the VIP or the Sensitive flag, this information appears
in red after the Customer field label. For more information, see the BMC Remedy IT
4 In the Summary field, enter a brief description.
5 In the Notes field, enter the work order details.
6 In the Work Order Type field, enter a type (for example, General).
7 In the Request Manager section, enter the necessary information:
a Select a Support Company.
Your selection filters the Support Organization menu list.
b Select a Support Organization.
Your selection filters the Support Group Name menu list.
c Select a Support Group Name.
Your selection filters the Request Manager menu list.
8 (optional) In the Service field, select a service configuration item (CI) to relate to the
work order.
Items in the list are retrieved from the Atrium Service Catalog.
Selecting a service CI automatically performs the following actions:
Updates information in the Product Categorization area of the Classification tab
of the work order, based on the categorization of the service CI. You can modify
the Product Categorization values later.
Relates the service CI to the work order as a “Related to” association type.
After it is established, you cannot delete the association from the Relationships
tab. However, you can clear the business service from the Service field and save
the record to delete the association.
NOTE
Some CI types are virtual, while others are physical. The Business Service CI type
is an example of a virtual CI. In this context, a business service can be provided
from one business or organization within a business to another. Business Service
CIs can include customer support, employee provisioning, server farms, storage,
and so on.
The business service selected by a requester in response to a question takes

precedence over a business service specified in the Work Order template or in the
SRD. (The business service specified in the SRD takes precedence over a business
service specified in a Work Order template.)

9 Select the Priority to identify the importance you (as support staff) assign to the
work order.
Priority indicates the relative order in which changes should be addressed. It is
influenced by considerations of risk and resource availability. The default value of
the Priority field is Low.
10 If the fields in the Request Assignee section do not have assignee information,
complete the fields.
Alternatively, click one of the following links in the Quick Action section of the
navigation bar at the left:
Assign to Me—Assigns the work order to the user who is logged in.
Auto Assign—Assigns the work order according to the rules in the Assignment
Configuration form.
11 Click Save.
Entering work information for a work order

You sometimes need to modify the work order with work history entries that you
can create during its life cycle to document activities performed or information
gathered. Use the Work Detail tab to add work information regarding tasks
performed on the current work order. For example, you can track a work order’s
progress by recording the steps you took to implement it in the work history.
You might add work information about the following activities:
General Information—Notes about the work order. For example, you might
want to note that a particular CI was deployed and include the date.
Planning—Notes about a plan to implement a work order throughout your
organization.
Implementation—Installation and back out procedures for the work order.
Costing and Charging—Additional information about the cost of the work
order, or so on. For example, you might want to note that the cost was split
between two cost centers or that the cost to implement a work order came under
budget.
To enter work information for a work order

1 From the IT Home Page, choose Service Request Management > Search Work
Order, and click Search.
2 Select the work order to modify, and make the appropriate changes.
3 Click the Work Detail tab.
4 In the Notes field, enter notes about the work order.

5 To add an attachment, click the folder next to the Attachment field, and browse for
a file.
To clear an attachment that you just added, click the Remove File icon ( ).
To add more attachments, see step 6.
NOTE
Attachments to Work Info entries in a work order are not transferred with
information sent to a service request. You can access the attachment only from the
work order. Similarly, attachments added in BMC Service Request Management
are not transferred to the Work Order application.
6 To add more details:

a Click the arrow next to More Details.
b Add more attachments, as needed.
c From the Work Info Type list, select the type of work information to add.
d From the Source list, select the source of this information.
Information sources can include, for example, email, system assignment, or the
Web.
e For the Locked field, select Yes (to lock the log) or No.
f In the View Access field, select one of the following options:
Internal—If you want only users in your organization to see the entry.
Public—If you want everyone with access to the system to see the entry,
including requesters.
7 Click Add to add your entry to the work history.
WARNING
You cannot modify a Work Detail entry after you add it.
8 To filter specific work entries that appear in the table based on the type of activity,
select an option from the Show field.
9 To see a report of the activities that you performed against this work order, click
the Report icon ( ).
10 To see all entries for work information history, click the View icon ( ) at the top
of the tab.
NOTE
When you return to the Work Order Console, you might need to refresh the
Assigned Work Orders table to see all the modified records.
11 Click Save.

To view work information for a work order

1 Double-click an entry listed on the Work Detail tab.
The details appear on the tab.
2 To view an attachment, click the Download icon ( ).
3 Click Clear to return the tab to a state that allows you to enter new work
information.
Using the Classification tab to classify work orders

The Classification tab describes the work order and shows which products and
services are affected by the work order.
NOTE
Operational and Product categorizations are not configured as shipped for work
orders. You must modify the records in the Product Catalog Setup and Product
Catalog Setup forms if you intend to use them with work orders. See the BMC
Remedy IT Service Management Configuration Guide.
To use the Classification tab

2 Select a work order, and click the Classification tab.
3 Enter the following information:
a Enter Location information.
b Enter information about the Operational and Product categorizations.
Operational categorization is based on a three-tier hierarchy defined in the
Operational Catalog Setup form.
Product categorization is based on a five-tier hierarchy defined in your
Product Catalog Setup form.
c View the read-only information about the business service attached to the work
order.
See “Adding a service CI to an SRD” on page 136.
4 Click Save.

Relating work orders to other objects

The Relationships tab on the Work Order form includes a table that lists all service
requests that are related to the work order.
On the Relationships tab, you can perform the following actions:
Relate incidents, change requests, configuration items (CIs), and other work
orders to a work order.
NOTE
In the Work Order form, you can relate a CI to a work order, but in the CI form,
you cannot relate a work order to a CI.
View an incident, change request, CI, or another work order that is related to a
work order.
To view an incident, select it in the Relationships table, and click the View
icon ( ).
To restrict the number of requests that appear in the table, select a type of
request in the Show Related field.
Remove a relationship between a work order and an incident, change request,
CI, or another work order. (To unrelate a service request, select it in the
Relationships table, and click the Remove button [ ].)
NOTE
If the BMC Remedy IT Service Management applications are installed on a remote
system, status information is not visible in the table. This is because the status sync
up workflow is implemented in filters, but filters do not support accessing forms
on a remote system. If the BMC Remedy IT Service Management applications are
installed on a local system, there is no issue.
To relate work orders to other objects

2 Select the work order, and click the Relationship tab.
3 From the Search list (under Create Relationships) at the bottom of the
Relationships tab, select the type of record to which to relate the current record.
NOTE
Alternatively, you can skip step 2 and step 3, and select Create Relationship To >
Type of Record from the Quick Action section of the navigation bar at the right.
4 Click the Search icon ( ).
NOTE
The contents of the search form depend on the type of record that you chose in the
Search list.

5 In the search window for the request type, enter a string in the Search field, and
click the Search icon.
6 In the search results table, select the record to relate to the work order.
7 From the Select a Relationship Type list at the bottom of the search dialog box,
select the type of relationship to define (for example, Related to).
8 Click Relate.
9 Click OK.
To view related work orders

1 Select a related work order in the table on the Relationships tab.
2 Click the View icon ( ).
The related work order appears on the Work Order form.
3 To return to the current work order, click on work order number listed in the path
of links (“bread crumbs”) at the top of the form.
Adding details to a work order

The Details and Details 2 tabs appear on the Work Order form only when a work
order template is included with a work order. See “Selecting work order
The details tabs contain thirty fields that were provided to accommodate
customizations to the application. In the sample templates, some fields have
sample labels; the other fields show “Not Used” as a label.
To define details fields

2 Select the work order, and click the Tasks tab.
3 Click the Details tab or the Details 2 tab.
4 Enter information into the details fields provided by your administrator.
5 Click Save.
Searching for work orders

From the Work Order Console, you can run a series of predefined searches, one-
time custom search by using the Search form, or create and save your own custom
searches by using advanced qualifications.

Searching for work orders
Using Defined Searches

The Defined Searches area of the navigation pane contains a series of predefined
searches that you can use to look for records. For example, you can use a
predefined search to search the database for all work orders that have a status of
open.
The predefined search looks only through records that are in some way associated
with you through your login ID or group ID (for example, records assigned to you
or to your support group, and so on). You run this search from the Defined
Searches area of the navigation pane.
NOTE
To view the support groups you belong to, click the My Profile link in the
navigation pane, and click the Support Groups tab. For more information about
this link, see “Updating assignment availability” on page 296.
To run Defined Searches

1 From the Work Order Console, make sure the Company and View By fields in the
console are pointing to the appropriate company and support group.
2 From the Defined Searches area of the navigation pane, open the node that
corresponds to the search to run.
For example, to see records by their status, open the By Status node.
3 Click the criteria that defines the status of the records to see.
For example, to see all open records by status, click All Open. The results of the
search appear in the Console List.
TIP
If the contents of the Console List do not update after you run the search, click the
Refresh button.
Using custom searches

A custom search looks through all the records that meet your search criteria,
regardless of their associations to people or groups. You run this type of search by
using the Search Problem link in the navigation pane.
Use this type of search when you are looking for a record not associated with your
ID or your group’s ID, or any time you need to search all records.

To use a custom search

1 From the navigation pane of the Work Order Console, click Functions > Search
Work Order.
A form appears that enables you to perform the search. The form is laid out in a
similar way to the Work Order form, and contains the same tabs and fields. You
can use any of the tabs and fields in the form to specify your search criteria.
2 Using the tabs and fields, build your search condition.
To reduce the number of records found by the search, enter as much information
into the form as you can.
3 Click Search.
When the search finishes, the search results list contains all the records that match
the search criteria.
4 Scroll through the list to find the specific record.
Creating a custom search with advanced qualifications

In the Manage My Searches area in the left navigation pane of the Work Order
Console, you can define and save a custom search. Custom searches using
advanced qualifications allow you to create searches with very specific search
criteria, which you can save for reuse. After you save the custom search, it appears
in the My Searches node of the Defined Searches list.
NOTE
The My Searches node only appears after a custom search is defined.
To define a custom search

1 In the Defined Searches section of the navigation pane of the Work Order Console,
click Manage My Searches.
2 In the Type field, select the type of record to search for.
3 In the Search Name field, type a name for the search.
4 Click Build Search Qualification to open the Advanced Qualification Builder
dialog box, and define the search qualification.
5 From the Keywords or Fields selection boxes, select the keywords or record fields
on which to search.
To insert operators (+, =, >,<, and so on), click the appropriate operator button. Do
not forget to place literal values between double quotation marks. For example, to
search for a problem investigation with a priority of “high,” you would construct
the following search:
'Priority' = "High"

Adding or modifying a customer profile
6 Click Select to close the Advanced Qualification Builder, and click Save.
The search appears in the Defined Searches list, under the My Searches node.
NOTE
The My Searches node only appears when a custom search is defined.
To edit a custom search, select it, make any changes, and click Save. To delete a
custom search, select it, and click Delete.

Before you can create a work order, the customer must be listed in the People
database. Customers are usually added to the People database by the
administrator, as described in “Creating people information” on page 50.
However, if a customer is not listed in the database, you can add a customer’s
profile from the Work Order form.
You can also modify the customer and the contact phone number and site directly
on the Work Order form. A modification directly on the Work Order form,
however, applies only to the current work order; it does not update the People
record permanently.
To update the People database permanently, you can open the People form from
the Work Order record, as described in the following procedure.
To add a customer profile

1 From the IT Home Page, choose Service Request Management > Work Order
Console.
2 Click Create to create a work order.
3 Click the Customer Search button ( ) next to the Customer or Client fields.
4 On the People Search form, click Create.
5 On the People form, complete or modify the required fields, and click Save.
If you are adding a customer record, you do not need to add all the information for
this individual’s profile, only what is necessary to submit the record.
NOTE
You cannot define a Support Person record here. For more information, see
“Application functional roles” on page 46.
If you are adding a customer, the status of the person you added has a default
value of Proposed. Your People/Contact administrator must verify those in
Proposed status, update them to Enabled, and add any other information that is
necessary.

6 To clear the Customer or Contact field and enter a different name, click the Clear
Field icon ( ).
NOTE
If you are using the Classic view, click Create on the Customer tab to add a
customer profile.
To modify a customer profile

Console.
2 Open a current work order that belongs to the customer whose profile you are
modifying.
3 Click the Details button ( ) next to the Customer or Client fields.
4 In the People form, make the necessary changes.
5 Click Save.
6 To clear the Customer or Contact field and enter a different name, click the Clear
Field icon ( ).
NOTE
If you are using the Classic view, click Modify on the Customer tab to modify a
customer profile.
Configuring the search type for Customer and Contact fields

From the Work Order Settings form, you can configure which of the People form
fields the application searches against when the user types information into either
the Customer or the Contact field. This lets the user type some information in the
field and then press Enter to return a list of partial matches from which an exact
match can be chosen.
You can configure the Customer and the Contact fields to search against one of the
following People form fields:
Corporate ID
First Name
Last Name
Internet Email (default)
Phone Number
For example, using the default configuration, the application searches against the
Internet email address that appears on the People form. Therefore, if the user types
Al in either the Customer or the Contact field and then presses Enter, the
application returns a list of all people whose email address starts with Al (Arthur
Albertson, Allen Allworth, Anita Alman, and so on).

To configure the search type for Customer and Contact fields

tab.
Order > Work Order Settings, and then click Open.
3 Click Show Settings to populate the fields with the current setting.
4 From the Customer and Contact Search Type list, select the type of search you
want.
5 Click Add/Modify Settings to save the setting.
Configuring the People form to appear when selecting customer or

contact
You can choose to have the People form appear after a work order manager selects
a customer or a contact name when registering a new request. Having the People
form appear enables the manager to see and, if necessary, edit any of the People
information on the People form.
The default setting is No, which means the People form does not appear.
To configure the People form to appear when selecting a customer or

contact
tab.
2 From the Application Settings list, choose Incident Management > Advanced
Options > Incident Management Settings, and then click Open.
3 Click Show Settings to populate the Customer and Contact Search Type field with
the current setting.
4 From the Display Customer Info Dialog list, select Yes to have the People form
appear.
5 Click Add/Modify Settings to save the setting.

Selecting work order templates

Work order templates let you quickly and efficiently create “standard” work
orders with a minimum of mouse clicks and keyboard entry. Work order templates
are useful in any work order that follows well-defined methods for specific and
repeated requirements, for example, Installs, Moves, Add Changes (IMAC). New
and occasional users to work orders should find work order templates very
helpful.
If you need details fields with your work order, you must generate them from a
work order template. See “Adding details to a work order” on page 258.
See also “About work order templates” on page 76.
To select templates
1 From the IT Home Page, choose Service Request Management > New Work Order.
2 From the navigation pane on the left side of the form, click Functions > Work
Order Template.
You can apply a work order template only while the Status is in Assigned state.
You can also select a work order template only once for each work order.
3 In the Work Order Available Templates dialog box, click View to examine the
contents of a work order template.
The template appears in read-only mode. Viewing a template enables you to see
its assignments, its task and task group templates, and other features.
4 Close the Work Order Template dialog box.
5 In the Work Order Available Templates dialog box, click Select Template.
The contents of the template are applied to the work order. The work order
template overwrites any field values that are already present in the work order. If
the work order already includes relationships or tasks, these are not overwritten.
Any additional tasks from the template are added as peers, and additional
relationships are included with the work order.

Viewing details of a service request associated with the work order
Viewing details of a service request associated

with the work order
If the work order is attached to a service request, the View Service Request link
appears at the top-right corner of the Work Order form. This link enables you to
view read-only information about the service request, for example, its work
history, its Request ID, and so on.
To view the service request associated with the work order

2 Select a work order that shows a View Service Request link.
3 Click the View Service Request link.
4 In the Request Details dialog box, perform one of the following tasks:
To track the history of the service request, click the Activity Log tab.
To view a complete list of the request’s details, click the Details tab.
Viewing the audit log

Viewing audit logs enables you to view field and notification audits against the
work order. When certain fields are changed or when system notifications are sent,
an audit entry is created to track the work order. The login ID of the individual
making the work order appears next to the audit entry.
To view audit logs

2 Select the work order for which to view the log.
3 From the navigation pane on the left side of the form, click Functions > View Audit
Log.
4 (optional) Use the Audit Type list to filter out audit log entries.
5 Click the Notification Audit tab to view notification audit entries against the work
order.
6 Select a notification audit entry and click View.

Reminders
Reminders enable you to create notes for yourself and others. You can send them
by email or through BMC Remedy Alert, and you can specify when they are sent.
You can create generic reminders, or you can create reminders that are associated
with a specific work order or task. For example, you can send yourself a note about
a specific work order to remind you to follow up on it.
Whether you access reminders from the console or from a work order determines
which reminders you can view:
When you open the Reminders dialog box from the console, you can view all
reminders that you have created.
When you open reminders from a work order, you can view all reminders
associated with that work order. This includes reminders created by other users
of the application.
You can modify or delete only the reminders that you have created.
Creating reminders
If you create a reminder from the console, the reminder is generic. If you create a
reminder from a work order, the reminder is specific to that work order.
To create a reminder
Console.
2 Click Functions > Reminders.
3 In the Reminders dialog box, click the Create Reminder tab.
4 In the Notify list, select Individual or Group, depending on whether you are
sending the reminder to a single person or a group of people.
5 In the Recipient field, type the name of the person or group to notify.
If you type a name in the Recipient field and press ENTER, the AR Login field is
automatically populated. If you leave the field empty and press ENTER, the People
Search dialog box appears. You can search for a name and select it from a list. The
Recipient and AR Login fields are automatically populated.
6 In the Time field, enter the time that you want the system to send the reminder.
You can type the information, or you can click the button next to the field and select
the time from the calendar that appears. By default, the Time field contains the
current date and time.
7 In the Subject field, enter information about the reminder.
The information in this field appears in the subject line if the reminder is sent by
email.

Sending email messages and pages
8 In the Message field, type the reminder message.

9 Click Save.
The reminder is sent at the time you specified.
Viewing, modifying, and deleting reminders

If you open the Reminders dialog box from the Work Order Console, all reminders
that you created appear. If you open the Reminders dialog box from a work order,
only the reminders associated with that work order appear.
To view, modify and delete reminders

1 In the Work Order Management console, or from a work order, click Functions >
Reminders.
The Reminders dialog box appears. If you opened the dialog box from the Work
Order Console, all reminders that you created appear. If you opened the dialog box
from a work order or a task, only the reminders associated with that work order or
task appear.
2 In the Show Reminders field, select the set of reminders to view:
All
Pending
Sent
The reminders appear in the table.
3 Select a reminder, and click View.
4 In the Reminder Details dialog box, modify the reminder, and click Save.

The Work Order form provides the following methods of sending messages to
individuals or organizations:
Email
Paging
To send an email message

2 Select the work order from which to send the email.
3 From the left navigation pane, click Functions > Email System.

4 In the Email System dialog box, indicate the recipient by selecting one of the
following options:
Select Current Contact—When you open the Email System form, if there is a
current contact assigned to the record, the contact’s name and contact
information appears in the table and is the default recipient.
Select Current Assignee—To select the current assignee, click Select Current
Assignee. The current assignee’s name and contact information appears in the
table.
5 If you are sending the email to another recipient, complete the following steps:
a Complete the fields in the People Search Criteria area, and click Search.
b When the search finishes, select the recipient’s name in the search results table.
If you need to see more information to determine which is the correct name in
the list, select an individual's name from the list, and click View. This opens the
People form, which contains detailed information about the recipient.
6 Complete the email information fields:
Internet Email—Type the recipient’s email address here.
You can find this information by selecting the person’s name from the search
results list, and clicking View. When the People form appears, look for the
Internet Email field on the General tab.
Email Subject Line—By default, the subject line contains the work order ID
number, to which you can append text to or over-type.
Email Message Body—Type the message text here. A series of buttons, to the
right of the Email Message Body field, enables you to automatically insert text
from the record into the message text.
NOTE
If one or more of these buttons appear disabled, it means the corresponding field
in the record contains no information.
Email Attachment—You can attach a file to the email message (you are limited
to only one attachment). To do this, right-click inside the Email Attachment
table, and click Add. The Add Attachment dialog box appears. Navigate to and
select the file to attach. Click Open. Details of the attached file appear in the
table.
7 Click Send Email Now.
To page a person or an on-call group

2 Select the work order from which to send the page.
3 From the left navigation pane, click Functions > Paging System.

4 Click one of the following tabs:

Page By Person—To page an individual.
Page By On-Call Group—To page the on-call member of a specified group.
5 Select the recipient.
To do this, complete the fields in the Search Criteria area, and click Search. Click
the recipient’s name in the search results table, and click Select.
If you are sending a page to a person (instead of an on-call group) and need help
determining the correct person, you can see more information by selecting an
individual's name from the list, and clicking View. This opens the People form,
which contains detailed information about the recipient.
6 Complete the fields in the Paging Information area, as follows, and click Send Page
Now.
Pager Service Provider—Select the recipient’s pager service provider from the
list.
If you are sending a page to a person, you can find this information by selecting
the person’s name from the search results list, and clicking View. When the
People form appears, click the Notifications tab and look for the Pager Service
Provider field.
NOTE
If you need more information about the service provider, click the button with the
globe icon beside the field to open a link that takes you to the service provider’s
website.
Pager Type—The system automatically populates this field, using information

about the recipient already in the system.
Pager Number—The system automatically populates this field with the pager’s
telephone number, when possible. If the pager number is unavailable to the
system, enter the pager number manually. See Manual Pager Number.
Pager Email—If the pager has an email address, type it here. If you are sending
the page to a person, this information is available on the Notifications tab.
Manual Pager Number—If the pager’s telephone number is not available
automatically from the paging system, type the pager’s telephone number here.
Alphanumeric Pager Message or Numeric Pager Message—Type your message
in this field. Be aware that only one of these fields is enabled, depending on the
type of pager the recipient carries.
7 Click Send Page Now.

Work order life cycle—Status transitions

Default work orders enable various status transitions to indicate their position in
the life cycle. Notifications might be sent at certain points in a work order's life
cycle to alert users that certain events have occurred.
Status Description
Assigned Initial status, or user saves a draft of the work order.
Pending The following descriptions can apply:
The work order assignee or Request Manager needs additional
information.
Indicates whether an error occurred for some reason, for example,
inaccurate data. Service request is created with an error. No work
order is created.
Waiting Approval Not applicable to work orders.
Planning Work order is created, but no work has started.
In Progress The work order is being implemented.
Completed When the last task on a work order is closed, the work order’s status
is automatically set to Completed.
The Completed status is the only status that is shipped with status
reasons related to it:
If the statuses for all the tasks are set to Closed with a reason of
Successful, then the work order is Completed with a reason of
Successful.
If the status of one of the tasks is not set to Closed with a reason
of Successful, then the work order status is set to Completed with
a reason of Successful with Issues.
Rejected Not applicable to work orders.
Cancelled The service request associated with this work order was cancelled,
or the work order was cancelled.
Closed The following descriptions can apply:
Closed without any issues.
Closed but with some issues.
Closed by the system after the service request was in an end status
(completed or cancelled) for 15 days.
You cannot modify a work order after it is closed.
In the Work Order Status Relationships (WOI:StatusRelationships) form, there is

one record for each possible status transition. This means that to customize status
transition rules, you can edit the data in these records, instead of creating new
records.
NOTE
Although you can easily change the status transition rules for a work order, the
Work Order Status Relationships form is a fulfillment form. Therefore, the records
are available only in English, and no localized versions are currently available.

The following diagram shows the included status transitions in the life cycle of a
work order (for the Assigned, Pending, and Waiting Approval statuses).
Figure 11-2: Work order life cycle—Assigned, Pending, and Waiting Approval statuses
Assigned
Waiting
Pending Rejected
Approval
Planning
In Progess
Completed
State transitions
Closed
Assigned
Pending
Waiting
Cancelled Approval
To prevent the transition from one status to another, you must set the appropriate
transition rule to Enabled, which is stored on the Work Order Status Relationships
form. To allow the transition from one status to another, you must set the status of
the transition rule to Offline.
The following diagram shows the included status transitions in the life cycle of a
work order (for the Planning and In Progress statuses).

Figure 11-3: Work order life cycle—Planning and In Progress statuses
Assigned
Waiting
Pending Rejected
Approval
Planning
In Progess
Completed
Closed
State transitions
Planning
Cancelled
In Progress
NOTE
Several work order status values do not have status transitions configured as
shipped (for example, Completed, Closed, Rejected, or Cancelled).
The following table describes the included transitions that are excluded in the work
order life cycle. For example, you cannot move a work order directly from
Assigned status to Closed status.
Work order cannot move from this status... ... to this status
Assigned Closed
Pending Assigned
Closed
Waiting Approval Assigned
Closed

Work order cannot move from this status... ... to this status
Planning Assigned
Waiting Approval
Closed
In Progress Assigned
Waiting Approval
Planning
Closed
Completed Assigned
Pending
Waiting Approval
Planning
In Progress
Rejected
Cancelled
Closed Assigned
Pending
Waiting Approval
Planning
In Progress
Completed
Rejected
Cancelled
Rejected Assigned
Pending
Waiting Approval
Planning
In Progress
Completed
Cancelled
Closed
Cancelled Assigned
Pending
Waiting Approval
Planning
In Progress
Completed
Rejected
Closed
NOTE
If a service request consists of a single work order, moving the work order from a
status of Completed back to In Progress does not result in the status of the Request
also being reset to In Progress. When the work order's status progresses, errors
result.

Assigning work orders

A work order must be assigned to a Support Group. However, a specific request
manager is typically responsible for the overall work order process.
If an assignment definition was not created for the work order, the request
manager must assign the work order manually. The request assignee is then
notified of work order assignments by email, pager, or BMC Remedy Alert.
Assigned work orders can also be listed in the Assigned Work Orders table in the
console.
Work order assignment is based on the work order’s categorization. The Work
Detail tab shows information about people assigned to a work order as the Request
Assignee.
NOTE
The application administrator must define at least one individual with the
functional role of Work Order Manager (the Request Manager) before you can
make any assignments to a Support Group.
During configuration, the application administrator determines to whom the work

orders are assigned. This decision is based on criteria such as the work order’s
categorization. For example, all work orders that are categorized as hardware
issues might be assigned to the Support-Hardware group. All work orders that are
categorized as software upgrades and originate from California might be assigned
to Sonya Software in San Jose. The criteria of the work order together with the
application administrator’s configuration determines to whom each work order is
assigned.
The assignee must make sure that the assignment is correct and accept the work
order. If the assignment is not correct, the request manager can reassign the
request.
To assign work orders

2 Select the work order, and click the Work Detail tab.
Based on the default configuration and requester information in the work order,
certain fields might already be filled.
3 To assign a request assignee, select the appropriate menu options from the
following fields:
Support Company
Support Organization
Support Group Name
Request Assignee

Assigning work orders
4 Click Save.
The request manager and the request assignee are automatically notified of their
assignments.
Reassigning work orders

If you cannot accept or resolve an assigned work order, you can reassign the work
order to another assignee, or you can ask your manager to reassign the work order.
If the work order was categorized incorrectly, it can also be reassigned.
To reassign a work order yourself

2 Select the work order, and click the Work Detail tab.
3 Select the assignee to whom to assign the work order.
4 Click Save.
The manager or assignee is notified of the reassigned work order.
Receiving notifications of work order assignments

Request assignees are notified of new work orders based on their notification
method preferences defined in their personal record. In addition, when a work
order moves into a new status, for example, Completed, the work order executes
workflow that triggers notifications. Based on your group or role, you might
receive notifications during various work order statuses. For more information
about notification preferences, see the BMC Remedy IT Service Management
The available notifications are:
Individual Notification—An individual assignee is notified according to the
notification method specified in their personal record.
For example, if Bob Backline has a notification method of BMC Remedy Alert,
he receives a notification from BMC Remedy Alert for each work order that is
assigned to him.
Group Notification—A support group is notified according to the notification
method specified by each group member’s entry in their personal record.
For example, if a work order is assigned to the Support-Software group, each
group member is notified through the notification method specified in their
personal record. For example, if Sarah Software has Email specified as the
notification method in her personal record, the notification is sent to her by
email.
NOTE
To receive notifications of assigned tasks if BMC Remedy Alert is configured as the
method of receiving notifications, log into BMC Remedy Alert.

Fulfilling work orders

One of the responsibilities of a request assignee is to fulfill the work orders that are
part of the service request. For example, a service request to replace a hard drive
can generate multiple work orders.
When the status of a fulfillment work order is In Progress or Implementation in
Progress, the status of the service request is set to In Progress.
To fulfill a service request work order

Console.
2 In the left navigation pane, click Functions > Search Work Orders.
3 In the Work Order form, search for the work order created for the service request.
4 Move the work order to the Closed status.
5 When you have finished with the details of the work order, click Save.
When the last fulfillment work order is fulfilled, the status of the service request is
set to Completed.
Viewing truncated data in a work order

When viewing a work order, you sometimes see that the data pushed from a field
in the service request to the work order was truncated, indicated by ellipses (...).
NOTE
When SRM data is truncated in other fulfillment applications, for example, within
a change request, you also see an ellipses (...).
If the application is properly configured, truncation of data is a fallback

mechanism in the fulfillment application that enables the creation of the entry even
when the field length in the service request is too long. Otherwise, CAI errors
appear when the application failed to create the entry. You can still view the
complete data, even though it does not appear in the work order.
To view truncated data from a service request

2 Select the work order, and click the View Service Request link.
The Request Details dialog box appears.

Working with tasks as a request manager
3 Click the Activity Log tab.

A TRUNCATE WARNING message appears in the Summary and Notes. You see this
message because the field length value in the service request did not fall within the
limits specified for the field and was truncated in the fulfillment application (here,
the Work Order Management application). The entry was successfully created;
however, some data was not pushed to the fulfillment application.
4 Scroll through the Summary and the Notes to view the complete data.
5 If needed, add a summary, note, or attachment.

Work order task groups and tasks
When you plan a work order, determine whether you can divide it into separate
tasks. Tasks are the individual components of a work order and are assigned to
assignees who complete the tasks.
TIP
When you are creating tasks for a work order, you must complete the Requester
Information, Work Order ID, and Summary in the work order before you include
the tasks.
The Tasks tab shows the tasks that are required to be performed to complete the
work order. You can use task groups to manage a work order with many tasks,
each having its own schedule, task assignee, and plan. For less complex work
orders, tasks are optional. Tasks are created and modified in the work order and
are stored separately in the Tasks form. A single work order can have an unlimited
number of tasks.
After a task is assigned to a support group or an individual, the assignee receives
notifications to perform the various task activities based on the work order
process.
Tasks, like work orders, go through many status transitions as they progress. The
status in which a task is created depends on the status of the parent work order.
Assigning tasks
You assign each task to a work order assignee.
To assign a task
3 Select the parent task or child task that is already related to the work order.

4 Click View.
The task opens in the Task form.
5 Select the Assignment tab.
6 Select the group or person who will work on the task from the Assignee Group or
Assignee lists.
7 Click Save.
The assignee for that task is notified of the task assignment.
Assigning a sequence number to task groups and tasks

When you include task group templates, task templates, or ad hoc tasks in a work
order, they are automatically assigned a sequence number in the order in which
you add them to the work order. Their sequence is strictly enforced inside the work
order.
To renumber a task group or task, you can use the arrow buttons on the top-right
side of the Tasks and Task Groups table. Tasks with lower sequence numbers (such
as 1) must be completed before those with higher numbers (for example, 2, 3, or 4).
More than one task group or task can have the same sequence number; task groups
and tasks with the same sequence number are considered peers. Peer tasks can be
completed in any order among themselves.
To assign a sequence to task groups and tasks

3 Add task group and task templates to the change, or create ad hoc tasks.
Your task groups and tasks appear in the Task and Task Groups table.
The work order includes several task groups and tasks. These task groups and
tasks must be completed in sequential order, from 1 to 4. The table also shows their
task status (Staged).
4 To renumber the tasks, select a task, and click the arrow buttons to renumber the
sequence.
When you move a task up in the sequence, it becomes a peer of any task already at
the level you move it to. For example, if you move the Deploy Package task to level
3 and Verify Tart Status is already at level 3, two peer tasks have the sequence
number 3. You can work on these two tasks in any order.
When working through the tasks and you complete the last task in the sequence,
you can close the work order.
5 Click Save.
For more information, see “Working with tasks with work orders as an assignee”
on page 280.

Reassigning tasks
Task reassignment is performed manually, directly on the Task form. If you cannot
resolve a task that you were assigned, you can reassign the task yourself, or you
can ask the requester to reassign the task. You might ask the requester to reassign
the task in situations where you want to reassign the task to someone outside of
your group.
To reassign a task
Console.
2 Choose Console Focus > Tasks.
3 In the Tasks table, select the task to reassign, and click View.
4 From the Task form, click the Assignment tab.
5 In the Assignee Group or Assignee fields, choose the group or person to whom to
assign the task to.
6 Make sure the Notify Assignee field is set to Yes.
7 Click Save.
The new assignee is notified of the request assignment. Until the new assignee
accepts the task assignment, you are still assigned to the task and have
responsibility for it.
Planning the time for tasks

You can create the time segments required to complete individual tasks. The Dates
tab in the Task form includes fields where you can enter scheduling information.
To plan the time for tasks

3 Select the task to modify.
4 Click the Assignment/Dates tab.
5 In the Dates/Time area of the form, provide dates for the scheduled start and end
dates of the task.
6 Click Save.

Adding financial information to a task

In the Financials tab, you can include auto-cost estimates in a work order.
To add financial information to a task

4 Click the Financials tab.
5 In the Calculation Unit Type field, select Flat Rate, Hours, or Minutes.
6 In the Budget Estimated Total Time, enter the time based on unit type.
You use this information to forecast the cost. For example, you might budget that
the change will take 2 hours to perform.
7 In the Actual Total Time, enter the time according to the calculation unit type.
You enter this information after the change is completed, for example, you
budgeted 2 hours to complete the change, but it actually took 3 hours.
8 Click Save.
Working with tasks with work orders as an

assignee
This section describes how to manage and fulfill your tasks. When a request
manager assigns the task, the assignees are notified of tasks assigned to them by
email, BMC Remedy Alert, pager, or some other means. After a task is assigned,
assignees can log their progress as they complete each task. When all of the tasks
related to a work order are closed or cancelled, the work order is set to Completed
and the requester is notified that the work order is resolved.
Searching for assigned tasks

You can search for tasks by entering the fields by which to search in the Task
Information form in Search mode, and you can also search for tasks assigned to
you or your group.
To search for open tasks

Console.

Working with tasks with work orders as an assignee
3 Select an option from the Show list:

All
Submitted By Me
Assigned To Me
Assigned To My Selected Groups
Assigned To All My Groups
Your open tasks appear in the Tasks table.
4 To further filter the results, select an option from the Filter By list.
5 To view the details of a task, select it and click View.
Viewing task groups and tasks

Your assigned tasks and task groups are listed on the Work Order Console. Tasks
are prefixed with TAS and task groups with TGR.
You can also view tasks and task groups related to a work order from the Tasks tab
of the Work Order form.
NOTE
To see a read-only view of the task flow in the task group, click the View Flow
button. For more information, see “Viewing the flow of a task” on page 282.
To view task groups and tasks

Console.
2 From the left navigation panel, set the Console Focus to Work Orders.
This enables you to see the tasks that are associated to a specific work order. To
view all the tasks for all of your work orders, set the Console Focus to Tasks.
3 Select a work order.
4 Under Work Order Details, select the task group or the task you want to view.
5 Click View.
Tasks appear in the Task form, while task groups appear in their Task Group form.

Viewing the flow of a task

You can click the View Flow button to see a read-only view of the task flow in the
task group.
To view the flow of a task

3 Select the task group or the task that to view.
4 Click View Flow to see a read-only view of the task flow in the task group.
The Task Flow Viewer appears.
Figure 11-4: Task Flow Viewer
The Task Flow Viewer uses color codes to illustrate the different stages of the tasks.
For example, a blue stage indicates that its status is Closed, but a yellow stage
shows its status is Staged. The Viewer also shows you the flow among tasks.
You can also perform the following functions in the Task Flow Viewer.
Zoom in to focus the view.
Zoom out to expand the view
Click the pan buttons to move the flow around.

Accepting assigned tasks

You receive notification of assigned tasks by BMC Remedy Alert, email, and so on.
You can also use the Work Order Console or the Overview Console to view all
tasks assigned to you. The table list includes a column that shows the assignee of
the task. Tasks are identified by the TAS prefix.
When a work order is set to In Progress and a task is not assigned, the task status
is set to Pending. If the task is assigned, its status is set to Work in Progress.
Following the recommended life cycle of a work order, the status of a task should
be Staged before you accept the task.
NOTE
To receive notifications of assigned tasks if BMC Remedy Alert is configured as the
method of receiving notifications, log into BMC Remedy Alert.
To accept an assigned task

Console.
2 In the View By field, select Personal.
3 Select the work order.
4 In the Tasks table, select the task that to accept.
Tasks are identified by the prefix of TAS.
5 Click View.
6 If you are ready to begin working on the task—that is, if the Status Field of the
work order is set to In Progress—set its Status field to Work in Progress.
This is an important step because the task then moves into Work in Progress status.
In addition, different escalations occur based on the task’s status. If the task is still
in the Scheduled status while you are working on it, an inaccurate escalation can
occur.
7 Click the Assignment tab.
8 To track the time spent working on a task by using the start and stop buttons,
follow these steps:
a Click the Start Clock button.
The current date and time appear in the read-only Start Time field.
b Click Save.

c When you have finished working on the task and want to stop tracking the time,
click the Stop Clock button.
You must repeat steps a and b first if you closed the task after saving it.
A message reports the number of minutes spent working on the task. The time
spent is also added to the value in the read-only Total Time Hours and Minutes
fields.
d Click Save.
You can use the start and stop clock buttons as many times as you like. Each
successive time, the new time is added to the value already in the Total Time
Hours and Minutes fields.
9 To track the time spent working on a task manually, enter a number of hours or
minutes manually in the editable Time Spent fields, and save your changes.
The time you entered is automatically added to the value already in the Total Time
Hours and Minutes fields.
10 Click Effort Log to keep track of how much time you spent.
See “Tracking task efforts” on page 286.
11 Click the Work Info tab and enter the progress you have made on the task.
12 Click Save.
Modifying tasks for work orders

You can access the task from either the Work Order Console, or from the work
order.
To modify tasks
4 Click View.
The task opens in the Task form in a modify window.
5 Modify the task details as needed.
NOTE
If you change the Status to Close, you must select a Status Reason (Success, Failed,
or Cancelled).
6 Click Save.

Adding work information to a task

You can add work information to each task included in the work order. The work
information for each task appears in the Work Info of Selected Task table on the
Work Order form.
To add work information to a task

Console.
2 Under Work Order Details, select the Tasks option.
3 Select a task, and click View.
4 From the Task form, click the Work Info tab.
5 From the Source list, select the source of this information.
Information sources include Email, System Assignment, or the Web.
6 Enter the details of your work information record in the Summary and Work Info
Notes fields.
7 To add an attachment, follow these steps:
a Right-click in the Attachments area, and click Add.
b From the Add Attachment dialog box, click Browse.
c Select the file and click Open.
d Click OK.
8 From the Locked list, select Yes or No to lock the log.
9 Select the view access:
Internal—If you want only users in your organization to see the entry.
External—Not applicable to tasks. Work information is not included in the
activity log.
10 Click Save.
The Save operation adds your entry to the task’s work history. The Show field
enables you to filter specific work entries based on the type of activity that appears
in the table.
NOTE
When you return to the Work Order form, you might need to refresh the Work Info
of Selected Task table to view all the entries.

Tracking task efforts

You can track the time spent working on a task at any time after it is created, but
typically the time tracked is between the Work In Progress and Closed status
changes. You can track the time spent working on a task in the following ways:
Using the start and stop clock buttons—The time is automatically calculated
based on when you click the start and stop clock buttons.
Manually entering the time—You can enter a time directly into the Time Spent
field.
Entering work into the task effort log—You can create a task effort log entry. See
“To track task efforts.”
The Task Effort Log shows a list of all individuals who have worked on the task
during its life cycle.
Entries in the effort log are not system-generated, so you must enter them
manually. The list is not in chronological order.
To track task efforts

4 Click the Assignment tab.
5 Click Effort Log.
6 In the Task Effort Log dialog box, select the type.
This information is required to show what kind of effort is being logged, for
example, actual task activity.
7 Enter the time spent in hours and minutes.
This information records where the time was spent.
9 Select information in the company, organization, group, and assignee fields.
This information is required to select the individual for whom the effort log is
being created.
10 Click Add to Effort Log.
The effort log appears in the table.
You can view the effort log entry and modify the time or any other information.

Working with a task in progress

As you work on implementing or completing a task, the Work Order Console
enables you to update the task with the progress you are making.
To modify a task
Console.
2 Select a work order.
Details for the parent work order appear under Work Order Details, including any
Work Info entries.
3 Under Work Order Details, select Tasks.
4 In the table, select the task to modify, and click View.
5 On the Task form, update the fields in the task.
6 Click the Work Info tab, and create a work info history entry for the task.
7 Click Save.
Adding ad hoc tasks to work orders

You can add an ad hoc task to the work order. You can manually set the
assignment for any task.
To add an ad hoc task to a work order

3 In the Request Type field, select Ad hoc.
4 Click Relate.
Some fields in the form already contain data for the work order.
5 In the upper area of the form, complete the following required fields:
Name—Enter a descriptive name of the task.
Summary—Enter a brief description of the task.
6 In the General tab, complete information about the company.
The Company field defaults to the contents of the Location Information area in the
Work Order form (in the Classification tab). Your task can be assigned to a
different department or company.
7 In the Requester tab, complete information about the person creating the task
(Requester) and the intended target of the task (Requested For).
Some information is set by default from the Requested By information of the work
order.

8 In the Classification tab, complete information about the product and operational
categorizations.
9 (optional) In the Assignment/Dates tab, complete the fields to assign the task:
For the Assignee fields, the assignment engine automatically assigns the task when
the task is created according to how the administrator configured the application,
but you can override this if needed. See Chapter 12, “Configuring assignments.”
For the Scheduled Start Date and Scheduled End Date fields, you might want to set
the dates to be different from the dates of the parent work order.
10 In the Relationships tab, search for, and relate configuration items, LDAP objects,
and software library items that are needed with this task.
11 Click Save.
The task information form closes and you return to the Work Order form. The task
management subsystem enforces the dependencies between tasks. These relate to
any Sequence order specified in the Work Order form.
Adding predefined task group or task templates to a work order

You can relate a predefined task or task group template to the work order. If BMC
Remedy Change Management is installed, the following predefined “best
practice” task group and task templates are included. You can use these templates
for installing or deploying software and verifying task completion.
See the BMC Remedy Task Management System Administrator’s Guide.
Template Description
Create and Modify Policy Task group that includes the following tasks:
with Closed Loop Create and Modify Policy
Verification Closed Loop Verification (automatically)
You use this task group template when creating or
modifying a BMC CM based policy. This template
automatically performs a closed-loop verification to make
sure that the task was executed properly.
Closed Loop Verification Automatic task that calls BMC Configuration Management
(automatic) Policy Manager to set up compliance parameters for Closed
Loop Verification. It verifies the task automatically against
compliance status.
Create and Modify Policy Manual task that creates or modifies a policy that uses the
Policy Manager.
Deploy Package Manual task that deploys a package that uses the BMC
Configuration Management Deployment Manager.
Verification of a Deployment Manager task is based on the
exit status of the Deployment Manager job itself.
Execute Remote Command Manual task that executes a remote command that uses the
BMC Configuration Management Deployment Manager.
Verification of a Deployment Manager task is based on the
exit status of the Deployment Manager job itself.

Template Description
Execute Remote Script Manual task that executes a remote script that uses the BMC
Configuration Management Deployment Manager. You use
the Task Attachments table to define the remote scripts to be
used. Verification of a Deployment Manager task is based on
the exit status of the Deployment Manager job itself.
Verify Target Status Manual task for manually verifying the status of a target
against BMC Configuration Management. Use this task to
verify that a specified target is in compliance with the
policies to which the target is assigned.
To add predefined task group and task templates to a work order

3 Select Task Group Template or Task Template from the Request Type list and click
Relate.
All template types for all categories are listed in the Select Template dialog box.
You can filter the list by selecting the type and category of template.
4 (optional) Filter the templates by taking the following steps:
a Select the type of template:
With task group templates, select Standard or Sequencing.
Sequencing—A basic task group template that contains task templates and
task group templates, where users can change the sequence during the
execution phase.
Standard—An advanced task group template containing task templates and
task group templates that execute in the flow defined by the task
administrator.
See the BMC Remedy Task Management System Administrator’s Guide.
With task templates, select Manual, Automatic, or ALL.
b (optional) From the Category menu, select which application the task belongs to
(for example, Task Management System).
The available task groups or tasks for that selection appear in the list. The
categorization of the work order determines which list items appear.
5 (optional) Select a task template or task group template, and click View to see more
details about the task group or task template.
6 If a relevant task set appears in the list to include with the work order, select it, and
click Relate.
The dialog box closes and you are returned to the work order.

7 Repeat steps 3 through 6 for all templates to add to the work order.
The templates you selected appear in the Tasks and Task Groups list. If there are
no templates listed, refresh the form.
8 Define a numerical sequence of the tasks, as described in “Assigning a sequence
number to task groups and tasks” on page 278.
The task management subsystem enforces the dependencies between tasks. These
relate to any Sequence order you might have specified in the Work Order form.
9 Save the work order.
For additional information about searching for tasks assigned to you or your
group, see “Searching for assigned tasks” on page 280.
Canceling tasks
You can cancel tasks by accessing them through the Work Order form. This action
does not delete the task; it sets the status of the task to Closed and the closure code
to Cancelled.
To cancel a task
Console.
2 Select a work order, and click the Tasks tab.
3 Select the task to cancel, and click Cancel.
The status of the task is automatically set to Closed.
4 Click Save.
Closing tasks
When you have completed a task, you are ready to close it.
To close a task
Console.
3 In the Assigned Tasks table, select a task and click View.
4 In the task, click the Assignment tab.
5 Update the time you spent on the task.
You can create an entry in the effort log as needed.
7 Make an entry in the Work Info History field.
8 At the top of the Task form, set the Status field to Closed.

Service targets in Work Order Management
9 Select a status reason to describe how the task was closed.

10 Click Save.
Service targets in Work Order Management

If you have BMC Service Level Management (BMC SLM) installed, the Work
Order form shows both overview and in-depth information about the work order
in relation to applicable service targets. You can view the service targets and
milestones for the restoration of the unavailability. Service targets and milestones
are defined from BMC SLM. Escalations can be set up to notify the assignment
group prior to acknowledgement or resolution breach times.
In the Work Order form, you can view service targets defined in BMC SLM. Service
targets can be defined in BMC SLM for response time and resolution time. Service
targets can be determined by related CIs, and many other criteria. The Next Target
Date field indicates the next deadline out of all the service targets attached to the
work order.
To view service targets related to a work order, open the work order. SLM status
appears on the Work Order form.
Figure 11-5: SLM status shown on the Work Order form
The following table lists the status icons.

Icon Description
Status: Not Attached.
No service target is attached to the work order.
Click Details or the icon to open the SLM:Integration Dialog
form.
Status: Attached.
Green: The service targets are in compliance.
Click the icon to open the SLM:Integration Dialog form.

Icon Description
Status: Warning.
Yellow: At least one service target is at risk.
Click the icon to open the SLM:Integration Dialog form.
Status: Breached.
Red: At least one service target did not meet its goal. Click
Details or the icon to open the SLM:Integration Dialog form.
The colors on the Status Gauge on the SLM:Integration Dialog form show the
current status of the selected service targets.
Figure 11-6: SLM:IntegrationDialog form
The following table explains the items on the Status Gauge.

Item Description
Green The service target is in compliance.
Yellow The service target has a warning status.
Red The service target missed its goal.
Due Date and Time The goal time within which there must either be an initiation or a
completion for the work order. Otherwise the goal is missed.
Time Until Due The amount of time left until the goal is considered missed.
Time Past Due The amount of time that has passed since the goal was due.

Creating service targets for a work order
The following table describes the information in the SLM:IntegrationDialog form.
Column Description
Case ID The ID of the work order.
Details... Click to see details about the selected service targets.
Service Target table
SVT Title The name of the service target.
Goal The type of goal for the service target:
Initiation goal—The work order must be responded to within the
time specified.
Completion goal—The work order must be resolved within the
time specified.
Hours/Min The initiation or completion time stipulated in the goal.
Cost Per Min The cost per minute for missing the initiation or completion time
goal.
Due Date/Time The goal time within which there must either be an initiation or a
completion for the change request. Otherwise the goal is missed.
Progress The status of the service target:
Attached—The service target is attached to the work order.
Detached—The service target is not attached to the work order.
In Process—Work on the work order is taking place.
Pending—Work on the work order is stopped, for example,
waiting for a part.
Warning—The service target is at risk.
Missed or Met—The service target either missed or met its goal.
Invalid—The service target is disabled.
Milestones for SVT
Title The title of the milestone.
Execution Time The time the milestone actions are executed.
Status The status of the milestone is active, inactive (pending), or Action
Performed.
For information about managing BMC SLM, see the BMC Service Level Management
User’s Guide.
Creating service targets for a work order

If you have BMC Service Level Management (BMC SLM) installed, you can create
service targets and relate them to a work order to set goals and track the level of
service for the work order. You can view the service target from Work Order
Management.
Service targets created with BMC Remedy are internal targets related to
Operational Level Agreements (OLAs).

To create service target terms and conditions for a work order

1 From the Service Level Management Console, click the Service Target tab.
2 Click Create.
3 In the Service Target wizard, enter a title for the service target in the Title field.
4 Optionally, enter a description of the service target in the Description field.
5 From the Applies To list, select Work Order.
6 In the Goal Type field, select Work Order Resolution—The work order must be
completed within the time specified
7 Click Define next to the Terms and Conditions field to open the Qualification
Builder.
8 Enter any criteria that to use to build the qualification. All fields are optional.
Company, Region, Site Group, and Site responsible for resolving the work order
9 In the Customer tab, enter criteria in the Requested For, and Operational Level
Agreement (OLA) categories.
Select Exact Match if you want the term used in the qualification to be exactly the
same as you have selected or typed in the field. If Exact Match is not selected, you
can type in partial words to be used in the qualification.
10 In the Classification tab, enter criteria in the Classification, Service Categorization
Selection, and Product Categorization Selection categories.
11 In the Assignment tab, enter criteria in the Change Manager and Change Assignee
categories.
12 Click Show Qualification to enter your qualification in the Qualification field.
13 Save your qualification.
An example of a qualification is as follows:
'Priority' = "Medium" AND 'Location Company' = $\NULL$ AND
'Customer Company' = "ABC Company" AND 'Customer Organization' =
"SMBU" AND 'Customer Department' = "Research and Development" AND
'Product Cat Tier 1(2)' = "Hardware" AND 'Product Cat Tier 2(2)' =
"Inventory" AND 'Product Cat Tier 3(2)' = "Laptop" AND 'Owner
Support Company' = $\NULL$
If the service target is related to an agreement with an associated business service
CI, an additional qualification is added to your terms and conditions.
NOTE
To build a custom qualification, select Yes in the Custom Qualification check box,
and enter your qualification in the Advanced Qualification Builder

Configuring work order rules
Configuring work order rules

Use the Work Order Configuration Rule form to configure the method of
assignment to automatically select a work order assignee (not the assigned support
group, but the individual in the group) for work orders. Each company can have
its own assignment rules.
You can configure assignment for one company, or you can configure it for all
companies by using the Global option. When Work Order Management uses
assignment (for example, when it assigns a work order), the Assignment Engine
checks the assignment rules for the approver’s company. If no rules are found, it
uses the rules defined for Global.
NOTE
Some work order rules settings are automatically defined during installation of the
application.
To configure work order rules

tab.
Order > Rules, and click Open.
3 Select the company for which to configure assignment, or select the Global option.
Selecting Global configures assignment for all companies.
4 For the Work Order Rule Status list, select Enabled if you want this assignment to
be available to users.
5 To use the assignment engine to automatically assign work orders to individuals,
perform the following steps:
a Set Assignment Engine Integration to Yes.
b From the Assignment Process Manager list, select the appropriate assignment
process.
The following table describes the available assignment processes:
Assignment process Description

Capacity The capacity for each person is specified in the Capacity Rating
field on the People form. The assignment process is a ratio-
based method. For example, if person A has a capacity of 100
and person B has a capacity of 200, person B can handle twice
as many requests as person A; the assignment engine assigns
two tickets to B, and assigns one ticket to A.

Assignment process Description

Number The People form tracks the number of tickets assigned to each
person. The number assignment process selects the person
with the least number of requests assigned.
Round Robin The People form keeps track of the last time the person received
an assignment. The round robin assignment process selects the
person who was least recently assigned a request.
c From the Assignment Process Assignee list, select one of the options:
Capacity
Number
Round Robin
For information about configuring the assignment engine, see Chapter 12,
“Configuring assignments.”
6 From the Create Service Request on Submit list, select Yes or No.
If you select Yes, when a user submits a work order, a corresponding service
request is created. The customer can view this service request, which indicates the
status, through the Request Entry console.
7 Click Save.
NOTE
To modify a rule from the Work Order Configuration Rules form, search for the
appropriate rule, and open it.
Updating assignment availability

Your assignment availability status indicates whether you are available to accept
work assignments. If your status is “yes,” you are available. If your status is “no,”
you are not available.
You can quickly update your status by using the My Profile function.
To update assignment availability

Console.
2 Click Functions > My Profile.
3 From the Assignment Availability field, choose the status.
4 Click Save.

Updating your profile
Updating your profile

To view and edit your personal profile, click Functions > My Profile on the Work
Order Console to update your record in the People form. In this form, you can:
Update company information, such as organization, business, and home
address, and so on.
View permissions.
View nonsupport staff profiles.
To update your profile

1 On the Work Order Console, click Functions > My Profile.
2 Update the information at the top of the People form, or click the tab
corresponding to the area in which to change the profile information.
3 Click Save.
Setting Work Order Console preferences

You can view and edit the default appearance of the Work Order Console that
users see. For example, when the Work Order Console opens, you can determine
the default search criteria settings.
When you define your preferences (for example, All Open Work Orders are the
default setting for the Work Order Status field), this base set of preferences is
inherited in the Overview Console.
To set application preferences

1 In the Work Order Console, click Functions > Application Preferences.
2 In the Console View field at the top of the Application Preferences form, choose
which group searches the Work Order form and shows the results in the Work
Order Console.
The default setting is Personal, but you can, for example, choose Select Groups or
All My Groups.
3 In the Application Preferences dialog box, click the Work Order Management tab.
4 In the Search Criteria Default area for the console page, define the following
options:
Work Order Role—When the Console Focus is Work Orders, choose the setting
that appears in the Role field.
Work Order Type—When the Console Focus is Work Orders, choose the setting
that appears in the Work Order Type field.
Task Status—When the Console Focus is Task, choose the setting that appears
in the Status field. The default is All Tasks.

5 In the Overview Console area, define the following options:

Show Work Order—Choose Yes if you want work orders loaded into the
Assigned Work table when the console is opened.
Show Task—Choose Yes if you want tasks loaded into the Assigned Work table
when the console is opened.
6 In the Work Order Console Settings area, choose whether you want work orders
or tasks loaded into the main table on the console.
7 Click Save.
You must close and re-open the Work Order Console for the changes to appear.

Chapter
12 Configuring assignments
Assignment is based on organization, location, service, and product

categorization. Assignments are also associated with the application in which they
are used. An assignment can be broadly or narrowly defined, and can apply to
different systems.
Creating assignment routing (page 300)
Creating group assignments (page 301)
Automatic assignment to individuals (page 303)

Creating assignment routing

BMC Service Request Management enables you to automatically assign service
requests and work orders to support groups and roles (such as Service Request
Assignee, Work Order Manager, Work Order Assignee) by using fields on Service
Request and Work Order forms. These fields are used as a search criteria against
the Assignment Configuration form.
The following table lists the fields and mappings between the Assignment
Configuration form and the Service Request and Work Order forms. Assignment
routing filters on a service request or work order use a combination of these fields
to assign the corresponding group.
FROM: TO: TO:

Field on the Assignment Field on Service Request form Field on Work Order form
Configuration form
Contact Company (under Company (under Requested For) Company (under Requested For)
Organization)
Organization (under Organization) Organization (under Requested Organization (under Requested
For) For)
Department (under Organization) Department (under Requested For) Department (under Requested For)
Company (under Location) Location Company (under Company (under Location
Location Information) Information)
Region (under Location) Region (under Location Region (under Location
Information) Information)
Site Group (under Location) Site Group (under Location Site Group (under Location
Information) Information)
Site (under Location) Site (under Location Information) Site (under Location Information)
Tier 1, Tier 2, Tier 3 (under Category 1, Category 2, Category 3 Tier 1, Tier 2, Tier 3 (under
Operational Categorization) Operational Categorization)
Tier 1, Tier 2, Tier 3 (under Product No field is mapped. Tier 1, Tier 2, Tier 3 (under Product
Categorization) Categorization)
To create assignment routing

select the company.
2 Click the Create link next to Assignment.
3 In the Event field of the Assignment form, select the type of assignment entry.
For BMC Service Request Management, the following assignment entries are
applicable:
Service Request Assignee (required)
Work Order Manager (required)
Work Order Assignee (required)
Task Assignee (required)

Creating group assignments
Infrastructure Change Manager (required if BMC Service Request Management

is integrated with BMC Remedy Change Management)
Infrastructure Change Assignee (required if BMC Service Request Management
is integrated with BMC Remedy Change Management)
Incident Owner (required if BMC Service Request Management is integrated
with BMC Remedy Incident Management)
4 In the Description field, enter a description for the assignment.
5 From the Assigned Group list, select the support group to assign.
6 In the Routing Order area, specify when this assignment entry should be used for
the automated assignment.
Company—Select the location of the incident or request. If this routing applies
to all companies, select Global.
Operational Categorization—You can route assignments by operational
services.
Product Categorization—You can route assignments by product categorization.
7 Click Add.
Creating group assignments

The first step in creating assignment information is configuring a group
assignment. You can then use predefined assignment information for automatic
assignment to an individual in the assigned group using the Assignment Engine,
if needed. Advanced administrators can also define custom individual assignment
information for the Assignment Engine.
Even if you have already creating assignment routing for other BMC Remedy IT
Service Management applications, you must configure the Service Request
Assignee, Work Order Manager, and Work Order Assignee.
NOTE
If assignments are not configured, they must be manually entered.
From the Configure Assignment form, you can also modify or delete assignment
information.
Creating a group assignment

tab.
2 From the Application Settings list, choose Foundation > Configure Assignment >
Configure Assignment, and click Open.
The Configure Assignment form appears.

3 To change the form to New mode, click the New Request button on the form in a
browser or the New Request toolbar icon in BMC Remedy User.
4 In the Event field, select the type of assignment entry (for example, Work Order
Manager).
For more information, see “Assignment events” on page 303.
5 In the Assignment area, select the support company, support organization, and
assigned group to use for assignment.
6 In the Available Systems area, select the applications and modules to apply to the
assignment entry.
For Work Orders, make sure you select Work Order Management.
For example, you can create an assignment entry that applies only to BMC Remedy
Incident Management. This enables you to select different support groups for
assignment, even if the mapping selections are the same.
7 In the Routing Order area, further specify when this assignment entry should be
used for the automated assignment. (This is an advanced feature.)
The Contact Company and Company fields are required.
The Assignment entry can be mapped using the following data structures:
Organization
Location
Operational Categorization
Product Categorization
When BMC Service Request Management uses the routing order, which is a
feature of many of the main ticketing forms, it uses information from the form that
it is on to find an assignment entry, and in turn, the support group for assignment.
8 Click Save.
9 Create the group assignment for Work Order Assignee.
10 Create the group assignments for your company.
By default, assignment configuration records were installed out-of-the-box for
your use as templates. You can copy these records for your own company (for
example, to create Service Request Assignee, Incident Owner, or Infrastructure
Change Manager assignments).

Automatic assignment to individuals
Assignment events
The following table describes the assignment events.
Event Available systems Form assignment Description
Service Request All Service Request Used to assign a request to the request
Assignee coordinator group.
Task Assignee Task Management System Task Used to assign a task to the task
implementer group.
Work Order Work Order Management Work Order Used to assign a work order to the work
Assignee order management group.
Work Order Work Order Management Work Order Used to assign a work order to the work
Manager order management group.
Automatic assignment to individuals

After you have configured SRM group assignments, the round robin method of
assigning service requests and work orders to individuals is activated. By default,
BMC Service Request Management uses the round robin method in the
Assignment Engine to assign service requests and work orders to the person who
has gone the longest since receiving an assignment.
You can configure work orders to use different assignment processes for work
order managers and assignees (for example, load balance by capacity).
To remove a person from individual auto-assignment, set the Assignment
Availability field on the People record to No as described in the BMC Remedy IT
Advanced administrators can also define custom individual assignment
information for work orders with the Assignment Engine. For more information
about configuring the Assignment Engine for assignment to individuals, see the
BMC Remedy Action Request System Configuration Guide.


Chapter
13 Importing and Exporting PDTs

and SRDs
Service Catalog Managers can use the Import Export Console to export SRDs and
PDTs between source and destination servers.
This functionality also supports the portability of “best practice” service catalog
offerings from a community website.
Exporting SRDs and PDTs (page 306)
Importing SRDs and PDTs (page 308)
Viewing the history of imports and exports (page 312)
About migrating the application from test to production environments
(page 313)

Exporting SRDs and PDTs

When you export SRDs, or only PDTs, the export operation includes all related data
(for example, questions, images, category and entitlement data, and so on). The
Import Export Console exports this data so that the SRDs and PDTs operate
correctly.
When you export SRDs or PDTs, all related PDTs and AOTs are included in the
export operation.
To export or import SRDs, PDTs, and supporting data, you must have the Request
Catalog Manager permission. To import data, you must also have the BMC
Remedy AR System Administrator permission and you must install the BMC
Remedy Data Import tool, which is included with BMC Remedy Developer Studio,
on your local computer.
Export SRDs only when they are in Draft or Deployed status.
NOTE
To make sure that SRDs and PDTs are exported properly, confirm that the
reporting server is a BMC Service Request Management 7.6.00 or later server or
that the Report Server field is left blank. To confirm this, see the Advanced tab of
the BMC Remedy AR System User Preference form. (In BMC Remedy User, choose
Tools > Options, and click the Advanced tab.)
To export SRDs and PDTs, or only PDTs

1 Log into your source BMC Remedy AR System server with BMC Remedy User.
NOTE
The Import Export Console works only with BMC Remedy User; you cannot use a
browser.
2 Choose File > Open > Object List.

3 Open the SRM Import Export Console form.
4 From the left navigation pane, click Export Request Definition to export SRDs and
PDTs, or click Export Process to export only PDTs.
5 Search for the SRDs or the PDTs to export. You can use various search criteria (for
example, searching by Title or by Company).
6 Select one or more SRDs or PDTs from the search results table.
You can select multiple SRDs or PDTs and export them as a unit.
NOTE
If you do not start the export immediately, it is possible for the selected SRDs or
PDTs to be deleted by another Service Catalog Manager before you start the export
operation.

Exporting SRDs and PDTs
7 In the File Name field under Export Options, enter a path and file name.
A folder with the name of the file followed by a sequence of numbers is created,
containing images used by the SRDs. The .arx extension is automatically added
to the export file.
If the specified export file exists, the file is appended to and an additional folder is
created that contains images used by the SRDs. This behavior is useful if you want
to add new SRDs and PDTs to an existing file. If you want to create a new export
file, enter a new file name, or delete the contents of the original export file.
8 Click Export.
9 If you see the AR System User - Note dialog box, click OK.
When the export operation is completed, the History window appears. You can
navigate to the path for the export file to verify that the file was exported. The
search results table in the History window shows information about the export.
See “Viewing the history of imports and exports” on page 312.
Exporting supporting data

You can export supporting data in bulk that is available on your server. You can
export all the supporting data from your server, or only specific items (for example,
only the questions).
IMPORTANT
You cannot import BMC Service Request Management data (AOTs, PDTs, SRDs,
and any supporting data) that was exported using one version of BMC Remedy
Incident Management and BMC Remedy Change Management to the destination
server running a different version of BMC Remedy Incident Management and
BMC Remedy Change Management. For example, if your BMC Service Request
Management data was created on a source BMC Remedy AR System server
running BMC Remedy ITSM 7.x, you must import it to a destination server
running BMC Remedy ITSM 7.x. You cannot mix-and-match BMC Remedy ITSM
6.x and 7.x versions when exporting and importing.
To export supporting data

4 From the left navigation pane, click Export Supporting Data.
5 Select one or more of the following options:
All Supporting Data—Exports all underlying support data from your source
server, including navigation categories.
Configure Survey Questions—Exports survey questions tied to a specific SRD or
survey questions defined as default for all SRDs for a given company.

Service Request Images—Exports all images used with your SRDs and
navigational categories.
Category Data—Exports navigational categories for SRDs and the images that
are related to the categories.
Entitlement Data—Exports entitlement rules.
Questions—Exports questions text and question menu items.
6 In the Export Options field, enter a path and file name.
The .arx extension is automatically added to the export file. If the specified export
file exists, the file is appended to.
7 Click Export.
When the export operation is completed, the History window appears. You can
navigate to the path for the export file to verify that the file was exported.
The search results table in the History window shows information about the
export. See “Viewing the history of imports and exports” on page 312.
NOTE
If advanced interface forms (for example, the Password Reset form) are attached to
your SRDs, you must export and import them manually. For more information
about advanced interface forms, see “Advanced interface forms—Overview” on
page 346.
Importing SRDs and PDTs

After you export SRDs and PDTs, you can import them to the target system. The
import utility uses BMC Remedy Data Import, which comes with BMC Remedy
AR System. See the BMC Remedy Action Request System Configuration Guide.
Before you import the definitions to production forms, you might want to modify
the definitions. The import utility provides options to avoid conflicts on the
destination BMC Remedy AR System server when you are importing definitions.
The import operation “stages” the data, so that you can monitor the progress of the
import operation. If needed, you can “back out” from the import operation by
deleting the staged data. When you validate the data, the modifications are applied
to the staged definitions. The import data is imported to the destination server only
when you promote it.
NOTE
If you delete an SRD, the related requestable offering in the Atrium Service Catalog
is not deleted until the data is purged (this is usually a scheduled process). If you
export and then import that SRD on the same computer, make sure that the related
requestable offering is purged, or the SRD will not be overwritten properly.

About the Version and Patch fields

The Version field and the Patch field in SRD and PDT forms hold the version and
patch level of the application on the export system. This information is used to
dictate which version of exported data can be imported onto a system. The added
Version information is included only in exported BMC Service Request
Management 7.6.00 (or later) data.
During the staging (on the merge), the version checking is executed to check
versions of imported SRDs and PDTs against the version of the import system. If
the import system version is older than the version of an SRD or PDT, the
SRS:ImportExportCompatibility form is checked for compatibility information. If
this information is not found, a warning is issued that the version of the SRD or
PDT is newer than the version of the target system. If the Version Compatibility is
not Enforced option (default setting) is selected in the Version Checking Mode
field on the Import Export Console, the warning can optionally be ignored. If the
Enforce Version Compatibility option is selected, the warning is treated as an
error, and the import operation is terminated.
NOTE
To export BMC Service Request Management 2.0.00, 2.1.00, or 2.2.00 data, you
must first upgrade the application to BMC Service Request Management 7.6.00 (or
later). You can then export the data from the BMC Service Request Management
7.6.00 (or later) system and import it to another BMC Service Request Management
7.6.00 (or later) system.
About importing data from another company

If you are importing data that was exported from a different company, note the
following:
Categories—Matching categories are created for the new company if they do not
exist. If they exist, the sub-categories (level 2 and 3) might need to be updated in
the imported SRDs.
Surveys—Matching surveys are created for the new company if they do not
exist. If they exist, nothing needs to be updated. The imported SRDs point to the
matching surveys after the import.
Entitlement Rules—If entitlements exist, the imported entitlements will be
skipped. If there are no duplicates, everything is imported as is. Entitlement
data is imported and duplicate entitlement data is skipped.
Permission Groups—Permission Groups (along with their corresponding
People) are not copied to the new company.

NOTE
For access permissions groups that are included in an entitlement definition, a
warning is issued if a matching permission group for the new company is found.
The warning states: The import process has encountered a warning. The
entitlement group has been skipped, since the definitions are being
applied to the new company. The import process has found the
entitlement group that matches the new company and updated the
related People Entitlement Definitions.
The import process retains the values for the original company and the
following information might need to be updated manually.
Navigational categories (levels 2 and 3)
Request Catalog Manager
Service Request Coordinator
Request Catalog Manager
Entitlement rules
Approval chains
Importing SRDs linked to Atrium Service Catalog

If you import an SRD that was linked to a requestable offering (RO) from the
Atrium Service Catalog, make sure that the related Atrium data is imported first
(through Atrium Integrator). This ensures that the RO relationship data is
preserved.
If you do not import the Atrium data first, the data is not preserved. A new RO is
created as a Transactional offering, and the Service and Service Offering fields on
the SRD are empty.
NOTE
Manually creating the related Atrium data does not ensure that the RO
relationship data will remain after you import the data. In this case, the keys used
to maintain the relationship will not match, and the RO information is lost. You can
associate the imported SRD to the new Business Service and Service Offering.
To import SRDs and PDTs

1 Log into your destination server with BMC Remedy User.
NOTE
The import utility works only with BMC Remedy User; you cannot use a browser.

4 From the left navigation pane, click Import.

5 In the Import Command area, enter the following information:

a In the User Password field, enter the password to the target BMC Remedy
AR System server.
b In the Path field, enter the path to the BMC Remedy Data Import batch file
(DataImportTool.bat).
This batch file comes with BMC Remedy Developer Studio. By default, the
install path is:
C:\Program Files\BMC Software\AR System\dataimporttool\.
c In the Import Path and File Name field, enter the path and file name to the
definition file (.arx) to import.
d In the Import Log field, enter the location to the import log.
By default, the location is:
C:\Program Files\BMC Software\AR System\dataimporttool\
SRMImportLog.txt
6 Click the 1. Stage Data button.
In the Import Data Options area, select the option to use to resolve conflicts with
importing definitions to your destination BMC Remedy AR System server:
Option Description
Import new definitions only If the import operation finds existing definitions, the import
(skip duplicates) operation continues but skips any duplicates.
Import new definitions only If the import operation finds existing definitions, the import
(if existing definitions operation is cancelled.
found, cancel import)
Import all definitions as The import operation avoids the possibility of conflicts by
new (rename all by adding renaming the definitions. To avoid duplicate SRDs and
a prefix to name) PDTs, the utility enables you to add a prefix or version
number to the object names. You are limited to 19 characters
in the prefix.
Imported objects can include an optional version level, as
you manage the development, test, and production life
cycle, for example, 00.80 for Beta, or 01.00 for first roll out to
customers.
Apply the imported If you select this option, the Company field appears, listing
definitions to a different all companies available on the import system.
company
Keep Template Select the Yes option to keep AOT and template associations
Associations relationships. Otherwise, select No to remove AOT and
template associations relationships.
7 (optional) Click the Validate Staged Data button.

The Import utility validates the data and shows the results in the Import Results
table. For example, the names of the SRDs and PDTs changed by the import utility
appear. The Details table shows the SRD records imported to their forms.

Depending on the conflict resolution option you selected, the validate stage
attempts to correct the staged data, if necessary, so that the data can be imported
to the production forms. For example, the validate stage checks if you can properly
apply the company to the staged AOTs, PDTs, and SRDs.
NOTE
One important error message you might see is that you are attempting to import
objects to your BMC Remedy AR System server that have the same name as
existing objects. If this message appears, you should import the objects as new and
rename them. The Validate stage makes sure that you do not duplicate existing
data in the production forms after you perform the import. Otherwise, you can
delete the staged data and try again.
If necessary, click the Delete Staged Data button to delete the staged data.
8 Click the 2. Promote Staged Data button.
In the promote stage, the import utility completes the import of data to the BMC
Remedy AR System server.
Viewing the history of imports and exports

The History View window shows the history records of your imports and exports.
To view the history of imports and exports

1 Log into your BMC Remedy AR System server with BMC Remedy User.
4 From the left navigation pane, click History.
5 In the Operation field in the History View window, select Export or Import as the
operation to view.
6 (export only) In the Type field, select SRD, PDT, or Supporting Data as the type of
data to view.
7 Click Search after you have specified your search criteria (for example, SRD as the
Type of data and Export as the Operation).
The history data appears in the search results table.
8 (optional) Click the header of the column by which to sort the table.
9 To print the a list of the data in the table, follow these steps:
a Right-click in the table.
b From the menu, choose Print Table.
This prints a list of all the items in the table, including those that are not in view.
c In the Print dialog box, enter the printing specifications, and click OK.

About migrating the application from test to

production environments
Use the following migration steps when migrating the application from test to
production systems. This procedure makes the following assumptions:
BMC Remedy AR System is installed and configured on the target server
All required add-ons are installed and configured on the target BMC Remedy
AR System server (for example, BMC Remedy Email Engine, BMC Atrium
Integration Engine, BMC Remedy Approval Server, Assignment Engine)
All required BMC Remedy IT Service Management applications are installed
and configured on the target server
The application is installed and configured on the target BMC Remedy AR
System server
All Foundation data is installed and configured on the target BMC Remedy AR
System server
You would find this overview helpful if, for example, in your test environment,
you added an SRD that reuses an existing PDT. If you also added approval rules,
entitlement rules, and work order assignment rules to support this new service, the
following procedures help you move this service to your production system with
the confidence that it will work the same way as it does in your test environment.
Exporting definitions from your test environment

The following procedure describes the definitions that you should export from
your test environment. For more information about exporting definitions, see the
BMC Remedy Action Request System Configuration Guide.
To export definitions from your test environment

1 Open BMC Remedy Developer Studio on your test environment server.
2 Choose File > Export to open the Export Wizard.
3 Expand BMC Remedy Developer Studio in the tree.
4 Select Object Definitions, and click Next.
5 Select the BMC Remedy AR System server from which to export objects, and click
Next.
6 In the Export Objects dialog box, click Add to open the Add Items dialog box.
7 Click the objects to export.
Include the following forms with your export operations:
All modified standard forms
All custom advanced interface forms

NOTE
On custom advanced interface forms, use the Directly Related option to migrate
the forms and custom workflow. You should attach the standard workflow on the
target BMC Remedy AR System server after the custom advanced interface form
is imported. See “Creating advanced interface forms from templates” on page 347.
All custom (new) forms

8 From the Add Items with Related Properties list, select the Directly Related option
so that you copy all objects related to the forms (for example, workflow, menus,
web services, and so on).
9 Click Next.
10 To add more objects, click Add, and repeat steps 6 through 8.
This enables you to copy the following:
Any additional modified standard workflow
All custom (new) workflow
11 When the list is complete, click Next.
12 In the To File field of the Options page, enter the directory and file names for the
objects being exported.
Make any corrections or use other options as necessary. You can save the file
as.def (AR System definition format) or .xml type.
13 Click Finish to start the export operation.
Exporting additional supporting data from your test environment

The following procedure describes how to run a BMC Remedy AR System report
to export the remaining supporting data from your test environment. You perform
a search on the fulfillment configuration forms used in the Application
Administration Console and run the report to export the underlying data in .arx
format.
Export the data from the following fulfillment configuration forms:
Define Application Field—SYS:Form Field Selection (if you added new
fields)
Approval Mappings—APR:Approver Lookup
Navigational categories
SRM:Navigational Category Strings
SRM:CategoryReference
SRD Levels
SRD:SRDLevelCompanyModuleAssoc
SRD:SRDLevel
On Behalf Of Management—OBO:OnBehalfOfDefinition

Service Target Defaults—INT:SLMSRS:ConfigServiceTarget:Defaults

Work Order Rules—WOI:CFG Rules
Templates
Work Order Template—Work Order Template
Task Group Template—TMS:TaskGroupTemplate
Variable Template—TMS:VariableTemplate
To export additional supporting data from your test environment

1 Log into BMC Remedy User on your test environment’s BMC Remedy AR System
server.
2 Open a fulfillment configuration form (see the preceding list) in Search mode.
3 Run an unqualified search.
4 Select all the records.
5 Click Report.
6 Click New Style.
7 In the Properties dialog box, click Add All to include all the fields to the report, and
click OK.
8 Choose Report > Export To > File.
9 Use the form name to name your data file (for example, SYS_Form Field
Selection.arx).
Make sure that you save the report as .arx type.
10 Repeat this procedure for each form in the list of the fulfillment configuration
forms.
Exporting SRDs from your test environment

Use the following procedure to export SRDs from your test environment. See
“Exporting SRDs and PDTs” on page 306.
To export SRDs from your test environment

4 From the left navigation pane, click Export Request Definition.
5 Search for the SRDs to export.
6 Select one or more SRDs from the search results table.

7 In the Export Options field, enter a path and file name.

8 Click Export.
Importing definitions to your production environment

The following procedure describes the steps for importing BMC Service Request
Management definitions to your production environment.
To import definitions to your production environment

1 Open BMC Remedy Developer Studio on your test environment BMC Remedy AR
System server.
2 Choose File > Import.
3 From the Import Wizard, expand BMC Remedy Developer Studio in the tree.
4 Select Object Definitions, and click Next.
5 Select the BMC Remedy AR System server from which to export objects, and click
Next.
6 In the Import File dialog box, select the .def file, and click Next.
7 Select Replace Objects on the Destination Server, or other options as necessary.
8 Click Finish to start the import operation.
Importing data to your production system

The following procedure describes the steps for importing BMC Service Request
Management data to your production environment. See the BMC Remedy Action
Request System Configuration Guide.
To import data to your production environment

1 Open BMC Remedy Data Import on your production environment.
2 Choose File > Preferences to define your import preferences.
3 Choose File > New Mapping to create a mapping file, or use a saved mapping file.
4 Choose Import > Start Import to import the data.
If errors occur, the type of messages you receive depend on what you enter in the
Bad Records field. After the import ends, a results message appears and the import
log is updated. You can then use your imported data.
Importing SRDs to your production environment

Use the following procedure to import SRDs to your production environment. See
“Exporting SRDs and PDTs” on page 306.

To import SRDs to your production environment

4 From the left navigation pane, click Import.
5 Enter the password for the target BMC Remedy AR System server that you are
importing data to.
6 Enter the path to the BMC Remedy Data Import batch file (DataImportTool.bat).
7 Enter the path and file name to the definition file (.arx) to import.
8 (optional) If necessary, modify the location to the BMC Service Request
Management import log. By default, the location is:
C:\Program Files\BMC Software\AR System\dataimporttool\
SRMImportLog.txt
9 Click the 1. Stage Data button.
10 Review the data import error logs.
11 Click the Validate Staged Data button.
12 Click the 2. Promote Staged Data button.
In the Promote stage, the Import utility completes the import of data to the BMC
Remedy AR System server, and shows you the results in the Import Results table.
For example, you are shown that the import operation was completed by the
import utility.
IMPORTANT
When you export SRDs/PDT, the templates for the Work Order and other BMC
applications are not exported. You must independently export the templates, and
then import and configure them up on the target server as a separate step. If an
AOT includes a template, the import export utility does not import the template
along with the AOT, but includes the AOT reference to the template. As a result, if
the template exists on the destination BMC Remedy AR System server, the AOT
uses that template after the import is finished. If the template does not exist on the
destination BMC Remedy AR System server, the import export utility imports the
AOT, but it is set to inactive. To activate the AOT, you must register a template
with the AOT. See “About registering application templates with AOTs” on
page 86.
13 In the Import Export Console, select Import from the left of the Import/Export
form, and enter the password and path to the import file.
14 Validate that the questions work (you might need to remap the questions), and
verify the field mappings from the SRD.


Chapter
14 Opening the Request Entry

console in context
Users can open the Request Entry console in context by specifying the context in
the URL used to access the console, or by using a BMC Remedy AR System Open
Window action, which specifies the context in the On Dialog Open Action.
Using the Context URL Builder utility to generate URLs (page 320)
Using context fields when creating launch-in-context URLs (page 324)
Manually creating URLs to open the Request Entry console in context (page 327)
About using an Open Window action to open the Request Entry console in
context (page 327)
Examples of launch-in-context URLs (page 328)
Using the Context URL Builder utility to generate URLs (page 320)
Manually creating URLs to open the Request Entry console in context (page 327)

Using the Context URL Builder utility to

generate URLs
You can use the Context URL Builder utility (SRS:SRCLaunchURLBuilder) to
generate the URLs that open the Request Entry console in context. These URLs can
appear in a portal, in a knowledge base entry, or some other web page that links to
BMC Service Request Management.
Figure 14-1: Context URL Builder utility
To use the Context URL Builder utility to generate URLs

1 Log into the BMC Remedy AR System server as a BMC Remedy AR System
administrator.
2 In a browser or BMC Remedy User, open the SRS:SRCLaunchURLBuilder helper
form.
Based on the server you logged in to, the values in the Mid Tier Path and Server
fields are automatically filled in. You can modify these fields as needed (for
example, with a different mid tier or server).

Using the Context URL Builder utility to generate URLs
3 Enter the following information to define the launch URL:

Restrict Acting On Behalf Determines if the On Behalf Of link is disabled when the console is launched.
Of The default value is No—the link is not disabled, and the user can act on behalf of
another user.
Restrict Navigation Determines if the navigation links outside the work area (Popular Services,
Submitted Requests, Broadcasts, and so on) are disabled when the console is
launched.
The default value is No—the link is not disabled, allowing users to navigate away
from the specified context.
Close Console After Determines if the console closes immediately after the user submits a request.
Request Is Submitted The default value is No.
4 Perform the following steps, depending on the Request Entry console view you
selected:
If you selected Perform these steps to generate a URL

Service Categories 1 From the View field, select Service Categories.
2 Click Generate URL.
A URL appears in the URL field, for example:
http://MidTier:8080/arsys/forms/TestServer/
SRS:ServiceRequestConsole/
?mode=submit&F303900000=1&F303906700=0&F303902000=0&F303902
100=0
Service Subcategories 1 From the View field, select Service Subcategories.
2 Select a subcategory.
?mode=submit&F303900000=2&F303906900=ID00137260F2FC6Dv6SQ5r
SKEABGEH&F303906700=0&F303902000=0&F303902100=0


Services 1 From the View field, select Services.
2 Enter a search string.
3 Click Launch URL encoder.
Not all characters are valid in URLs (for example, the # character or certain
GUIDs). This utility helps you create valid URLs.
4 In the ARURLEncoder form, enter the original string.
5 Click Convert.
6 Copy the encoded string and paste it into the URL Encoded String field in the
Context URL Builder utility.
A URL appears in the URL field, for example (searching for “BMC Remedy
Change Management” as a string):
?mode=submit&F303900000=3&F303906900=ID00137260F2FC6Dv6SQ5r
SKEABGEH&F303901700=BMC%20Remedy%20Change%20Management&F303
906700=0&F303902000=0&F303902100=0
Provide Information 1 From the View field, select Provide Information.
2 Search for an SRD to use in context (for example, by company or title).
3 Select an SRD from the table list of search results.
A URL appears in the URL field, for example (selecting “Create new badge” as the
SRD):
?mode=submit&F303900000=4&F303900900=SR00137260F2FCxjr6SQwk
iGEAel4H&F303906700=0&F303902000=0&F303902100=0
Service Review 1 From the View field, select Service Review.
2 Search for an SRD to use in context (for example, by company or title).
3 Select an SRD from the table list of search results.
A URL appears in the URL field, for example (selecting “Create new badge” as the
SRD):
?mode=submit&F303900000=5&F303900900=SR00137260F2FCxjr6SQwk
iGEAel4H&F303906700=0&F303902000=0&F303902100=0

Using the Context URL Builder utility to generate URLs

Cart 1 From the View field, select Cart.
?mode=submit&F303900000=6&F303906700=0&F303902000=0&F303902
100=0
Submitted Requests 1 From the View field, select Submitted Results.
2 From the Show field, select the status to display (for example, All Open Requests
or Draft Requests).
A URL appears in the URL field, for example (selecting All Open Requests):
?mode=submit&F303900000=7&F303901600=10&F303906700=0&F30390
2000=0&F303902100=0
For more information, see “Examples of launch-in-context URLs” on page 328.

5 (optional) To make sure that your URLs are properly encoded, perform the
following steps:
a Open the URL Encoder form.
http://webServer:port/arsys/shared/ar_url_encoder.jsp
b Enter the original string to encode.
c Click Convert.
d Copy the encoded string.

Using context fields when creating launch-in-

context URLs
When creating launch-in-context URLs, context fields have been added to the
Request Entry console to specify which view to launch, the context to display, and
the behavior of the console after it is launched. The following table lists the context
fields, and provides a description of the values used to set the context.
Field name Database ID Values Description

Context_View 303900000 1—Browse Categories view. This field value is required for all
2—Browse Subcategories view. views. The Context_View field is
This value requires that field used to designate which view to
Context_Category1_Base_ launch.
InstanceId be set.
3—Services view. This value
requires that the
Context_Search_Category and
Context_Search_String fields be
set.
4—Provide Information view.
This value requires that the
Context_SRD_InstanceId field be
set. It also optionally uses the
Context_SRD_Number field in
place of the
Context_SRD_InstanceId field.
5—Service Review view. This
value requires that the
Context_SRD_InstanceId field be
set. It also optionally uses the
Context_SRD_Number field in
place of the
Context_SRD_InstanceId field.
6—Cart view.
7—Submitted Requests view.
This value requires that the
Context_Request_Show field be
set.
Context_Category1_Base_ 303906900 Category 1 (Navigational This field value is required when
InstanceId Category) instanceId. This value the Context_View is 2. It is used
might need to be URL encoded. to specify the category to display
subcategories for.

Using context fields when creating launch-in-context URLs

Context_Search_Category 303901800 All—Search within all services. This field value is required when
Quick Picks—Search within the Context_View is 3. It specifies
services that are designated as the category under which a
Quick Picks. These include user search for services is constrained.
favorites, system requests, and
services most requested.
categoryName—Search within
services that are configured with
the designated category 1
navigational category. This value
might need to be URL encoded.
Context_Search_String 303901700 A URL encoded string used to (optional) This field value is used
limit the search for services. when the Context_View is 3. This
string is used to check the Service
Request Definition search cache
field. The search cache field
contains a string representation
of a combination of an SRD’s
title, navigational categories, and
keywords.
Context_SRD_InstanceId 303900900 Service Request Definition This field value is required when
instanceId. This value might the Context_View is 4 or 5. It is
need to be URL encoded. used to specify the SRD to be
used in the context of the view. If
the Context_SRD_Number field
value is set instead, the
Context_SRD_InstanceId value
is set by workflow that looks up
the value based on the
Context_SRD_Number value.
Context_SRD_Number 301628200 Service Request Definition ID (optional) This field value is used
when the Context_View value is
4 or 5. It is used to specify the
SRD to be used in the context of
the view. It can be used in place
of the Context_SRD_InstanceId
field value. It is used by
workflow to lookup the
Context_SRD_InstanceId field
value.
Context_Request_Show 303901600 10—All open requests (default) This field value is required when
20—Draft requests the Context_View is set to 7. It is
used to specify the filter value for
30—Requests needing attention
the Submitted Requests.
40—Recently closed requests
50—Requests closed since last
log in
60—Closed requests


Context_Restrict_ 303902000 0—No (default) This field is required, but is set to
Navigation 1—Yes 0 by default. Its value determines
whether the navigation links
outside the work area (Popular
Services, Submitted Requests,
Broadcasts, and so on) are
disabled when the console is
launched. If the value is set to 1,
the links are disabled, forcing
users to drill down towards
submitting a request only by
using the buttons in the work
area to control the navigation.
Context_Restrict_OBO 303906700 0—No (default) This field is required, but is set to
1—Yes 0 by default. Its value determines
whether the On Behalf Of link is
disabled when the console is
launched. If the value is set to 1,
the link is disabled, and users
cannot act on behalf of another
user.
Context_PI_ 303902100 0—No (default) This field is required when the
CloseAfterSubmit 1—Yes Context_View field is set to 4 or
5. It is set to 0 by default. Its value
determines whether the console
closes immediately after the user
submits a request.
Context_ 303931400 This field is used when
EntitlementVerified Entitlement Management is set
to On, to verify whether the user
is entitled to request the SRD
specified in the context. The
value is set by workflow on the
Service Request console.
Context_ 302792000 1000—Online This field is used when the
TakeSRDOfflineFlag 2000—Offline Context_View field is set to 4 or 5
It verifies that the SRD specified
in the context is online for users
to request. The value is set by
workflow on the Service Request
console.
Context_VerifyFailed 303932500 0—No (default) This field is used when the
1—Yes Context_View field is set to 4 or 5
It verifies that the SRD specified
in the context is online and the
user is entitled to request it when
Entitlement Management is set
to “On.” The value is set by
workflow on the Service Request
console.

Manually creating URLs to open the Request Entry console in context
Manually creating URLs to open the Request

Entry console in context
If you do not use the SRS:SRCLaunchURLBuilder helper form to generate the
URLs, this section describes the requirements for manually creating URLs for
opening the Request Entry console in context.
The URLs must be formatted as follows:
http://webServer:port/arsys/forms/ARServer/SRS:ServiceRequestConsole/
?mode=submit&FfieldId=paramValue&FfieldId2=paramValue2&FfieldId3=paramValue3
The variables in the URL are defined as follows:
webServer is the fully qualified name of the BMC Remedy Mid Tier system,
specified in the format serverName.company.com.
port is an optional port number, which is needed if the web server is not on the
default port (port 80).
ARServer is the name of the BMC Remedy AR System server that contains the
application.
fieldID is the database ID of the field for which you must supply a value when
the Request Entry console opens. For more information, see “Using context fields
when creating launch-in-context URLs” on page 324.
paramValue is the value to populate in the field when the Request Entry console
opens.
About using an Open Window action to open

the Request Entry console in context
To open the Request Entry console in context from an Open Window action, you
must supply values for the context fields of the SRS:ServiceRequestConsole form.
These fields specify which view to launch, the context to display, and the behavior
of the console after it is launched. The table in “Using context fields when creating
launch-in-context URLs” on page 324 lists the context fields, and provides a
description of the values used to set the context. For information about the Open
Window Action, see the BMC Remedy Action Request System Workflow Objects Guide.

Examples of launch-in-context URLs

The following table lists example launch-in-context URLs:
Context Sample URL
Service http://webServer:port/arsys/forms/ARServer/
categories SRS:ServiceRequestConsole/
?mode=submit&F303900000=1&F303906700=0&F303902000=0&F303902100=0
Service http://webServer:port/arsys/forms/ARServer/
subcategories SRS:ServiceRequestConsole/
?mode=submit&F303900000=2&F303906900=ID00137260F2FChCXySQ_AVfAAWUw
A&F303906700=0&F303902000=0&F303902100=0
Services http://webServer:port/arsys/forms/ARServer/
?mode=submit&F303900000=3&F303906900=ID00137260F2FChCXySQ_AVfAAWUw
A&F303901700=report%20a%20problem&F303906700=0&F303902000=0&F30390
2100=0
Provide http://webServer:port/arsys/forms/ARServer/
information SRS:ServiceRequestConsole/
?mode=submit&F303900000=4&F303900900=SR000F1F6C79D85P3MRQE2hwBAvPQ
A&F303906700=0&F303902000=0&F303902100=0
Service review http://webServer:port/arsys/forms/ARServer/
?mode=submit&F303900000=5&F303900900=SR000F1F6C79D85P3MRQE2hwBAvPQ
A&F303906700=0&F303902000=0&F303902100=0
Cart http://webServer:port/arsys/forms/ARServer/
?mode=submit&F303900000=6&F303906700=0&F303902000=0&F303902100=0
Submitted http://webServer:port/arsys/forms/ARServer/
requests SRS:ServiceRequestConsole/
?mode=submit&F303900000=7&F303901600=30&F303906700=0&F303902000=0&
F303902100=0

Appendix
A Internationalization and
localization
This section provides advanced instructions in localizing the application.

About internationalization and localization (page 330)
Supported languages (page 330)
About localizing the application (page 331)
Configuring the BMC Remedy AR System server for localization (page 333)
Localizing navigational categories (page 333)
Localizing SRD levels (page 335)
Localizing questions to use with SRDs (page 335)
Localizing AOTs (page 337)
Localizing PDTs (page 337)
Localizing SRDs (page 338)
Localizing surveys in an SRD (page 339)
Localizing advanced interface forms (page 340)
Finishing localization (page 341)
About localization problems (page 342)
Using the localization utility to change the locale (page 343)

About internationalization and localization

The application is built on BMC Remedy AR System, which is a robust
internationalized environment. This environment includes internal support for
different character sets and a suite of features that enables administrators to
produce localized applications. In addition, support is provided for a locale model
in which users can specify their language and formatting preferences to have the
application delivered in the style that is the most useful to them. With this model,
the same application can be delivered simultaneously to different users in multiple
languages.
You can localize BMC Service Request Management in the following ways:
You can define Navigational Categories and SRD Levels in multiple languages.
You can define the display properties for application object templates (AOTs),
process definition templates (PDTs), and service request definitions (SRDs) in
multiple languages. The display properties of these object are then
automatically related to each other.
You can define Questions in different languages. The display properties of
Questions (unlike, for example, AOTs) are not automatically tied to each other.
End users can see the service requests available in their own language.
You can define a custom date/time format. Enter the custom date/time format
on the Locale tab on the AR System User Preferences form. For more
information, see “Defining date and time questions” on page 215.
Supported languages
The application is localized in the following languages:
English
Brazilian Portuguese
French
German
Italian
Japanese
Korean
Simplified Chinese
Spanish

About localizing the application
In addition, localized help is available to users who are working in the Request
Entry console and the Business Manager Console. It consists of a separate set of
localized HTML help files that are accessed from the web-based forms by clicking
the Help link. For information about making help available to your users, see the
BMC Service Request Management Installation Guide.
About localizing the application

You should localize all content that appears to users in the Request Entry console.
This section guides you through the steps of localizing the display properties in the
languages of your user community.
You do not need to perform these advanced configuration and administration steps
immediately, but only after you understand basic BMC Service Request
Management functionality. For example, display properties you can localize
include navigational categories, AOTs, SRDs, and so on.
The following sections describe the best practices you should follow when
localizing the application for your particular environment.
Locale fallback mechanism

Locale behavior affects the entire chain of BMC Service Request Management
objects, from SRD > PDT > AOT > Questions > Navigational Categories > Browse
for Service details. If a BMC Service Request Management object is not localized, it
might be invisible to your users.
The application uses the following fallback lookup mechanism when selecting a
view for the user’s browser:
1 The mid tier first uses the locale defined in the AR System User Preference form.
2 If there are no user preferences, the system selects the appropriate view for the
user’s browser.
3 If the view with the user’s preferred locale is not found, the system checks the
operating system of the user’s computer.
4 If there is no exact match during any of these stages, the fallback mechanism finds
the closest possible locale to the one requested.
The application uses the following fallback mechanism for locale (following the
BMC Remedy AR System behavior) in BMC Remedy User:
1 If a user indicates a locale as a preference in the Options dialog box in BMC
Remedy User, the view that matches the selected locale is used. It is first matched
by language and country, and then by the language if the country is not specified.
2 If no locale preference is set, a view with a blank locale, or the locale of operating
system on the user’s computer, is used.
3 If no locale preference is set and there is no view with a blank locale, an available
view for the selected form appears.

The resulting view then appears. For example, if a user has es_AR
(Spanish_Argentina) selected as a preference, but there is no view created for
es_AR, the view created with locale es appears. So creating a view with locale es
covers all Spanish users, regardless of whether the user’s preferred locale is es_AR
or es_ES.
Fallback mechanism for Popular Services and DVF data

The application uses the following fallback lookup mechanism when selecting
data, for example, displaying the Popular Services items in the Request Entry
console:
1 The Request Entry console searches for data with the exact user locale, for example,
en_US.
2 If the Request Entry console cannot find data with the en_US locale, it performs a
wildcard search using en%.
3 If the Request Entry console still cannot find any data, it searches for data where
the locale setting is null.
When the DVF retrieves data to display, it follows the same sequence as the
1 The DVF searches for data with the exact user locale.
2 The DVF then performs a wildcard search, for example, en%.
3 The DVF then searches for data with a null locale value.
4 If the DVF still cannot find any data, it searches for the navigational category of the
initial view.
Localizing BMC Service Request Management objects

The various BMC Service Request Management objects (for example, navigational
categories or SRDs) appear based on the locale fallback mechanism of BMC
Remedy AR System. If BMC Remedy AR System finds at least one localized object
for the client locale (for example, en_US), it does not display the other localized
objects defined in other locales.
By default, the BMC Service Request Management sample data was defined with
null locale values. If you do not localize any BMC Service Request Management
objects, the sample data (for example, the navigational categories) appears the first
time that you log into the Request Entry console. Any users logging in to the
system are guaranteed to see this sample data.
But when you localize an BMC Service Request Management object (for example,
a navigational category with the en_US or fr locale), users who log into the system
with the fr locale no longer can see the sample data with null locales. Users see
only those BMC Service Request Management objects that match their client locale.

Configuring the BMC Remedy AR System server for localization
To show the sample data, you must localize this as well. You must choose between
the following localization options:
Use the localization utility to override the null values in the sample data. (See
“Using the localization utility to change the locale” on page 343.) This option is
not recommended. You should leave sample data with null values intact, so that
users who log into the Request Entry console without the en_US or fr locales are
not confused when they do not see any objects shown.
When you create your own navigational categories, AOTs, PDTs, and so on,
make sure you localize these objects at the same time.
Configuring the BMC Remedy AR System

server for localization
To localize the application, you must configure the BMC Remedy AR System
administration settings.
To configure the BMC Remedy AR System server for localization

1 From the IT Home Page, open the AR System Administration Console.
2 Choose System > General > Server Information.
3 In the Server Information window, click the Advanced tab.
4 In the Localized Error Messages section, choose Localize Server (if it is not selected
already).
5 Click OK.
Localizing navigational categories

Translated navigational categories follow the default language sort order specified
in Category Management. You cannot sort translated categories differently than
the base locale value.
When you configure a navigational category, you can also include other locales in
addition to those shipped with the application (French, Japanese, Simplified
Chinese, and so on). You can create additional sets of display properties for your
users, based on the locales you specify, for example, Dutch (nl). These display
properties are automatically related to each other.
This navigational category appears in the Request Entry console in the main
window and as a menu item in the Search menu. If you include additional locales,
this procedure describes some additional steps you must perform to finish
localizing the application.

You can change the image for each localized Category 1 record. Each localized
category can use a different image; the base category is the default image.
NOTE
This section assumes you understood navigational category configuration. See
“Configuring navigational categories” on page 65.
To localize navigational categories

1 To create the navigational category, choose Service Request Management >
Navigational Categories > Category Management, and then click Open.
2 Choose Global or a company.
3 Click Manage Locales.
The Category tree shows either global categories or categories for the specific
company that you selected on the Category Management form.
4 Click Add Locale to populate the list of languages available for localization.
5 In the Category Locale Select dialog box, select a locale (for example, fr_FR or
es_ES), and click OK.
You can add as many locales as needed. When you click Select, all categories
shown in the category locale are duplicated for that locale with parentheses
around the category name.
6 Select a record in the Categories tree (for example, Calbro Services Computers).
7 From the Select Locale menu, select a language (for example, fr_FR).
8 In the Localized Category Name and the Localized Description fields, enter the
localized text.
The original text appears in parentheses. Remove the parentheses when you add
your localized text. Some localized categories are provided for you by default
when the application is installed. Otherwise, you must select your own localized
category.
TIP
Enter “user-friendly” names for this navigational category, based on your locale.
9 Replace the image, as needed, for your locale.

You can relate different images for different locales for each category. You might
decide the French locale needs a different image associated with the navigational
category. For example, you can relate one image appropriate for the en_US locale,
and a different image appropriate for the fr_FR locale.
10 Click Apply.
The localized information appears in the category tree.
11 Log into the Request Entry console.
This localized navigational category is shown in the specified language when users
log into the server with the specified locale, for example, Dutch (nl). For more
information, see “Finishing localization” on page 341.

Localizing SRD levels
Localizing SRD levels

When you create SRD levels, you can also localize them.
To define SRD levels

1 From the Application Settings list, choose Service Request Management > SRD
Level > SRD Level, and click Open.
2 Enter a locale, level, and status.
3 Save the record.
4 Click Other Locales.
5 In the Defined Locales dialog box, select the new locale.
6 Enter the new localized level text, and click Add.
If you search for these new levels in the SRD Level dialog box, both items are
available, each in their respective locale, Dutch and Portuguese.
When the Service Catalog Manager creates the SRD, the locale level is available for
use.
Localizing questions to use with SRDs

In the Questions Library form, you can localize a set of questions that users are
prompted to answer when creating a service request from the SRD.
To define the Questions Library entries

1 Choose Service Request Management >Application Configuration > Define
Questions Library, and then click Open.
NOTE
You can also dynamically define questions when you are creating mappings in the
SRD.
2 Search for a question and open it.

3 Specify the locale to deliver questions in the language that is the most useful to
your users, for example, fr.
NOTE
Only questions with a locale that exactly matches the locale on the SRD appear in
the questions dialog box.
4 Perform the following steps:

a Enter the locale.
b Enter the question text for users.

c Select the application category to which the answer is pushed.

This is the value you specified for the Registry Name field on the Application
Registry form. You push the answer to the question back to the work order that
is part of the AOT.
d Select Active status if you want this question to be visible.
e Specify the answer format to this question entry.
If you select Single Answer Horizontal or Single Answer Menu, additional fields
appear where you can specify the menu list values, the sort order, and the locale
in which this will appear.
Specify the default value (if any) to this question entry.
5 Click Save.
Remapping questions to an SRD

You must map the localized questions to the SRD.
NOTE
For information about defining questions, see “Creating questions to use with
SRDs” on page 203 and “About adding questions and mapping variables and
service request fields” on page 128.
To remap questions in an SRD

1 From the Service Catalog Manager Console, select an SRD, and click View.
2 Click Questions & Mapping to open the Question Management dialog box.
3 Perform the following steps to map your questions to the SRD:
a On the Questions tab, select a question you have localized.
b Enter a default value (optional), and click Apply.
c Click the Variable Mapping, and map the variables accordingly.
d Map the target to the question.
e Click Apply.
4 Update all the questions and data targets.
5 Close the Question Management dialog box.
6 Save the SRD.

Localizing AOTs
Localizing AOTs
When you configure an AOT, you can also include other locales. You can create
additional sets of display properties for your users, based on other locales you
specify, for example, fr. These display properties are automatically related to each
other.
NOTE
The following procedure assumes you understand the AOT configuration. See
“Defining AOTs” on page 83.
To localize AOTs
1 To create the AOT, choose Service Request Management >Application
Configuration > Define Application Object Template, and click Open.
2 Search for a record and open it.
4 In the Defined Locales dialog box, specify a new locale, for example, fr.
5 Enter a “user-friendly” name of this AOT, based on your locale.
6 Provide a summary, based on your locale.
7 Click Add to save the display properties for this locale.
8 Add more locales as needed.
9 Close the dialog box, and click Save.
The Service Catalog Manager can use this localized AOT when creating a PDT.
Localizing PDTs
When you create a PDT, you can also include other locales. You create additional
sets of display properties for your users, based on other locales you specify, for
example, fr. These display properties are automatically related to each other.
IMPORTANT
The parent AOTs and PDTs appear in the first locale created. As a result, if you first
create an AOT in English and then localize it for French, you only see the parent
English AOT shown in the PDT form.
To localize PDTs
1 Create the PDT.
See “Creating a standard PDT” on page 91 or “Creating a quick launch PDT” on
page 98.
2 Add the localized AOT or PDT to this PDT.


4 In the Defined Locales dialog box, specify a new locale, for example, fr.
5 Enter a “user-friendly” name of this PDT, based on your locale.
9 Close the dialog box, and click Save.
The localized PDTs appear in the Process View of the Service Catalog Manager
Console.
NOTE
The localized PDTs have the same template ID as the original.
The Service Catalog Manager can use these localized PDTs when creating an SRD.
Localizing SRDs
When you create an SRD, you can also include other locales. You can create
additional sets of display properties for your users, based on other locales that you
specify, for example, fr. These display properties are automatically related to each
other.
NOTE
You should create your localized navigational categories before you localize the
SRD. If you do not, you are prompted to create them before the SRD can be saved.
To localize SRDs
1 Create the SRD.
See “Creating a standard SRD with the Service Request Definition form” on
page 116 or “Creating a quick launch SRD” on page 123.
3 In the specify Defined Locales form, specify a new locale, for example, fr.
4 Enter a “user-friendly” name of this SRD, based on your locale.

Localizing surveys in an SRD
8 Close the Defined Locales dialog box.

Users can view this localized SRD in the Request Entry console when they log into
the server with the fr locale.
9 Save the SRD.
Localizing surveys in an SRD

Use the Search for Surveys form to select survey questions for your requesters.
Surveys give the Service Catalog Manager or Business Manager an indication of
customer satisfaction levels and how the service desk is performing.
NOTE
You can add a survey to an SRD only if surveys are enabled in the Request
Preferences form. See “Defining behavior rules for surveys” on page 177.
To select surveys
If your application administrator created a default survey, its name appears.
3 To exclude a survey from this SRD, select Disabled from the Status field.
4 To create a custom survey for this SRD, select Custom from the Configuration
field.
Otherwise, the default survey is included with the SRD.
5 Click Select.
6 In the Search Survey form, select the company to which this survey applies, or
8 In the Configure Survey dialog box, enter a name for your survey.
9 Click Save.
The dialog box closes and you are returned to the Search Survey form.
10 Click Manage Questions.
The Manage Questions dialog box appears.
11 To create or modify questions in your survey, perform these steps:
a Specify a locale, if your questions must be localized, for example, en_US.
b Specify the numerical sequence, for example, 1.
c Define the question.

Localizing advanced interface forms

You should create localized views for your advanced interface forms if you plan to
deploy them in a localized environment. The advanced interface forms are
installed with localized views for English, Japanese, French, Italian, German,
Spanish, and Simplified Chinese.
NOTE
For information about localizing BMC Remedy AR System forms, see the BMC
Remedy Action Request System Form and Application Objects Guide.
To localize advanced interface forms

1 For each advanced interface form you want to localize, create a localized view of
that form.
You can use a copy of a view as the base for creating a localized view. The new
view should have the Locale property set to match the locale you will be localizing
the view for.
2 After you associate a view with a specific locale, select that view and localize the
components that users see.
For example, you should translate the field labels.
3 After you translate the components, adjust the field and view size to better match
the new labels.
Configuring advanced interface forms

If you create and localize your own advanced interface forms and they do not
appear as expected, use the following procedure to configure them.
For more information, see “Creating and using advanced interface forms” on
page 345.
To configure advanced interface forms

Advanced > Configure Advanced Interface data, and click Open.
2 Search for a form record.
3 Modify the information as needed.
4 Specify the proper locale for your form.
5 Click Save.
If the SRD includes an advanced interface form that is localized, users will see the
correct localized version when they log into the Request Entry console.

Finishing localization
Finishing localization
After you finish localizing the navigational categories, AOTs, PDTs, and so on,
perform the following steps.
To finish localization
1 Deploy the SRD.
2 Make sure the proper locales for your users are defined in the People form.
a Click the Notifications tab.
b Select the Notification Language, for example, French (France).
c Save your changes.
3 If your users have problems seeing currencies in their proper locale, define their
user preference settings:
a Open the AR System User Preference form in new mode.
b Click the Locale tab.
c Define the User Locale and Currency settings.
NOTE
Currency works only if the currency ratios are properly configured on the BMC
Remedy AR System server. See the BMC Remedy Action Request System
d Click Save.
NOTE
For each user, make sure that the AR System User Preference locale and the
Notification Language are the same, to prevent confusion.
4 Log into the Request Entry console.

If you have properly localized all the BMC Service Request Management
components, the localized navigational category appears in the Request Entry
console.
5 Select a service.
The localized information appear properly.
6 Submit the service request.
7 Verify the request details.
8 Open the request in the fulfillment application.
Make sure the answers to the localized questions were correctly pushed to the
application.

About localization problems

When you are working on a BMC Remedy AR System server that has the Localize
Server option enabled, you sometimes see unexpected behavior with localized
BMC Service Request Management objects, for example, missing navigational
categories or SRDs do not appear as expected.
Problem Solution
Why do we create PDTs by locale? Shouldn’t only When creating PDTs, the process definition is the same
the SRD be by locale but the PDT be the same for across all the locales. Only the fields that appear to users
all users? in the Visual Process Editor are localized.
Navigational categories are not shown as The SRDs and navigational categories appear to users
expected. For example, I created an SRD in three based on the locale fallback mechanism for locale defined
locale entries (English, Spanish and French). I also by BMC Remedy AR System.
created three separate navigational category If you are testing this behavior with BMC Remedy User,
entries for them. make sure that the client’s locale and the BMC Remedy
When I open the Request Entry console, my client User locale are set to the same value.
locale is English. But the navigational categories
appear in Spanish.
Then when I choose the SRD, the English one
appears.
All the global SRDs were shown as expected until The SRDs appear based on the locale fallback mechanism
you created an SRD with three different locales. of BMC Remedy AR System.
You see only the one SRD that was localized and If BMC Remedy AR System finds at least one SRD for the
all of the others, including the navigational client locale, it does not display the SRDs defined in other
categories, are not visible. locales.
The global SRDs were defined with a null locale value and
the new SRD was created with a locale value that matches
your client locale. As a result, only new SRDs appear.
After you have chosen any type of locale option, any BMC
Service Request Management object that does not have a
locale defined no longer appears. To show the global
SRDs, they must be also be localized.
I localized my SRD and the SRD appears, but it The SRD and all related objects must be localized. This
does not work properly, and there are no questions includes the PDTs, the navigational categories, the
in the Provide Information window in the Request questions, and the AOTs. If these are not localized, they
Entry console. will not be present on the SRD for that locale.
For more information about localizing BMC Remedy AR System applications, see
the BMC Remedy Action Request System Form and Application Objects Guide.

Using the localization utility to change the locale
Using the localization utility to change the

locale
To change the locale on records, the application includes a utility
(SRD:SetLocaleDlg) that searches for records with one specified locale and
replaces them with records with a different locale, if no records exist. For example,
you could use the utility to search for records that have a null locale value and
replace them with en_US. Or, you could also search for records with en_US and
replace them with a null locale. The SRDs then appear in the Request Entry console
as expected.
To use the localization utility to change the BMC Service Request

Management locale on records
1 In BMC Remedy User, open the SRD:SetLocaleDlg utility.
2 In the Current Locale Value field, enter the locale to search for.
3 In the New Locale Value, enter the locale to replace the current locale with.
This example searches for all records with a null locale value and replaces them
with records with the en_US locale.
4 Click Set Locale.
The Locale field on all the forms listed in the SRD:SetLocaleDlg form are set with
the value you specified.
NOTE
If the locale exists for that record, the utility does not create or modify a record.


Appendix
B Creating and using advanced

interface forms
This section describes how to create and use advanced interface forms.
Advanced interface forms—Overview (page 346)
Creating advanced interface forms from templates (page 347)
Registering advanced interface forms (page 351)
Relating Mapped and Details tab fields in the Work Order Template form
(page 353)
Creating SRDs with advanced interface forms (page 354)
Mapping fulfillment application fields to the service request fields (page 354)
Requesting a service with an advanced interface form (page 355)

Advanced interface forms—Overview

You can configure an SRD to use an advanced interface form as the user interface
to collect user’s request information in the Request Entry console. The advanced
interface form mechanism enables complex validation of answers and custom flow
of the interface for user interaction. If the SRD uses an advanced interface form, the
advanced interface form is used in the Provide Information stage instead of the
usual questions. Depending on the type of advanced interface form used, you
might need to map fields on the advanced interface form to the SRDs required
target data (fulfillment application fields).
Advanced interface forms allow you to have a personalized Provide Information
screen in the Request Entry console. You can use the advanced interface form’s
functionality to submit requests in place of the default method to submit requests
on the Request Entry console. Advanced interface forms provide the following
functionality:
Ability to map more than forty user responses to fulfillment application fields
(target data).
Ability to capture additional fields besides the default set of fields that are
captured by using the product as shipped.
Ability to control data flow in the advanced interface form.
Ability to create sophisticated data validation.
You use the following steps to create your own advanced interface forms:
Step 1 Create your own advanced interface form from the templates that BMC provides.
See “Creating advanced interface forms from templates” on page 347.
Step 2 Register the new form.
See “Registering advanced interface forms” on page 351.
Step 3 (optional) Configure the details fields in the Work Order Template form.
See “Relating Mapped and Details tab fields in the Work Order Template form” on
page 353.
Step 4 Configure the SRD to use the new form.
See “Creating SRDs with advanced interface forms” on page 354.
Step 5 (optional) Map your fulfillment application fields, if necessary.
See “Mapping fulfillment application fields to the service request fields” on

page 354.

Creating advanced interface forms from templates
Step 6 Open the advanced interface form from the Request Entry console.
This feature enables fulfillment process owners and service coordinators to view
the user responses on the advanced interface forms.
See “Requesting a service with an advanced interface form” on page 355.
Creating advanced interface forms from

templates
The application is shipped with three advanced interface forms that you can copy
and then modify, as needed. This enables you to use the advanced interface forms
provided as templates. As a result, you can create an SRD and attach one of these
advanced interface forms as shipped with your service request.
The following advanced interface forms are included:
Form name Description

With Backend Mapping This example of the advanced interface form uses a Regular form,
(SRS:AdvancedInterface_With which can be used to store data on the form itself, while also mapping
BackendMapping) some of the field values on the form to the fulfillment application fields.
The fields on the form are used to pose questions to users and capture
responses to those questions.
Without Backend Mapping This example of the advanced interface form uses a Regular form,
(SRS:AdvancedInterface_Without which can be used to store data requested of users directly on the form,
BackendMapping) without mapping this data to fulfillment application fields.
Password Reset This example of the advanced interface form uses a display-only type
(SRS:AdvancedInterface_Password of form, and illustrates a password reset use case. A display-only form
Reset) does not store any data. This type of form can be used only to map field
values to fulfillment application fields.
Before making changes, run tests on the copy to verify that it works the same as the
original.
IMPORTANT
You must have BMC Remedy AR System Administrator permissions and
knowledge of BMC Remedy AR System development to modify and enhance the

To use BMC Remedy Developer Studio to create advanced interface forms

from templates
1 Log into BMC Remedy Developer Studio.
2 From the AR System Navigator, open one of the sample advanced interface forms.
For example, open the SRS:AdvancedInterface_WithBackendMapping form.
TIP
In BMC Remedy Developer Studio, create a packing list of the advanced interface
form that you want to modify, and add all the related objects.
When opening the SRS:AdvancedInterface_WithBackendMapping form in BMC

Remedy Developer Studio, you should modify only the fields on the Your Fields
tab and only the field labels on the Mapped tab. Following is a description of the
tabs and the fields on those tabs:
The Your Fields tab contains the fields that are saved to the form. This tab and
all of its fields should be visible to users.
The Mapped tab contains fields that are pre-defined to map to fulfillment
application fields on the Details tab of a work order. The labels on these fields
can be changed to pose questions to users. This tab and any fields used to pose
questions to users should be visible. Any fields not used should be hidden from
users.
These fields are mainly character and integer type fields. If a user response
requires a selection field, data/time field, or a currency field, those fields can be
placed on the Your Fields tab, and additional workflow with an execution order
of 0 can be created to set the field values on the Mapped tab to the value of those
fields. This would be done with the hidden fields that are not used to pose
questions to the users. This enables those data types to be mapped automatically
by using the pre-defined mapping.
The Mapped 10-27 and Mapped 28-47 tabs contain additional fields that can be
mapped to fulfillment application fields by using the Question Selection and
Fulfillment Application Field Mapping dialog during SRD configuration. These
tabs should be hidden to users.
NOTE
The fields on the Mapped tab can also be mapped in this manner if the target
fulfillment application field is not on a work order, that is, an incident or change
request.
WARNING
Do not modify the other fields on this form—they are the core set of fields that map
to the service request, and are needed to create the service request. You can,
however, add specific workflow to the advanced interface fields for validation,
and so on.

Creating advanced interface forms from templates
3 Save a copy.
a Choose File > Save Form As.
If you copy the advanced interface forms with a new name (for example,
SRS:MyAdvancedInterface_Questions) and modify the copies, your work will
not be overwritten when you upgrade the application.
b Enter a new name for the copy.
Avoid using a plus sign (+) sign in the form name to ensure that a URL that
contains the form name is not interrupted.
4 Add your advanced interface form to the form attach list in the BMC workflow.
a Open the packing list you created in BMC Remedy Developer Studio.
b Open all the workflow objects from your packing list (for example, Active Links)
and associate your form, except for the four following active links:
SRS:ADN:WithMapping_OnSubmit_109_SubmitRequest_CheckReqFields
SRS:ADN:WithMapping_OnSubmit_109_AddToCart_SetFlag
SRS:ADN:WithoutMapping_OnSubmit_109_SubmitRequest_CheckReqFields
SRS:ADN:WithoutMapping_OnSubmit_109_AddToCart_SetFlag
IMPORTANT
To avoid migration issues, do not copy and rename the workflow that is attached
to the included advanced interface forms.
c Check the Filters, Active Link Guides, Menus, and Filter Guides, and associate
the new advanced interface form to them as well.
5 Perform the following actions to the preceding active links.
You must modify this workflow to set the flag in the RequiredQuestionsAnswered
field that determines whether the user entered all of the required information to
submit the service request or the cart.
a Copy and rename the active links.
NOTE
Do not use the BMC prefix (SRS:ADN) when you rename the active links.
b Modify the form name to your own interface form.

c Modify the Run If qualification to match the required fields on your form.
6 Edit the SRS:ADN:SHR_OnSubmit_SubmitInReview active link guide by adding
your submit request active links to it.
NOTE
Add your active links under the
SRS:ADN:WithMapping_OnSubmit_109_SubmitRequest_CheckReqFields and
SRS:ADN:WithoutMapping_OnSubmit_109_SubmitRequest_CheckReqFields
active links.

7 Edit the SRS:ADN:SHR_OnSubmit_SubmitInCart active link guide by adding

your cart active links to it.
NOTE
Add your active links under the
SRS:ADN:WithMapping_OnSubmit_109_AddToCart_SetFlag and
SRS:ADN:WithoutMapping_OnSubmit_109_AddToCart_SetFlag active links.
8 Test your copied version of the advanced interface form.

It should work just as the original form.
9 Modify your copy of the advanced interface form.
If you used the SRS:AdvancedInterface_WithBackendMapping or
SRS:AdvancedInterface_WithoutBackendMapping form as a template, you can
modify the fields in the Your Fields data fields sections.
WARNING
Do not delete or modify any other fields on these forms. BMC supports only
changes to appearance items, such as the header, background, labels, and so on.
You must now register the form.
Passing requestable offering data to advanced interface forms

The advanced interface forms that are shipped with BMC Service Request
Management 7.6.04 include requestable offering data. This data is passed when
advanced interface forms are displayed in the Request Entry console.
So that requestable offering data is stored on the default advanced interface forms,
the following fields are automatically copied from the Service Request Definition
form to the advanced interface forms in version 7.6.04 when you upgrade to BMC
Service Request Management 7.6.04:
Field name Database ID Description
RO Instance ID 304242570 Requestable Offering Instance ID
SRD_RO_ReconID 304242580 Requestable Offering Reconciliation ID
SRD_RO_DatasetID 304242590 Requestable Offering Dataset ID
NOTE
If you customized advanced interface forms in releases versions earlier than 7.6.04,
you must add these fields to the forms.

Registering advanced interface forms
Registering advanced interface forms

Use the Configure Advanced Interface Information form to modify the name of the
company, advanced interface form, server, and so on to be used when choosing
this advanced interface data record.
NOTE
You must have SRM Administrator permissions to access this form.
You can also disable these advanced interface forms. If you configure an advanced
interface form to be inactive, application administrators cannot select it as an
advanced interface template option when creating SRDs.
The advanced interface form feature also gives the application administrators the
option of creating an advanced data entry screen instead of the default window
used in the Request Entry console for completing details. You can also register new
NOTE
The advanced interface forms are installed with localized views for English,
Japanese, French, Italian, German, Spanish, and Simplified Chinese.
To register advanced interface forms

1 Open the Application Administration Console.
2 Click the Custom Configuration tab.
3 Choose Service Request Management > Advanced > Configure Advanced
Interface form data, and click Open.
The Configure Advanced Interface Information form appears.
The application includes entries for the three advanced interface forms shipped
with the application. You must create entries for any copies of the advanced
interface forms you create.

Figure B-1: Registering an advanced interface form
4 Specify a company.
5 Enter a template name (for example, Advanced Interface Questions).
This name will appear in the Advanced Interface field as a menu choice on the
Service Request Definition form.
6 Enter the form name and location as it appears on the BMC Remedy AR System
server.
For example, if you are using the advanced interface form you just created, enter
SRS:MyAdvancedInterface_Questions.
7 Specify the server and specify its status, either Active (enabled) or Inactive
(disabled).
8 Click Save.
Service Catalog Managers can now choose this advanced interface template from
the Custom Template field when they are creating SRDs.

Relating Mapped and Details tab fields in the Work Order Template form
Relating Mapped and Details tab fields in the

Work Order Template form
The Mapped tab on the advanced interface form contains fields whose values are
automatically mapped to the work order fields on the Details and Details 2 tabs of
the work order template. As a result, users do not have to define their own target
data mappings.
To transfer the questions posed to users with those fields to the work order, you
can modify both the field labels of the advanced interface forms and the Field Label
values on the Details and Details 2 tab of the Work Order Template form. You
should clearly match the labels on advanced interface form and the Details and
Details2 tabs of the Work Order Template, so that work order users understand the
particular meaning of the various detail fields.
NOTE
Unless more than 15 total fields, or all the available fields for any field type (22
character fields, 2 date/time fields, or 6 integer fields) are configured, the Details 2
tab will not appear to users in the Request Entry console.
Figure B-2: Mapped tab on advanced interface form
Modify these
field labels as
needed
For information about creating work order templates, see “Configuring work
order templates” on page 77.

Creating SRDs with advanced interface forms

After you create the advanced interface form, attach it to the SRD.
To use the advanced interface form when creating an SRD

1 Log into your server as a Service Catalog Manager.
2 Open the Service Catalog Manager Console.
3 Create an SRD.
4 On the Service Request Definition form, select the Advanced Interface Questions
item from the Advanced Interface Form field.
This field provides a menu of the entries found in the Configure Advanced
Interface Info form.
If an advanced interface template is specified and the SRD is used for creating a
request, the advanced interface form opens from the Request Entry console. This
is used instead of the Provide Information page.
5 Attach your PDT (containing the work order application template and AOT) to the
SRD.
6 Enter the remaining information into the SRD, and then save your changes.
7 Deploy the SRD.
See “Managing SRDs” on page 158.
Mapping fulfillment application fields to the

service request fields
If your AOT had target data added to it, you can also map fulfillment application
fields to the Service Request Fields used on the advanced interface form.
To map fulfillment application fields

2 Set the SRD to Offline.
3 Click the Mapping button.
The Question Selection and Fulfillment Application Field Mapping dialog box
appears. You can choose questions from the menu list of target data items to ask
your users.
NOTE
The Mapping button is enabled if there is application target data to map with the
PDT selected.

Requesting a service with an advanced interface form
4 Select a fulfillment application field from the list.

5 Under Fulfillment Mapping Details, select Map Target To > Service Request Fields.
The Service Request fields from the advanced interface form are the “SR Type Field
1” through “SR Type Field 47” fields. The “SR Type Field 1” through “SR Type
Field 9” fields are the fields that appear on the Mapped tab of the
SRS:AdvancedInterface_WithBackendMapping form. The “SR Type Field 10”
through “SR Type Field 47” fields appear on the Mapped 10-27 and Mapped 28-47
tabs on the SRS:AdvancedInterface_WithBackendMapping form.
6 Select the appropriate field from the Selected Field list.
7 Click Add.
8 Close the Question Selection and Fulfillment Application Field Mapping dialog
box, and save the SRD.
Requesting a service with an advanced

interface form
The following section describes how to use the advanced interface form with your
SRD.
NOTE
If you use the templates that are installed with BMC Service Request Management,
guest users cannot submit a request if the SRD includes an Advanced Interface
form.
To use advanced interface forms in your SRD

1 Open the Request Entry console, and then search for the service that represents the
SRD.
2 Select the service.
Your interactive interface form appears.
This backend mapping form includes generic service request fields, such as
Requester, Summary, Notes, and so on, that are pushed to the Service Request
(SRM:Request) form. In addition, this form includes the following tabs:
Your Fields—Shows users the questions that are specific to the service request.
Mapped—Contains fields that map to the service request and are automatically
mapped to the Type Fields on a work order. Your label changes should appear
to the users.
The Mapped 10-27 and Mapped 28-47 tabs contain fields that map to the service
request. These tabs should be hidden to users.

3 Enter the required data on the advanced interface form and then click the Submit
Request button.
This action creates a service request that uses the advanced interface form. The
advanced interface field values are stored on the advanced interface form and the
mapped fields are stored on the Service Requests form, making them available for
mapping to the fulfillment application fields.
After the service request is created, the submitted advanced interface form details
can be viewed using the More Details button on the Request Details dialog box.
The Request Details dialog box shows the details of a service request and can be
viewed by fulfillment process owners and service coordinators. For example, from
a work order, the Request Details dialog can be opened using the View Service
Request link.
4 Click the More Details button on the service request.
The advanced interface form details appear.

Appendix
C Using the mid tier prefetch

utility
This section describes how to use the prefetch utility when configuring BMC
Preloading specified forms (page 358)
Tips for using prefetch with Apache Tomcat (page 358)
Prefetch components (page 359)

Preloading specified forms

To prevent degradation of performance while applications and forms are loaded
to a cache, use the prefetch configuration utility with the mid tier when
configuring the application. Loading applications and forms in memory can cause
a significant delay for the first user in a “permission type.”
You can use a PERL-based utility (prefetch.pl) to make calls to the mid tier URLs
from the command line and therefore offload the performance hit of caching. With
this prefetch.pl utility, the cache can be preloaded during the mid tier startup.
NOTE
For more information, see the BMC Remedy Action Request System BMC Remedy Mid
Tier Guide.
Tips for using prefetch with Apache Tomcat

The more forms you add to prefetch, the more time you must allow for a graceful
shutdown of Tomcat. If Tomcat crashes or the server is shut down before Tomcat
saves any open prefetch files, the prefetch restarts upon reboot, leading to slow
response and a possible system crash if others try to use it while it is fetching again.
Remember these tips when using prefetch with Apache Tomcat:
Increase the Tomcat shutdown time and thread stack sizes to enable the efficient
serialization of your forms. This action gives Tomcat extra time to save prefetch
files.
Raise the maximum memory size of Tomcat (for example, 1024 MB).
Flush the Tomcat cache. Restart Tomcat, and let it run. This action could take
several hours to finish.
Monitor the amount of memory actually needed and lower the number
accordingly.
Include only the front-end user facing forms in the prefetch.
Include the user name that is the most common group combination in the
prefetch file. Using the Admin user might not be appropriate as the users
belonging to other groups triggers the HTML generation on the mid tier.
Watch the Tomcat process to make sure you are not keeping the JVM busy with
the memory swap. If possible, allocate the min and max as 2 GB so that the
Tomcat process starts up with the full memory available.
Because the memory requirements depend on how many forms are being
loaded, you must calculate the amount of memory needed based on the
application stack and the usage of your deployment.
NOTE
For more information about Tomcat configuration settings and the persistent
cache option, see the BMC Remedy Action Request System BMC Remedy Mid Tier
Guide.

Prefetch components
Prefetch components
The prefetch.pl utility uses the following components:
Component Description
StartServlet Contains the main code.
prefetchConfig.xml Main configuration file found in midTierInstall/WEB-
INF/classes.
prefetchConfig.xsd XML schema definition (XSD) for the .xml file, found in
the midTierInstall folder.
The format of the prefetch.pl utility configuration file is as follows:
Section Example code

Header <?xml version="1.0" encoding="UTF-8"?> <midtier-prefetch-
config xmlns="http://www.bmc.com/remedy/midtier/700">
Authentication—One or <prefetch-user>
more users that determines <user-name>SupportUser</user-name>
the permission-type cache. <locale>en_US</locale>
No password is required.
Server, applications and <prefetch-server>
forms—applications can <server-name>arserver</server-name>
contain 0+ forms. Forms can <prefetch-app>
exist individually at a server <app-name>Sample</app-name>
level. <prefetch-form>
<form-name>Home Page</form-name>
</prefetch-form>
…
</prefetch-app>
<prefetch-form>
<form-name>Home Page</form-name>
</prefetch-form>
</prefetch-server>
</prefetch-user>
Footer </midtier-prefetch-config>

Note the following usage issues:

Forms are cached differently, depending upon whether they are accessed using
a call to the application (/arsys/apps/ARServer/appName/formName) or the
forms directly (/arsys/forms/ARServer/formName). For environments where
either call is possible, both methods should be covered in the .xml file:
…
<prefetch-server>
<serverName>ServerName</server-name>
<prefetch-app>
<app-name>AppName</app-name>
<prefetch-form>
<form-name>FormName</form-name>
</prefetch-form>
</prefetch-app>
</prefetch-server>
<prefetch-server>
<server-name>ServerName</server-name>
<prefetch-form>
<form-name>FormName</form-name>
</prefetch-form>
</prefetch-server>
…
Specifying an application without at least one form causes the mid tier to cache
all of the forms in that application.
….
<prefetch-server>
<server-name>ServerName</server-name>
<prefetch-app>
<app-name>AppName</app-name>
</prefetch-app>
</prefetch-server>
…
You can see the prefetch activity in the mid tier logs in the following situations:
The performance category is selected.
The Log Level is set to Fine.
Apr 12, 2007 1:05:57 PM com.remedy.arsys.prefetch.PrefetchTask
run
INFO: START prefetch
Apr 12, 2007 1:06:14 PM com.remedy.arsys.goat.Form get
FINE: Form: Constructing for missing key Form:atlwin01/AR System
User Preference
Apr 12, 2007 1:06:17 PM com.remedy.arsys.goat.Form <init>
FINE: API form time = 2735
FINE: Form: Construction for key Form:atlwin01/AR System User
Preference took 2765
Apr 12, 2007 1:06:17 PM
com.remedy.arsys.goat.Form$CachedFieldMap <init>

Prefetch components
FINE: Form.CachedFieldMap: Constructing for missing key

atlwin01/AR System User Preference/Admin
Apr 12, 2007 1:06:17 PM
FINE: API field key time = 31
Apr 12, 2007 1:06:22 PM
FINE: API field time = 4797
…
…
FINE: Using the preference server atlwin01 form AR System User
Preference for user Demo
FINE: Form: Constructing for missing key Form:atlwin01/
Sample:Classes
Apr 12, 2007 1:06:24 PM com.remedy.arsys.goat.Form <init>
FINE: API form time = 2031
…
Apr 12, 2007 1:06:30 PM com.remedy.arsys.goat.field.FieldGraph

instantiateFields
FINE: FieldGraph: Populated fields/workflow for key
Admin|atlwin01/Sample:Classes/536880381/N, took 5438
Apr 12, 2007 1:06:30 PM com.remedy.arsys.goat.Globule init
FINE: Globule: Compressed data type text/html; charset=UTF-8 -
was 17445 bytes, now 3718 bytes
Apr 12, 2007 1:06:30 PM com.remedy.arsys.goat.ActiveLink
getBound
FINE: COMPILE formactivelink time = 0
Apr 12, 2007 1:06:30 PM com.remedy.arsys.goat.ActiveLink
getBound
FINE: COMPILE formactivelink time = 0
Apr 12, 2007 1:06:31 PM com.remedy.arsys.goat.menu.Menu
getMenuFromServer
FINE: API Get Menu time = 421
Apr 12, 2007 1:06:31 PM com.remedy.arsys.goat.Globule init
FINE: Globule: Compressed data type text/js; charset=UTF-8 - was
5967 bytes, now 1972 bytes
Apr 12, 2007 1:06:31 PM
com.remedy.arsys.prefetch.PrefetchWorkerImpl fetchForUser
FINE: successful prefetch -
server:atlwin01||form:Sample:Classes||username:Demo||appname:Sam
ple||view:null||locale:en_US||timezone:null took 8687
milliseconds.
FINE: Form: Constructing for missing key Form:atlwin01/AR Sample
Application: Console
…
…
Apr 12, 2007 1:06:31 PM com.remedy.arsys.prefetch.PrefetchTask
run
INFO: END prefetch


Glossary
This glossary contains terms for BMC Service Request application object template (AOT)
Management. Interface to a fulfillment application that is
needed to fulfill a service request.
For a list of AR System terms, see the glossary in the approval
BMC Remedy Action Request System Concepts Guide A process that generates electronic signature
lines for items that require approval, and
For a list of BMC Remedy IT Service Management tracks who has approved or rejected a given
terms, see the glossary in the BMC Remedy IT Service request.
Management Concepts Guide.
assignee
access permission The person assigned the responsibility of
See permission group. working on any of the following activities:
service request, change request, incident
Administration console
ticket, problem investigation, known error,
See Application Administration Console.
solution database entry, and so on.
administrator
assignment
See application administrator.
Automatically or manually assigning a group
AOI or individual the responsibility of resolving
See application object instance (AOI). an issue or request. The application uses the
AOT Assignment form for group automatic
See application object template (AOT). assignment and the Assignment Engine for
Application Administration Console
individual automatic assignment.
The main interface for configuring the BMC Atrium Configuration Management Database
application. The console works like a control (CMDB)
panel from which administrators can perform An infrastructure built on AR System and
common configuration activities and activities used to build data models and define datasets.
specific to different applications and broadcast message
subsystems. An application feature that enables users to
application administrator create messages that can be viewed by the
An individual responsible for the entire organization or by users in specific
management of the application, including groups.
setting up forms, setting access rights for BSM
users, and creating configurations. See business service management (BSM).
application object instance (AOI)
Instantiation of an AOT during its execution
phase.
Glossary 363
business service management (BSM) Configuration Management Database

A flexible, comprehensive management See BMC Atrium Configuration Management
approach that links IT resources and business Database (CMDB).
objectives. BSM makes sure that everything IT customer
does is prioritized according to business General recipient of an IT service, usually
impact, and enables IT organizations to management, that has responsibility for the
proactively address business requirements. cost of the service, directly through charging
change management or indirectly through demonstrated need.
As a concept, the process of planning, dataset
scheduling, implementing, and tracking A logical group of data. A dataset can
changes to the IT infrastructure, or any other represent data from a particular source, a
aspect of service, in a controlled manner. By snapshot from a particular date, and so on.
using change management, you can The dataset used by BMC products for
implement approved changes with minimal reconciled production data is named BMC
disruption to the business environment. Asset.
change request entitlement
The controlled process for the addition, Process that enables administrators to define
modification, or removal of approved, which users and groups of users can access
supported, or baselined hardware, networks, SRDs.
software, applications, environments, or
systems. A change request can involve escalation
multiple change activities. A workflow component that searches at
specified times or at regular intervals for
CI requests matching a specified condition, and
See configuration item (CI). performs specified operations on all matching
CMDB requests. Escalations are generally used to
See BMC Atrium Configuration Management find records that have exceeded specified
Database (CMDB). business rules or processes, and take
Company field appropriate action. They run on the
A field that controls multi-tenancy. It shows AR System server.
only data for the companies for which you flashboard
have permission. See also multi-tenancy. A real-time visual monitoring tool that shows
compliance service target you the state of your service operations, warns
A target (such as 99 percent) that tracks the you about potential problems, and collects
performance of the agreement to see the and shows trend data.
percentage of time the agreement was met form
over specific time periods. A collection of fields that represents a record
configuration item (CI) of information in the AR System. AR System
An infrastructure component or an item administrators can define and change the
associated with the infrastructure that is (or fields and workflow associated with a form.
will be) under the control of configuration An AR System application can include many
management, for example, a Request for forms.
Change. A CI can be complex or simple, large functional role
or small. CIs can include entire systems or be A defined role used for notifications and to
a single module or minor component. CIs can extend access granted by permission groups.
also include records of people (users and
customers) and locations.

Glossary
global milestone
A setting that applies changes or defines A point in time that triggers a set of actions as
certain parameters for all companies in a you progress toward an agreement
multi-tenancy environment. See also multi- compliance target or service target goal. The
tenancy. triggered actions make sure your goals are
goal being met.
Measurement method that enables you to multi-tenancy
track the time taken to resolve an issue or A feature that uses the Company field to limit
track how often an asset or service was access by individuals. The Company field can
available. Goals are used to determine be used to represent a company, department,
whether service targets are met. or other group. The Company field also can be
guest user used to control access in a hosted
Users who have not been configured with environment. By default, the application
login information in the People form. Guest operates in multi-tenancy mode. See also
users can create requests from generic services single-tenancy.
they are entitled to use, for example, global navigation pane
SRDs. An area on the left side of consoles that
incident
provides links to functionality and links to
Any event that is not part of the standard other programs.
operation of a service and that causes an notification
interruption to or reduction in the quality of A message sent to a user by workflow.
that service. See also incident management. Notification can be in the form of an alert,
incident management
email message, or other method using
As a concept, a reactive process typically integrations.
initiated in response to a customer’s call. The operational catalog
primary goal of the incident management A feature in which operational categories for
process is to restore normal service operation service requests are defined.
as quickly as possible and with minimum operational categorization
disruption to the business. A three-tier hierarchical representation of
Information Technology Infrastructure Library (ITIL) operations as defined in the Operational
A set of guidelines for the management and Catalog configuration form. This
provision of operational IT services. categorization is included in records to specify
instance
the range of operations to which a record
A record in the application. An instance is an applies.
object of a particular class. operator
instantiation
One of a number of functions that enable you
Process of creating an object from a template to define advanced searches or build
during its execution phase. qualifications.
ITIL Overview Console

See Information Technology Infrastructure A central console for the BMC Remedy IT
Library (ITIL). Service Management applications. The
console works like a control panel from which
measurement users can access all assigned work and
The metric by which supervisors measure the perform their primary activities.
ability of the support staff to meet their
agreements. PDI
See process definition instance (PDI).
Glossary 365
PDT process definition instance (PDI)

See process definition template (PDT). Instantiation of a PDT during its execution
performance-level service target phase.
A service target that compares a service level process definition template (PDT)
to the goals defined in the service target to Intermediate object that relates AOTs to SRDs.
determine whether the goal is met. Enables A PDT consists of the underlying processes
you to monitor whether a critical application that are needed to fulfill an SRD.
that you are using has responded within the registered user
time period specified in the goals. See also A user who has an entry in the People form
goal. with an AR System login ID.
performance-monitoring service target reminder
A service target that compares a goal to a A message similar to an AR System
defined threshold to determine if the goal is notification, except that you can define the
met. For example, it enables you to monitor content of a reminder and specify when to
whether a critical application that you are send it.
using responds within 4 seconds or if the
application meets other criteria such as being requestable service
in a state of “OK.” A non-technical term used in the Service
Request Designer for a service request
permission group definition (SRD). A requestable service is a
A feature of the application that controls what type of service offering, communicated to
areas of the application a user can access. Each users as a service request through the Request
permission group can access only certain Entry console. See also service request definition
areas of the application. A user can belong to (SRD).
more than one permission group.
request-based service target
problem A service target that measures how long a
The root cause of an incident or potential process takes, such as the time to respond to or
incident. After a resolution or work-around is resolve a service desk request, or the time to
identified, the problem becomes a solution respond to or resolve a change request.
database entry or known error. See also
incident, solution database, and workaround. Request Entry console
The front end in BMC Service Request
problem management Management for the BMC Remedy Change
As a concept, a process that identifies the Management, BMC Remedy Incident
cause of problems and initiates actions that Management, Work Orders, or other
help to improve or correct the situation, applications. It provides an easy, user-
preventing an incident from recurring or friendly interface that enables users to quickly
occurring in the first place. The cause submit requests for change or incidents to the
identified by a problem investigation can be fulfillment applications that are registered as
documented in a known error or solution shipped to work with BMC Service Request
database record. See also incident, solution Management, and to view their submitted
database, and problem. requests.
product categorization requester
A five-tier hierarchical representation of A person in the organization who needs
products as defined in the Product Catalog assistance from the IT support staff. A
configuration form. This categorization is requester is usually an employee in the
included in records to specify the range of organization who needs to have a change
products to which the record applies. implemented or an incident resolved.

Glossary
role service target

A set of responsibilities, activities, and The individual level of service to achieve. A
authorizations, usually in the context of a service target includes terms and conditions,
single application or a business system. goals, costs, and milestones. Examples of
Note: Access to the application is based on service target goals include incident
user roles. Depending on your role in the resolution time of 30 minutes, application
organization—requester, support, response time of 4 seconds, and an application
management—you work with a different being in a state of “OK.” See also performance-
application (or view) on your desktop. monitoring service target, request-based service
target, and compliance service target.
service catalog
A list of IT services, default levels, and set field
options. An advanced action that enables you to pull
information from other forms to set in the
service level agreement (SLA) form for which you are creating the
An agreement between a service provider and agreement.
its customers or lines of business that formally
documents the needs of the customer and single-tenancy
makes sure the correct level of service is A feature that enables selection of a default
received from the service provider. company for company fields. Single-tenancy
mode is required to give unknown users
service level management (SLM) access to the Request Entry console. See also
As a concept, the continuous and proactive multi-tenancy.
process of defining, agreeing, monitoring,
reporting, and reviewing the performance of SLM
IT services to make sure that adequate levels See service level management (SLM).
of service are delivered in alignment with solution database
business needs and at acceptable cost. A repository that stores reusable solutions to
service request customer product problems in an easy-to-
A request for service to the IT organization. retrieve format.
Service requests can be requests for change or solution entry
requests to resolve incidents that impact A reusable solution to a customer product
users. Also, the instantiation of an SRD during problem. This is stored in the solution
its execution phase. database.
Service Request console SRD
See Request Entry console. See service request definition (SRD).
service request definition (SRD) submitter
Service offering available to users through the A person who reports a problem, makes a
service catalog. request, or enters information into a database.
service request management (BMC Service Request submitter group
Management) One of several special access control groups
As a concept, the process of managing IT that AR System provides. Users automatically
services to meet the customer’s requirements. belong to this implicit group for requests they
As a function, the application makes sure that have submitted. See also assignee.
IT services are aligned to the needs of
customers and users. As a process, the
application aims to make sure the timely
acceptance, documentation, handling, and
close-out of service requests.
Glossary 367
task wildcard
A unit of work that needs to be completed as A character that users can type to represent
a step in implementing an incident or problem other characters in a search. For example, in
investigation. In BMC Remedy Change search statements in character fields, users can
Management, BMC Remedy Incident specify wildcards to match single characters,
Management, or Work Orders, you can also strings, or characters within a range or set.
group a number of activities for requests with work info
a number of actions that must be completed A record describing work performed.
before the request can be resolved. Your
administrator creates task templates and task work order
group templates that you can reuse for the System that provides basic functionality for
same types of requests. Tasks can be manual assignment, status, work information, and task
or automatic. management in the application.
task management system (TMS) workaround
A sub-system that is used to create task A temporary resolution to an incident,
templates and task group templates. Besides problem, or known error.
the ability to set up predecessor-successor workflow
relationships, TMS supports branching and The automated set of business processes used
multiple task paths as well as the data to run a company.
exchange between activities.
template
1. A set of predefined criteria or settings that
can be used by many agreements or service
targets. See also service level agreement (SLA).
2. A form set up by an administrator that a
user can select to complete an incident ticket,
a change request, or a work order with
information consistent with the user’s support
group and the type of incident, change
request, or work order.
time-based service target
A service target that measures the time taken,
for example, to resolve an incident from the
time the incident was reported to the time it
was resolved. Any time that falls within the
“Exclude when” qualification is ignored and
not measured.
TMS
See task management system (TMS).
user
Specific person who receives the IT and other
business services on a day-to-day basis.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A application settings, configuring 62

application templates
access about 21, 22
by functional role 46 mapping to AOTs 83
by guest users 60 overview 74
granting to the application 41 parameters for creating 75
to forms 37 Approval Console, approving SRDs using 151
activity log information, passing 184 Approval Process Configuration form 235
ad hoc approvals, about 233 approval processes
ad hoc tasks, relating to work orders 287 adding 234
administrator, defining application 39 mapping level type to groups 227
advanced interface forms setting up company 235
about 346 approvals
adding SRDs to 165 ad hoc process type 233
configuring 340 adding alternate 149
creating and using 346 approval chains, custom 219
Details and Details2 tabs 79 approval states 230
localizing 340 approved state 231
registering 351 approvers, mapping 223
requesting a service with 355 begin state 231
service request fields, mapping to 354 company 233
SRDs, creating with 354 configuring 23
using BMC Remedy Developer Studio to creating people for 218
create 347 custom approval chain 219
work order type fields, configuring 353 defining for SRDs 146
alternate approvers, adding 149 for service requests, setting 138
AOTs for SRDs, setting 146
about 21, 82 global 233
creating 22 group approvers 218
defining 83 individual 218
defining output variables for 90 level process type 233
localization 337 mapping approvers to level types 223
order, specifying 88 mapping groups to level type approvals 227
PDTs and 88 mapping individuals to level types 225
Register Application Template form 84 mapping roles for 218
registering application templates 86 mappings, creating 218
relationship of SRD to PDTs and AOTs 88 no approvals state 231
template form 83 process configuration for companies 234
AP:Rule Definition form 231 process types 219, 230, 233
Application Administration Console 37 rejected state 231
application administrator, defining 39 service requests 219
application object templates. See AOTs setting up approvers 21
Index 369
approvals (continued) BMC SLM

SRD approval process 231 permission group for 42
state transitions 231 status gauge 292
submitting for SRDs 149 tab on Work Order form 291, 293
approved approval state 231 BMC Software
Approver Mappings form 223 contacting 2
Assignment form 300 education 33
assignments branch conditions, adding to questions 132
accepting tasks 283 browser, opening application consoles in 36
auto-assignments, individual 303 Business Analyst permission group 42
availability, updating 296 business analyst role 42
configuring 24 Business Holidays Definition form 62
creating for work orders 274 business hours, modifying for support groups 61
events 303 Business Manager permission group 41
group 301 business manager role 41
individual 303 business service CIs, relating to SRDs 136
notification of groups 275
notification of individuals 275
routing 300 C
tasks 277 canceling tasks 290
work order templates, about 77 categories
work order templates, settings in 78 operational 55
work orders 274 product 54
attachments in SRDs 167 categories, navigational
audience for this guide 13 company 70
audit log defining 66
viewing SRD 164 localization 333
viewing work order 265 setting up 22
sorting 71
B change request PDTs, adding information to 102
Change User permission group 43
begin approval state 231 check box questions, defining 207
benefits, BMC Service Request Management 19 closing tasks 290
Best Practice view 250 companies
BMC Remedy AR System licenses 38 company approval processes 235
BMC Remedy User, opening application consoles company navigational categories 70
in 36 creating 48
BMC Service Request Management locations 49
about 18 organizations 48
accessing 41 regions 49
benefits 19 site groups 49
components 20 structure 48
configuration prerequisites 38 Company and Console View, Service Catalog
customizing 33 Manager Console 159
documentation for 14 company approvals 233
permissions 41 configuration
request management 20 AOTs 82
service catalog 20 Application Administration Console 37
setup tasks 20 application templates 74
system SRDs shipped with 115 behavior rules for surveys 177
change templates 81
companies 48

configuration (continued) customer support 3

data, managing 56 customizing the application 33
defining the application administrator 39
incident templates 82
localizing advanced interface forms 340 D
locations 49 data
mid tier and multi-tenancy settings, 62 exporting supporting data from test systems 314
mid tier to view DVF fields, defining 63 importing from another company 309
miscellaneous 173 importing to a production system 316
modifying standard 56 data flow, mapping the direction of 95
navigational categories 66 data visualization fields, See
non-support staff members, creating 52 date and time questions, defining 215
operational categories 55 Define Business Hours form 61
organizations 48 Defined Searches, using 259
people information 50 definitions, exporting from test systems 313
performing 46 deploying
prerequisites 38 SRDs, steps for 168
product categories 54 Details tab and Details2 tab, configuring 79
Questions Library entries 204 DVF fields configuration 63
questions to use with SRDs 204 dynamic data flow
Request Entry console preferences 182 about 105
request entry preferences 178 building PDTs that use, about 106
service request HTML definitions 181 dynamic query menus, defining 213
service request image definitions 174
service request query exclusions 183
SRD images 175 E
SRD levels 174
education, BMC Software website 33
standard, performing 37
email, sending from Work Order form 267
support groups 49
entitlement
support staff members 50
adding people entitlement definitions 244
survey questions 176
adding SRD qualifications 245
unknown users access to the application,
configuration process 240
allowing 60
configuring 24
work order rules 295
creating people qualifications and 143
work order templates, about 76
enabling 242
work order templates, modifying or deleting 80
groups 243
Configure Assignment form 301
modifying rules for 142
Configure Service Target Defaults form 156
permission group for 42
consoles
rules 244
opening in a browser 36
SRDs and 141
opening in BMC Remedy user 36
validating users 246
Service Catalog Manager, using to manage
Entitlement Group Management form 243
PDTs 99
Entitlement Management console 242
user access to 44
Entitlement Management form 244
Work Order Console, opening 249
Entitlement Management Qualifications form 246
Context URL Builder 320
Entitlement Rule form 244
context URLs, examples 328
events, assignment
custom searches
Service Request Assignee 303
about 260
Task Assignee 303
using for work orders 259
Work Order Assignee 303
customer information, defining in an SRD 165
Work Order Manager 303
customer profile, adding and modifying 261
Index 371
exporting
PDTs 306
I
SRDs 306 image, changing for SRD 160
SRDs from a test system 315 importing
supporting data 307 data from another company 309
viewing history of exports 312 data to a production system 316
definitions to a production system 316
PDTs 308
F PDTs from another company 309
financial information in tasks, adding to 280 SRDs 308
flow, viewing task 282 SRDs from another company 309
fulfilling work orders 276 SRDs to a production system 316
fulfillment provider role 43 viewing history of 312
functional roles 46 incident requests
adding information to PDT 104
viewing related service targets 291
G Incident User permission group 43
individual approvers, creating 218
getting started 24
individual notifications of work order
global approvals 233
assignments 275
global navigational categories 68
inherent group mappings 229
group approvers 218
internal variables 90
group notifications of work order assignments 275
internationalization 330
groups
approvers 218
assignment to 301
entitlement 243
L
functional roles and 46 level approvals
permission, Business Analyst 42 about 233
permission, Business Manager 41 group mapping 227
permission, Change User 43 licenses
permission, Incident User 43 BMC Remedy AR System 38
permission, Request Catalog Manager 42 on behalf of feature requirement 58
permission, Service Request User 43 life cycles
permission, SRM Administrator 42 service request 31
permission, Work Order Config 43 SRD 110
permission, Work Order Master 43 localization
guest users about 330
access to the Request Entry console 60 advanced interface forms 340
single-tenancy 62 AOTs 337
BMC Service Request Management objects 332
configuring BMC Remedy AR System server
H for 333
fallback mechanism for DVFs and Popular
history
Services 332
exports 312
languages supported 330
imports 312
locale fallback mechanism 331
holidays, modifying for support groups 61
navigational categories 333

localization (continued)
overview 331
N
PDTs 337 navigational categories
process, finishing steps 341 about setting up 22
questions to use with SRDs 335 defining 66
SRD levels 335 defining company 70
SRDs 338 defining global 68
surveys 339 sorting 71
troubleshooting problems 342 navigational categories, localizing 333
user help 331 no approvers approval state 231
utility, using 343 non-support staff members
Location form 49 creating 52
locations defined 50
creating 49 notifications
site groups 49 group work order assignment 275
structure 49 individual work order assignment 275
logs managing service request 163
SRD audit 164 viewing SRD trail 164
task effort 286 work orders, assignment 275
work order audit 265 notifications, functional roles and 46
M O
mapping offline SRDs 169
approvers 223 on behalf of definition rules 58
approvers to phases 223, 225 On Behalf Of Definition Rules form 58
roles for approvals 218 online, returning SRDs 170
service request fields 135 opening forms 37
menu questions, query Operational Catalog form 56
about 209 operational categories 55
defining 210 organizations
testing 212 creating 48
menu questions, static structure 48
about 209 Overview Console. updating profiles 297
defining 209
metrics for SRDs 166
mid tier P
configuring 62 packages 240
configuring to view DVF fields 63 packages and SRDs 140
migrating paging, from Work order form 267
exporting definitions from test to production passing activity log information 184
systems 313 Patch fields 309
exporting supporting data from test to PDTs
production systems 314 about 21, 22, 88
from test to production systems 313 adding change request information to 102
multi-tenancy adding incident request information to 104
about 62 checking for use in other PDTs or SRDs 97
configuring 62 creating, example of 102
multi-tenancy and guest users 62 creating, getting started 91
my searches, custom searches 260
Index 373
PDTs (continued) preferences

data flow 88 Service Catalog Manager Console 186
defining 88 Work Order Console 297
defining output variables for 90 prefetch utility
defining variables for 94 Apache Tomcat servlet container tips 358
exporting 306 components 359
flow, designing 92 using to preload forms 358
general details, defining 96 prerequisites, configuration 38
how they work 89 process definition templates See PDTs 22
importing 308 process input variables 90
importing from another company 309 process objects, defining properties of 95
localizing 337 process output variables 90
quick launch 98 process steps 21
quick start for creating 90 process templates
relationship of SRD to PDTs and AOTs 88 adding to SRDs 127
reviewing nested PDTs 100 viewing 126
reviewing related AOTs 100 Process View, Service Catalog Manager Console 88
standard 91 processes
testing an SRD that uses 171 about 21
using Company field to search for 100 analyzing 21
using dynamic data flow 106 types, about 230
using the Service Catalog Manager Console to using the Visual Process Editor to view 101
manage 99 Product Category form 54
work information, adding 97 product support 3
peer tasks 278 product, categorization structures 54
people entitlement definitions 244 profiles, Work Order Console 297
People form 297
People form, people information for approvals 218
people information, creating 50 Q
People Qualification Definition form 144 qualifications, people entitlements and 143
People Qualification for Entitlement form 244 query exclusions, configuring 183
permission groups query menu questions
ASE Administrator 42 about 209
Business Analyst 42 defining 210
Business Manager 41 defining dynamic 213
Change User 43 testing 212
Entitlement Administrator 42 Question Management form 128
Incident User 43 Question Selection and Data Target Mapping dialog
Request Catalog Manager 42 box 354
Service Request User 43 questions
SLM Config 42 adding branch conditions to 132
SRM Administrator 42 adding to an SRD 129
Task Administrator 42 check box 207
Work Order Config 43 configuring survey 176
Work Order Master 43 date and time 215
permissions defining dynamic 213
functional roles and 46 localizing, to use with SRDs 335
groups 41 mapping variables for, about 128
predefined multiple inputs. concatenating 135
task groups 288 query menu, about 209
task templates 288 query menu, defining 210
query menu, testing 212

questions (continued) roles (continued)

radio button 206 mapping for approvals 218
range 208 service catalog manager 42
remapping localized to an SRD 336 service request coordinator 43
restrictions in creating 131 SRM administrator 42
restrictions in format 134 user 41
static menu, about 209 work order assignee 43
static menu, defining 209 work order assignee functional role 249
text 205 work order manager 43, 248
Questions Library, about 204 routing, creating assignment 300
quick launch rules
PDTs, creating 98 entitlement 244
SRDs, creating 123 modifying entitlement rules for SRDs 142
quick start on behalf of definition rules 58
creating PDTs and SRDs 90 surveys 177
work order, configuring 295
R
radio button questions, defining 206
S
range questions, defining 208 Search for Surveys form 339
Read license, and Submitter Mode Locked option 53 sequence numbers, assigning in work orders 278
reassigning service catalog 20
tasks 279 Service Catalog Manager Console
work orders 275 approving SRDs using 151
regions, geographic 49 Company and Console View 159
Register Application Template form 84 manage PDTs, using to 99
rejected approval state 231 preferences. setting 186
reminders Process View 88
about 266 service catalog manager role 42
creating 266 service catalog managers
viewing, modifying, and deleting 267 approving SRDs 150
Request Catalog Manager permission group 42 managing SRDs 158
Request Entry console using Service Request Designer 190
context fields 324 Service Request Assignee event 303
default preferences 182 service request definition See SRDs 23
manually creating URLs to open 327 Service Request Definition Settings form 173
opening in context 319 service request definitions. See SRDs
query exclusions, configuring 183 Service Request Designer
service request image definitions, about 190
configuring 174 Approvers section 197
user help localized 331 Deployment section 200
using Open Window action to open 327 Description section 192
request management 20 Entitlements section 198
Request Preferences form 177 Fulfillment Process section 194
Requester Console summary records, converted to Options section 199
SRDs 115 starting 191
roles Service Request HTML form 181
analyzing 21 Service Request Images form 175
business analyst 42 Service Request Management Image Management
business manager 41 form 176
fulfillment provider 43 Service Request Query Exclusions form 183
functional 46 Service Request User permission group 43
Index 375
service requests definition settings, defining 173

about 30 deploying 168
approvals for 219 entitlements, modifying rules for 142
configuring rules for 178 entitlements, selecting 141
coordinator role 30, 43 exporting 306
defining rules for 177 exporting from test environment 315
image definitions 174 HTML definitions 181
life cycle 31 images, managing 175
mapping data to fields 135 importing 308
query exclusions 183 importing from another company 309
setting approvals for 138 importing to a production system 316
state transitions 32 life cycle 110
status reasons 32 localization utility, using 343
viewing associated work orders 265 localizing questions 335
Service Target Wizard 153 localizing, about 338
service targets managing 158
associating with SRDs 154 mapping variables to questions 133
configuring 155 modifying 158
defining for SRDs 152 notifications 163
managing 291 offline, taking 169
related incident requests 291 online, returning 170
shipped with the application 155 overview for creating 114
Work Order Management, viewing in 291 packages 140
work order, creating for 293 qualification management 245
services, relating business service CIs to SRDs 136 quick launch 123
setup tasks, overview 20 related to a PDT 100
Show/Hide Options form 162 relating business service CIs to 136
single-tenancy and guest users 62 relationship of SRD to PDTs and AOTs 88
site groups 49 remapping localized questions 336
SRD Qualification for Entitlement form 245 resetting dates in expired 170
SRDs searching for 99, 158
adding a standard process template to 125 standard 116
adding advanced interface forms to 165 surveys 156
adding an attachment 167 system SRDs shipped with the application 115
adding questions to 129 testing 171
adding quick launch process templates to 127 using dynamic data flow, about building 171
adding surveys 339 using search criteria to search for 159
adding work information to 144 using Service Request Designer to create 189
advanced interface forms, creating with 354 validating user entitlement to 246
approvals, defining 146 viewing metrics about 166
approvals, setting 146 viewing notification trail 164
approvals, viewing 150 viewing process templates attached to 126
approving 150 yellow stoplight 117
associating service targets with 154 SRM Administrator permission group 42
audit log 164 SRM administrator role 42
changing the image 160 SRM Application Settings form 62
configuring visible fields in 161 Standard Configuration tab
creating 23 about 46
creating using Incident PDT 172 accessing 47
customer information, defining 165 working with 37
defining levels 174 standard PDT, creating 91
defining service targets for 152 standard process templates, adding to SRDs 125

states and status tasks

service request reasons 32 accepting assignments for 283
service request state transitions 32 adding work information 285
viewing in Work Order Management 292 assigning 277
states, approval 230 canceling 290
static menu questions closing 290
about 209 creating for work orders 277
defining 209 financial information, adding to 280
status gauge 292 managing for work orders 280
stoplight, yellow SRD 117, 123 modifying 287
structures modifying for work orders 284
location 49 peer 278
organization 48 reassigning 279
product categorization 54 relating ad hoc to work orders 287
support group 49 sequence numbers in work orders 278
Submitter Mode Locked option 53 setting start and end date 279
Support Group form 50, 61 tracking time 286
support groups viewing flow 282
creating 49 viewing work order-related 281
modifying business hours 61 work orders, searching for 280
role description 50 technical support 3
structure 49 templates
support staff members, creating 50 adding (relating) predefined task to work
support website 33 orders 288
support, customer 3 adding process templates to SRDs 127
survey questions, configuring 176 adding standard process to SRDs 125
surveys AOTs 88
adding to SRDs 156, 339 application 74
localizing 339 application, about creating 22
application, parameters for creating 75
change 81
T incident 82
tag names in HTML definition records 181 process definition, about 88
targets process definition, data flow 88
service request fields, mapping to fulfillment process definition, defining 88
application fields 354 process definition, designing the flow 92
service, defining for SRDs 152 process definition, getting started creating 91
viewing SLM integrations with 291 process definition, how they work 89
Task Assignee event 303 registering application templates 86
task effort logs 286 selecting work order 264
Task Flow Viewer 282 work order, about 76
task groups work order, assignment settings 77
adding (relating) predefined to work orders 288 work order, assignment settings in 78
creating for work orders 277 work order, classification 76
sequence number in work orders 278 work order, configuring 77
viewing work order-related 281 text questions, defining 205
Task Management System, using with work time, tracking task 286
orders 249 troubleshooting localization problems 342
truncated data from service request in work orders,
viewing 276
Index 377
U Work Order form

about 251
unknown users access to the application, allowing 60 Class view 250
Update Support Group Memberships and Roles paging from 267
form 40 sending email from 267
URL, application consoles 36 sending messages from 267
users work order manager 248
access for unknown users to the Request Entry Work Order Manager event 303
console 60 Work Order Master permission 248, 249
granting access to the application 41 Work Order Master permission group 43
roles 41 Work Order Template form 77
setting up 21 work order templates
about 76
assignment settings, about 77
V assignment settings, configuring 78
variables classification 76
defining for PDTs 94 configuring 77
defining output for AOTs or PDTs 90 modifying or deleting 80
internal 90 selecting 264
mapping to questions 133 work orders
mapping to questions, about 128 See also work order templates
process input 90 ad hoc tasks and 287
process output 90 adding (relating) predefined task groups 288
Version fields 309 adding (relating) predefined task templates
Visual Process Editor to 288
designing PDT flow in 92 adding details 258
using to view processes 101 assignee role 249
assigning 274
assigning sequence numbers 278
W audit log 265
Classic view of work order form, deploying 250
websites
classifying 256
BMC Software education 33
configuration rules 295
Customer Support 33
creating 252
work info entry, adding attachments to 145
creating assignments for 274
work information
creating task groups and tasks for 277
adding to process definition templates 97
custom searches for 260
adding to SRDs 144
form views 250
adding to tasks 285
fulfilling 276
work orders, modifying in 254
integrating with BMC SLM 291
Work Order Assignee
life cycle 270
event 303
managing SLM targets 291
Work Order Config permission 248
managing tasks 280
Work Order Config permission group 43
modifying tasks 284
Work Order Configuration Rules form 295
notifications of assignments 275
Work Order Console
reassigning 275
opening 249
relating to other object 257
setting preferences 297

work orders (continued)

searching for 258
service targets, creating for 293
service targets, viewing 291
tasks, modifying 287
tasks, searching for assigned 280
terms and conditions 294
truncated data from service request, viewing 276
type fields, configuring 353
using custom searches for 259
viewing associated service requests 265
work information, modifying in 254
Work Order form, Class view 250
work order manager functional role 248
Y
yellow stoplight, SRDs and 117, 123
Index 379

*180017*
*180017*
*180017*
*180017*
*180017*

SRM Admin Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRM Admin Guide PDF

Uploaded by

Copyright:

Available Formats

BMC Service Request Management 7.6.

© Copyright 2006-2011 BMC Software, Inc.

Restricted rights legend

Support by telephone or email

Before contacting BMC Software

Chapter 1 Introducing BMC Service Request Management 17

Chapter 2 Getting started 35

Chapter 3 Configuring navigational categories 65

Chapter 4 Creating application templates and application object templates 73

Chapter 5 Creating process definition templates 87

Chapter 6 Creating service request definitions 109

Chapter 7 Using the Service Request Designer 189

Chapter 9 Configuring approvals 217

Chapter 10 Configuring packages and entitlements 239

Chapter 11 Using the Work Order Management application 247

Chapter 12 Configuring assignments 299

Chapter 13 Importing and Exporting PDTs and SRDs 305

Chapter 14 Opening the Request Entry console in context 319

Appendix A Internationalization and localization 329

Appendix B Creating and using advanced interface forms 345

Appendix C Using the mid tier prefetch utility 357

BMC Service Request Management

Title Document provides Audience

Title Document provides Audience

1 Introducing BMC Service

This section provides an overview of the BMC Service Request Management

Chapter 1 Introducing BMC Service Request Management 17

What is BMC Service Request Management?

Figure 1-1: BMC Service Request Management solution

BMC Service Request Management shares a common foundation with BMC

BMC Service Request Management is integrated with BMC Remedy Change

Benefits of BMC Service Request Management

Chapter 1 Introducing BMC Service Request Management 19

Main components of BMC Service Request Management

Overview of setup tasks

Figure 1-2: Getting BMC Service Request Management up and running

Set up the framework

Chapter 1 Introducing BMC Service Request Management 21

Create application templates (optional)

Chapter 1 Introducing BMC Service Request Management 23

What users see

Basic steps to get started

Action Where to begin For more information

Chapter 1 Introducing BMC Service Request Management 25

Action Where to begin For more information

Action Where to begin For more information

Chapter 1 Introducing BMC Service Request Management 27

Action Where to begin For more information

Action Where to begin For more information

Chapter 1 Introducing BMC Service Request Management 29

About service requests

When a user submits, modifies, or cancels a request in the Service Request

An important part of the role of the Service Request Coordinator is monitoring

Service request life cycle

Figure 1-3: Service request life cycle

Chapter 1 Introducing BMC Service Request Management 31

Service request status reasons

Service request status Status reasons

Customizing the application

Chapter 1 Introducing BMC Service Request Management 33

This section describes how to set up the application.

The following topics are provided:

Chapter 2 Getting started 35