Vous êtes sur la page 1sur 300

BMC Remedy Action Request System 7.6.

04

BMC Remedy Approval


Server 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


2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA

Telephone

713 918 8800 or


800 841 2031

Fax

(01) 713 918 8000

Fax

713 918 8000

Outside United States and Canada


Telephone

(01) 713 918 8800

If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.

Copyright 19912011 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.
AIX, DB2, IBM, and Informix are trademarks or registered trademarks International Business Machines Corporation in the United States,
other countries, or both.
Linux is the registered trademark of Linus Torvalds.
Oracle and Java 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 U.S. 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

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 1

Introduction to the approval server

17

Approvals in business processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Overview of the approval server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flexibility and common experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification with feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic approval server concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approval roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18
18
19
19
19
19
20

Chapter 2

23

Configuring the approval server

Using the approval server Administration form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Process administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring process administrator capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process administrator prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a process administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring server settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approval server debug log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Private queues for loopback calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring settings on the Basic tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring settings on the Notifications tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring settings on the Escalations tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring business times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring previews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the approval server to work with flowcharts . . . . . . . . . . . . . . . . . . . . . .

24
25
26
26
26
27
27
28
30
31
32
32
33
33

Chapter 3

35

Processing approval requests

Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opening Approval Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AR System Object List in browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Working with pending approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processing an approval request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing a search on Approval Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents

36
37
37
38
38
38
5

Approving and rejecting requests from Approval Central . . . . . . . . . . . . . . . . . . . 39


Rejection justification for approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Working with request details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Processing More Information requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Requesting more information about approval requests. . . . . . . . . . . . . . . . . . . . . . 46
Viewing and responding to More Information requests . . . . . . . . . . . . . . . . . . . . . 47
Viewing pending More Information requests and responses . . . . . . . . . . . . . . . . . 48
Viewing all More Information requests you submitted . . . . . . . . . . . . . . . . . . . . . . 49
Using alternate approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Designating alternate approvers for yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Viewing and modifying alternate approver definitions . . . . . . . . . . . . . . . . . . . . . 52
Viewing requests for which you are an alternate approver . . . . . . . . . . . . . . . . . . 52
Defining alternates for other approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Performing overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Performing an override to a single signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Performing a global override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Chapter 4

Using the Get Agreement sample application

57

Overview of the Get Agreement application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


Accessing Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Creating new approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Approving approval requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Reassigning approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Requesting more information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Approval Status and More Information requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Responding to More Information requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Viewing responses to More Information requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Checking status of requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 5

Introduction to approval forms, processes, and rules

69

Approval server data and forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


Approval data and audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Approval server supporting forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Difference between processes and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Approval process stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Approval process types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Summary of process types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Signatures for multiple approvers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Action date for a process or signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Approval server rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Self Check stageRules that test for automatic approval and self approval . . . . 82
Next Approver stageRules that get the next approver. . . . . . . . . . . . . . . . . . . . . 85
Approver Response stageRules that work with signatures. . . . . . . . . . . . . . . . . 87
Completion Check stageRules that test for completion . . . . . . . . . . . . . . . . . . . . 91
Process Done stage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Chained processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Approver fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6

BMC Remedy Approval Server Guide

Lengths of approver fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94


The apchgschema utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 6

Defining an approval process

97

Using the Process tab on AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98


Creating a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Defining process basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Setting process intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Creating signature escalations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Creating More Information escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Working with existing processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Viewing and modifying a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Deleting processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Renaming an approval process or form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Defining roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Chapter 7

Defining approval rules

109

Using the Rule tab on AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Creating a rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Basic tab on the Rule Definition form. . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Set Fields tab on the Rule Definition form. . . . . . . . . . . . . . . . . . . . . . .
Example of the Set Fields tab for a query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Auto Approval rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of an Auto Approval rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining all Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Get Authority rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Self Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Self Approval rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Prep Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Prep Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process type and Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Parameterized Get Next Approver rules. . . . . . . . . . . . . . . . . . . . . . . . .
Example of Parameterized Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . .
Defining Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Validate Approver rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Signature Accumulator rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Signature Accumulator rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Statistical Override rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of decision-making rules in a sample application . . . . . . . . . . . . . . . . .
Example of a Statistical Override rule with default data. . . . . . . . . . . . . . . . . . . .
Defining Completion rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Completion rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Approval Process Done rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of an Approval Process Done rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents

110
110
111
113
113
114
114
115
116
117
118
119
120
120
121
122
123
125
126
128
129
130
131
132
132
133
137
138
138
139
140
7

Working with existing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141


Viewing and modifying rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Deleting rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Chapter 8

Using the Lunch Scheduler sample application

143

Overview of the Lunch Scheduler application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144


Important Lunch Scheduler forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Sample process descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Management cost authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Major account level approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Special overdue approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Chaining approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Using filters and a process status field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Restarting an approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Licensing sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Sample user approval authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Chapter 9

Adding approvals to your application

151

Designing an approval application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152


Connecting an application to the approval server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Creating an approval request form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Creating the join forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Running arjoinfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Adding the approval request form to AP:Administration . . . . . . . . . . . . . . . . . . 157
Implementing the approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Adding notifications to the approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Creating notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Enhancing your approval forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Add workflow to your approval server forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Show the password field in the detail view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Add a field menu of valid names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Adding previews to your approval application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Multi-process preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Using a custom ad hoc dialog box with the approval server. . . . . . . . . . . . . . . . . . . . 171
Appendix A

Upgrading the approval server

173

The arapupgd utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174


Running one-time escalations to configure new data . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Performing required three-way join form updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Using the approval server on the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Mapping application request form fields to AP:Detail fields . . . . . . . . . . . . . . . . . . . 178
Appendix B

Application commands

179

Using Application-Command processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180


Application command syntax and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Application command parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
8

BMC Remedy Approval Server Guide

Example of an application command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Approval server commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add-PGNA-Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add-Sig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Det-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Det-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Det-Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Det-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generate-Multi-Process-Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generate-Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MoreInfo-Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New-Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rename-Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rename-Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Notify-Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Notify-State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sig-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Update-Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181
182
182
183
184
184
185
185
186
186
187
187
188
188
189
189
190
190
191
192
192
193

Appendix C

195

Worksheets

Process worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
More Information escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signature escalations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rule worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auto Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Authority Self rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Self Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prep Get Next Approver rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Authority Regular rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parameterized Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signature Accumulator rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistical Override rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Completion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Approval Process Done rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

196
196
196
197
200
200
200
201
201
201
202
202
203
203
204
204
204
205

Appendix D

207

Approval forms

Administration forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AP:AdhocDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AP:Admin-DeleteVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents

208
208
209
210
9

AP:Admin-Rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
AP:Admin-ServerSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
AP:Customize-SourceID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
AP:Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
AP:Detail-Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
AP:DynamicLabels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
AP:Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
AP:Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
AP:Preview Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
AP:PreviewInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
AP:PreviewSignatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
AP:Process Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
AP:Process Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
AP:Question-Comment-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
AP:Reserved Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
AP:Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
AP:Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
AP:Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
AR System Business Time forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
User forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
AP:AdhocDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
AP:Alternate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
AP:Dtl-Sig-MoreInfoDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
AP:More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
AP:Password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
AP:Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
AP:Rejection Justification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
AP:Show-Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
AP:ShowDetail-DeleteVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Appendix E

Installing the approval server in a server group

281

Appendix F

Troubleshooting

283

Installation and upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283


Previous approval server installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Error 333 and Assignee Group Permission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Approval server log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Location of log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Approver server logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Runtime issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Approver receives request but cannot respond . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Deadlocked approval server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Approval server configuration file settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
System error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Accessibility issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

10

BMC Remedy Approval Server Guide

Glossary

289

Index

293

Contents

11

12

BMC Remedy Approval Server Guide

Preface
IMPORTANT
The compatibility information listed in the product documentation is subject to
change. See the compatibility matrix at http://www.bmc.com/support for the
latest, most complete information about what is officially supported.
Carefully read the system requirements for your operating system, especially the
patch requirements. See the Installation Guide, Obtaining system requirements
and software, page 12.

Audience
The BMC Remedy Approval Server Guide is written for:

Users of the BMC Remedy Action Request System (AR System) product who
want to understand approval workflow, including requesters and approvers.

Administrators of AR System who install the BMC Remedy Approval Server


(approval server) component, create users, forms, and workflow objects, and
assign permissions.

Approval server process administrators who design and maintain approval


processes.

This document assumes you are familiar with AR System. The administration
sections assume that you want to add the approval server feature to an existing
application.
This document provides instructions to install approval server forms and
workflow on the Windows and UNIX operating systems, and assumes that you
are familiar with the environment in which you install the software.

AR System documents
The following table lists documentation available for AR System 7.6.04.
Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is
available on AR System product installation DVDs, on the Customer Support
website (http://www.bmc.com/support), or both.
Preface

13

BMC Remedy Action Request System 7.6.04

You can access product help through each products Help menu or by clicking
Help links.

NOTE
The AR System product help has not been updated for version 7.6.04. The help
topics still apply to version 7.6.03. For the most recent content, refer to the PDF
documentation.
Title

Description

Concepts

Guide1

Audience

Overview of AR System architecture and features; includes Everyone


information about add-on products that extend AR System
functionality and a comprehensive glossary for the entire
AR System documentation set.

Installation Guide

Instructions for installing AR System.

Administrators

Introduction to Application
Development with
BMC Remedy Developer
Studio

Information about the development of AR System


applications, including an introduction to using
BMC Remedy Developer Studio.

Developers2

Form and Application


Objects Guide

Information about AR System applications and their user


interface components, including forms, fields, views,
menus, and images.

Developers

Workflow Objects Guide

Information about the AR System workflow objects (active Developers


links, filters, and escalations) and how to use them to create
processes that enforce business rules.

Configuration Guide

Information about configuring AR System servers and


clients, localizing, importing and exporting data, and
archiving data.

Administrators

BMC Remedy Mid Tier


Guide

Information about configuring the mid tier, setting up


applications for the mid tier, and using applications in
browsers.

Administrators

Integration Guide

Instructions for integrating AR System with external


Administrators/
systems by using web services, plug-ins, and other products, Developers/
Programmers3
including LDAP, OLE, and ARDBC.

Optimizing and
Troubleshooting Guide

Information about monitoring and maintaining AR System Administrators/


and AR System applications to optimize performance and Developers/
solve problems.
Programmers

Database Reference

Database administration topics and rules related to how


AR System interacts with specific databases; includes an
overview of the data dictionary tables.

Administrators/
Developers/
Programmers

BMC Remedy Distributed


Server Option Guide

Information about implementing a distributed AR System


server environment with BMC Remedy Distributed Server
Option (DSO).

Administrators

BMC Remedy Flashboards


Guide

Instructions for creating, modifying, and administering


Administrators/
flashboards to display and monitor AR System information. Developers

C API Reference

Information about AR System data structures, C API


function calls, and OLE support.

Programmers

C API Quick Reference

Quick reference to C API function calls.

Programmers

14

BMC Remedy Approval Server Guide

AR System documents

Title

Description

Audience

Java API

Programmers
Information about Oracle Java classes, methods, and
variables that integrate with AR System. For the location of
the JAR file containing this online documentation, see the
information about the Java API in the Integration Guide.

Java Plug-in API

Information about Java classes, methods, and variables used Programmers


to write plug-ins for AR System. For the location of the JAR
file containing this online documentation, see the
information about plug-ins in the Integration Guide.

BMC Remedy Email Engine


Guide

Instructions for configuring and using BMC Remedy Email Administrators


Engine.

Error Messages Guide

Descriptions of AR System error messages.

Administrators/
Developers/
Programmers

Master Index

Combined index of all books.

Everyone

BMC Remedy Approval


Server Guide

Instructions for using BMC Remedy Approval Server to


automate approval and signature processes in your
organization.

Administrators

Release Notes

Information about new features, compatibility, and


international issues.

Everyone

Release Notes with Known


Issues

Information about new features, compatibility, international Everyone


issues, installation planning, and open issues.

BMC Remedy User Help

Instructions for using BMC Remedy User.

Everyone

BMC Remedy Developer


Studio Help

Instructions for using BMC Remedy Developer Studio to


develop AR System forms, workflow objects, and
applications.

Developers

BMC Remedy Data Import


Help

Instructions for using BMC Remedy Data Import.

Administrators

BMC Remedy Alert Help

Instructions for using BMC Remedy Alert.

Everyone

BMC Remedy Mid Tier


Configuration Tool Help

Instructions for configuring BMC Remedy Mid Tier.

Administrators

BMC Remedy Browser


Help

Instructions for using AR System forms in browsers.

Everyone

BMC Remedy Migrator


7.6.04 BMC Remedy
Migrator Guide

Outlines procedures for installing BMC Remedy Migrator,


setting options, and performing migration tasks.

Administrators /
Developers

BMC Remedy Migrator


online help

Procedures for setting BMC Remedy Migrator options and


performing migration tasks.

Administrators /
Developers

BMC Remedy Encryption


Security 7.6.04
BMC Remedy Encryption
Security Guide

Provides an overview of the BMC Remedy Encryption


Administrators
Security products and explains how to install and configure
them.

The full title of each guide includes BMC Remedy Action Request System 7.6.04
(for example, BMC Remedy Action Request System 7.6.04 Concepts Guide), except

Preface

15

BMC Remedy Action Request System 7.6.04

the BMC Remedy Migrator Guide and BMC Remedy Encryption Security Guide.
Application developers who use BMC Remedy Developer Studio.
3 C and Java programmers who write plug-ins and clients for AR System.
2

16

BMC Remedy Approval Server Guide

Chapter

Introduction to the approval


server
This chapter introduces basic concepts and terminology related to BMC Remedy
Approval Server (approval server).
The following topics are provided:

Approvals in business processes (page 18)


Overview of the approval server (page 18)
Basic approval server concepts (page 19)

Chapter 1

Introduction to the approval server

17

BMC Remedy Action Request System 7.6.04

Approvals in business processes


An approval indicates an agreement to or rejection of a request or decision. In
business, an approval represents the signature or acknowledgment of an
individual where required in a process. Approvals must often be recorded to
provide an audit trail and proof of authenticity associated with a signature. The
approval server provides this functionality in BMC Remedy applications and also
allows you to add any type of approval or signature-driven process to your own
AR System applications.
You can use the approval server for processes with the following requirements:

Workflow that includes need for agreement or acknowledgment from others

Processes that must be auditable

Signatures that must be authenticated

Overview of the approval server


The approval server is a self-contained, shared module that can be attached to any
AR System application. It is a flexible solution for automating any approval or
signature-driven process across any organization. You can have multiple instances
of the approval server running with multiple instances of the AR System server on
one computer. The approval server includes built-in contingency handling, which
makes sure that approvals are completed quickly and properly within the system.
When an AR System application triggers an approval process, the approval server
routes a request to collect signatures within a defined approval process, handling
all notifications and requests for more information as it collects each response
(approval or rejection). The approval server then reactivates the original
application and reports the result of the approval process.
Figure 1-1: Using BMC Remedy Approval Server with AR System applications

18

BMC Remedy Approval Server Guide

Basic approval server concepts

Flexibility and common experience


You can use the approval server to define or modify how each approval process
should work. You can set up new processes and adapt existing processes as
changes occur in your organization. Customizing the approval server does not
require programming expertise.
For every stage of the approval process, you can define notifications to inform
interested parties of the status of an approval request. The approval server allows
approvers to gather more information about a request from any AR System user.
With BMC Remedy Approval Server, you do not need to build custom workflow
or separate solutions for each application. All processes can share the same
approval engine, providing a common approval experience across applications.

Notification with feedback


Although you can use built-in AR System functionality to exchange simple
notifications, using the approval server to do so enables you to build a feedback
loop. You can use this functionality to support business processes for which you
must make sure that the workflow has been seen and approved, acknowledged, or
signed by all the relevant parties.

Basic approval server concepts


An approval requires a process for people to acknowledge, approve, or reject an
approval request. This section describes the approval process and approval server
roles.

Approval processes
An approval process is a set of rules and procedures, based on data, that enforce
processes and workflow to require the appropriate people to review, approve, and
reject requests.

A process must have rules to make sure all required approvals occur, no
erroneous approvals occur, and sufficient authority is present to enable
approval.

A process must have procedures to route an approved request to the next


approver, to stop routing a rejected request, and to notify a person when a
response is required.

Every approval requires a process to obtain appropriate signatures. Business


processes often require the signatures of several people in one or more operational
groups. Business processes also need to allow for alternate approvers to cover days
when the regular approvers are unavailable.

Chapter 1

Introduction to the approval server

19

BMC Remedy Action Request System 7.6.04

A given request might require one simple approval process, or several processes
that work with each other. Often the appearance of a single operation involves
multiple approvals. Some requests must follow a process but can be approved
automatically based on certain criteria.
In BMC Remedy Approval Server, an approval process is the set of rules and forms
that generate data to authorize specific AR System workflow. An approval process
consists of definitions for the operation itself, rules that define what happens at
each specific stage in the process, and a place to store signatures. While process
administrators need to understand these rules, they are transparent to approvers.
The types of rules and how they interact are described under Approval server
rules on page 82.
The data generated by an approval process, such as the type of approval, approver
signatures, requests for more information, and time stamps for audit trails, is
stored in the detail record and other supporting forms. This enables you to track
the approval process for auditing or troubleshooting purposes. For more
information about data, see Approval data and audit on page 70.

Approval roles
Three roles are involved in the approval process: those requesting approval
(requesters), those approving requests (approvers and alternate approvers), and
process administrators who set up and modify the approval server configuration.
Most approval processes are transparent to requesters, who therefore do not need
a thorough understanding of approval server. This document is primarily written
for approvers and process administrators.

Requesters
Requesters are people who want something to be approved. Requesters work with
an application that starts an approval process by entering an approval request.
Approval requests are routed to all required approvers according to the rules of
the approval process.
The approval server allows requesters to enter approval requests, check the status
of their requests, and respond to More Information requests.

Approvers
Approvers are people with the authority to approve, reject, reassign, hold, or
provide questions and comments for a request in a given process.
The process administrator configures approvers for each process, so that each
request has a specified approver list. Different requesters can have different
approver lists for the same process.
An approver list specifies the exact list of signatures required for a request. A
signature can come from an individual or from a business role containing multiple
individuals, such as department managers. The approval server allows you to
work with any combination of individuals and roles to create the approver list for
each process.
20

BMC Remedy Approval Server Guide

Basic approval server concepts

Approvers interact with the approval server to review outstanding requests that
are assigned to them, and to take action on those requests. Approver actions are
performed using Approval Central, which is the approval server console. (For
more information, see Approval Central on page 255.) The actions approvers
can take include:

Approving

Rejecting

Reassigning

Holding

Requesting and responding to More Information Requests

Checking status

Approvers have access to the details of the request being processed as well as to
the request history. The history includes a list of all approvers who have
responded to the request, and the actions they took. Also, any comments that have
been entered by other approvers are available for review.
If approvers need to obtain more information before approving a request, they can
send a More Information request to any AR System user. A More Information
request is separate from the approval request, but remains associated with it.

Alternate approvers
When an approver cannot be available, such as during a business trip or vacation,
the approver can define an alternate approver with the same authority within an
approval process. An alternate is someone who substitutes for the approver and
acts with the approvers authority and privileges for a duration of their choice.
Approvers can to set up any number of alternates. Each alternate might be set up
to substitute within one or more approval processes.

Process administrators
The process administrator is a user who has permission to carry out design and
administration tasks in the approval server. Process administrators can perform
the following tasks:

Define approval server processes and rules.

Override the normal flow of a process when an emergency situation requires it.

Grant limited authority to specified users, allowing them to configure a process,


to override a process, or both.

Designate alternates for any approver.

Process administrator actions are performed using the AP:Administration form.

NOTE
An approval server process administrator is not the same as the AR System
administrator. See Chapter 5, Introduction to approval forms, processes, and
rules, for an explanation of the process administrators responsibilities.
Chapter 1

Introduction to the approval server

21

BMC Remedy Action Request System 7.6.04

22

BMC Remedy Approval Server Guide

Chapter

Configuring the approval


server
This section describes the procedures that process administrators use to configure
BMC Remedy Approval Server (approval server).
The following topics are provided:

Using the approval server Administration form (page 24)


Process administrator (page 25)
Configuring process administrator capabilities (page 26)
Configuring server settings (page 27)
Configuring business times (page 32)
Configuring previews (page 33)
Configuring the approval server to work with flowcharts (page 33)

Chapter 2

Configuring the approval server

23

BMC Remedy Action Request System 7.6.04

Using the approval server Administration form


Process administrators use the AP:Administration form to perform the following
tasks of managing and configuring the approval server:

Create or configure other process administrators and alternates

Access AR System server settings specific to the approval server

Rename related processes and forms

Manage approval server processes, rules, notifications, roles, and forms

To access the AP:Administration form, you must be an approval server process


administrator or an AR System administrator.
Figure 2-1: AP:Administration form

To open the AP:Administration form


1 Log in to AR System as an AR System administrator or a process administrator by

using BMC Remedy User or a browser.


2 Open the AP:Administration form by using the link on the default AR System

Home Page form.


If you do not see a link on AR System Home Page, open the form as follows:

In BMC Remedy User, press Ctrl+O to open the object list, and open the
AP:Administration form.

In a browser, enter the following URL and press Enter:


http://hostName/arsys/forms/serverName/AP:Administration
hostName is the name of the web server, and serverName is the name of the
AR System server.

24

BMC Remedy Approval Server Guide

Process administrator

This chapter only describes how to use the following tabs and links on the
AP:Administration form:

Administrator tabThis tab enables you to create and configure process


administrators. See Creating a process administrator on page 26.

Server settings linkThis link enables you to configure approval server


logging, and customize other approval server settings. See Configuring server
settings on page 27.

For information about using other tabs and links on the AP:Administration form,
see Chapter 6, Defining an approval process, Chapter 7, Defining approval
rules. Also see these sections: Connecting an application to the approval server
on page 152, Adding notifications to the approval process on page 158, and
Defining roles on page 106.

Process administrator
A process administrator is an AR System user with the authority to define an
approval process and to perform administrative tasks related to the AR System.
The first process administrator must be set up by the AR System administrator, but
others can be set up by an existing process administrator.
The process administrator is a more powerful authority than the signature
authorities (approvers) who actually sign approval requests. A process
administrator performs the following responsibilities:

Designs the approval process to generate approval signature data when


AR System workflow needs to be authorized.

Connects the approval server forms to workflow to accomplish the designed


approval process. This includes configuring routing, and creating the list of
authorized approvers. See also Chapter 9, Adding approvals to your
application.

Overrides a process, or parts of a process, when circumstances arise that must


be handled outside of established workflow. See Performing overrides on
page 54.

Creates and deletes other process administrators as needed. Other process


administrators can have full or limited authority. A process administrator with
limited authority can perform the following activities:

Act as an administrator to manage only specific processes that are assigned


by a process administrator with full authority.

Act as an override-only administrator to approve or reject requests regardless


of the approver list for the assigned processes.

Chapter 2

Configuring the approval server

25

BMC Remedy Action Request System 7.6.04

Configuring process administrator capabilities


Administrators having the appropriate privileges can use the AP:Administration
form to create process administrators with the following types of authorities:

Full Admin authoritygrants the ability to configure and modify processes, as


well as to approve or reject requests regardless of the normal process.

Override Only Admin authoritygrants the ability to approve or reject requests


regardless of the normal process, but not create or modify processes.

Process administrator prerequisites


The first process administrator must be created with Full Admin authority by an
AR System administrator. Subsequent process administrators can be created by
any process administrator with the Full Admin authority. To designate a user as a
process administrator, the user must exist in AR System, and must be a member of
the AR System Approval Admin group. If the user ID for a process administrator
does not exist, an AR System administrator must create it and assign the user to the
Approval Admin group. See the Configuration Guide, Adding and modifying user
information, page 57.

Creating a process administrator


This section describes how to assign process administrator authority to an existing
AR System user who is a member of the Approval Admin group.

To create a process administrator


1 Open the AP:Administration form as described in Using the approval server

Administration form on page 24.


2 Open the Administrator tab, and click Create to open the

AP:Process Administrator form.


Figure 2-2: Creating a process administrator

26

BMC Remedy Approval Server Guide

Configuring server settings

3 On the Process Administrator tab, specify appropriate values in the various fields.

See AP:Process Administrator on page 229.


4 Click Save.

Configuring server settings


You can configure various approval server settings such as specifying the debug
mode, log file name and location, and the private queues for loopback calls.
The AP:Admin-Server Settings form allows process administrators to manage
settings that apply to all approval server functionality and processes.

Approval server debug log


If you select the Approval Debug Mode check box, a log of approval activity is
generated. The log is a text file, and is stored in the location you specify in the
AP:Admin-ServerSettings form.
After the log is activated, logging starts immediately. The log file is emptied and
restarted when you restart the approval server or when you reactivate logging
after it has been deactivated. Because logging can generate large files, you should
plan to use the log for specific purposes, or regularly save and delete your log files.
The following output is a sample of the approval information stored in the log file.
<APPR> Approval Server Trace Log -- ON (Fri Mar 17 2006
10:39:00.9700)
<APPR>
Configuration tag Approval-Log-File: updated
successfully
<APPR>
Delete pending item -- 000000000000134
<APPR> Processing item number 1 (Fri Mar 17 2006 10:39:00.9860)
<APPR>
Initiated by -- Demo
<APPR>
Category
-- Approval
<APPR>
Command
-- Update-Config
<APPR>
Source Form
-<APPR>
Entry ID
-<APPR>
Tag
-- Debug-mode:
<APPR>
Field ID 1
-- 0
<APPR>
Field ID 2
-- 0
<APPR>
Field ID 3
-- 0
<APPR>
Other Short
-<APPR>
65536
<APPR>
Process an 'Update-Config' command
<APPR>
Configuration tag Debug-mode: updated successfully
<APPR>
Delete pending item -- 000000000000135
<APPR> Processing item number 2 (Fri Mar 17 2006 10:39:01.0170)
<APPR>
Initiated by -- Demo
<APPR>
Category
-- Approval
<APPR>
Command
-- Update-Config
<APPR>
Source Form
-<APPR>
Entry ID
-Chapter 2

Configuring the approval server

27

BMC Remedy Action Request System 7.6.04

<APPR>
<APPR>
<APPR>
<APPR>
<APPR>
<APPR>

Tag
Field
Field
Field
Other

ID 1
ID 2
ID 3
Short

------

Approval-Defn-Check-Interval:
0
0
0

Private queues for loopback calls


The Server Settings form provides the Private AR Server RPC Socket and Plugin
Loopback RPC Socket fields for controlling loopback calls to the AR System server.
A loopback call occurs when the approval server plug-in initiates a call back to the
AR System server while processing approval workflow. During heavy loads, this
can cause a server deadlock if enough queues or threads are not available. To avoid
this, use a dedicated loopback RPC queue. The valid RPC port number ranges are:

390621390634

390636390669

390680390694

To use the approval preview feature, you must set either the Private AR Server
RPC Socket or the Plugin Loopback RPC Socket.

Private AR Server RPC Socket


The Private AR Server RPC Socket field creates a private queue dedicated to
approval server loopback calls only. This setting appears in the AR System server
configuration file with the tag Approval-RPC-Socket.
If both the Private AR Server RPC Socket and Plugin Loopback RPC Socket values
are set, the approval server uses the Private AR Server RPC Socket.

Plugin Loopback RPC Socket


The Plugin Loopback RPC Socket field creates a private queue for all loopback calls
from the plug-in server, regardless of which plug-in application initiates the call.
If this value is set and the Private AR Server RPC Socket field is not set, the Plug-in
server uses this queue for approval server loopback calls. In other words, the
approval server shares this queue with other plug-in applications, but not with
AR System users.
This setting appears in the AR System server configuration file with the label
Plugin-Loopback-RPC-Socket.

NOTE
The Plugin Loopback RPC Socket field of the Server Settings dialog box controls
the same setting as the Plugin Loopback RPC Program Number field on the Ports
and Queues tab of the AR System Administration: Server Information form.

28

BMC Remedy Approval Server Guide

Configuring server settings

If the Plugin Loopback RPC Program Number is already defined for the
AR System server, enter the same RPC number in the Plugin Loopback RPC Socket
field of the Server Settings window. If this queue is not already defined for the
server, it will appear in the Server Information dialog box, on the Server Ports and
Queues tab, after you enter it in the Server Settings dialog box.
For more information about defining server ports and queues, see the
Configuration Guide, Server InformationPorts and Queues tab, page 157.

How the approval server uses RPC settings


In releases earlier than BMC Remedy Approval Server 7.5.00, RPC settings were
used as follows.
The approval server used the following RPC program numbers (defined by using
fields on the AP:Admin-ServerSettings form):

Private AR Server RPC Socket(Optional) If a value was specified, the


Private-RPC-Socket and Approval-RPC-Socket entries were created in the
ar.cfg (Windows) or ar.conf (UNIX) file, and a private queue dedicated to
approval server loopback calls was used, instead of using the default
administration (admin) queue at 390600.

Plugin Loopback RPC Socket(Optional) If specified, the Plugin-LoopbackRPC-Socket entry was created (or updated) in ar.cfg (or ar.conf), and that
queue was used for the Preview feature. If this value was not provided, the
Preview feature did not work.

These values were supposed to be different because they were used for different
functionalities.
Beginning with release 7.5.00, the approval server uses the Visualizer sub-plugin
to render previews (different from the Preview feature implementation).
Therefore, the same RPC queue can be used for approval processing as well as
preview generation.
Following this change, the RPC settings are provided by default at the time of
installation or upgrade:

When performing a fresh installation, the Private-RPC-Socket, ApprovalRPC-Socket, and Plugin-Loopback-RPC-Socket entries are created and set to
390680.

When upgrading to release 7.5.00 or later:

If Private-RPC-Socket, Approval-RPC-Socket, and Plugin-LoopbackRPC-Socket values are already defined in the existing setup, they are not
changed.

If Approval-RPC-Socket is not defined, but other Private-RPC-Socket


entries exist, the Private-RPC-Socket and Approval-RPC-Socket entries
are created and set to the next available valid value.
If this value is not specified, approval processing is done through the default
admin queue.

Chapter 2

Configuring the approval server

29

BMC Remedy Action Request System 7.6.04

If Plugin-Loopback-RPC-Socket is not defined, the corresponding entry is


created and set to the same value as that of Approval-RPC-Socket.
By default, the approval server uses this socket to run the Visualizer subplugin.

WARNING
If Plugin-Loopback-RPC-Socket is not defined, the approval server attempts to
use Approval-RPC-Socket to run the Visualizer sub-plugin. Therefore, if
Approval-RPC-Socket is missing from ar.cfg (or ar.conf), the Preview feature
will not work.

Configuring settings on the Basic tab


The Basic tab contains settings for generating an approval server log file, setting
the definition check interval, and configuring RPC and Loopback sockets.

To configure the server settings on the Basic tab


1 Open the AP:Administration form in BMC Remedy User or a browser.
2 Click the Server Settings link in the navigation pane.
3 On the AP:Admin-ServerSettings form, open the Basic tab (Figure 2-3 on page 30).
Figure 2-3: AP:Admin-Server Settings form

30

BMC Remedy Approval Server Guide

Configuring server settings

4 To generate a log of the approval server activity, check Approval Debug Mode.
5 In the Log File Name field, type the full path to the debug log file.

See Approval server debug log on page 27.


6 In the Definition Check Interval field, accept the default (300), or enter a new value.

The Definition Check Interval is the number of seconds after which the approval
server checks for changes to process definitions.

A larger number can increase AR System performance.

A smaller number is useful while creating and testing a process.

A zero (0) in this field causes immediate implementation of a definition.

7 To cause the approval server to use a dedicated private queue when it makes calls

to the AR System server, enter an RPC port number in the Private AR Server RPC
Socket field.
Choose an available RPC port number from the valid ranges. See Private queues
for loopback calls on page 28.
Leave this field empty if your approval server implementation does not use a
dedicated queue for loopback calls to the AR System server.
8 To cause the approval server to use the plug-in loopback RPC socket for loopback

calls, as required for the preview feature, enter the loopback queue RPC port
number in the Plugin Loopback RPC Socket field. Use an RPC port number from
the ranges given in step 7.
Leave this field empty if your Plug-in server does not use a dedicated loopback
RPC port. See Plugin Loopback RPC Socket on page 28.
9 Specify the Due-Soon Interval in Hours or Days for approval requests to be

highlighted when an approver logs in to Approval Central.


10 Specify the Recent History Interval in Hours or Days for the approval requests to

be displayed in the My Recent History section of Approval Central for an


approver.
11 Click Save to save your changes.
12 If you set a value for either the Private AR Server RPC Socket or Plugin Loopback

RPC Socket field, restart the AR System server.

Configuring settings on the Notifications tab


The Notifications tab of the AP:Admin-ServerSettings form allows you to define
which types of approval events can trigger notifications. These settings apply to all
approval events across processes. To define the specific notifications for a process,
see Adding notifications to the approval process on page 158.

NOTE
Activating events on this form does not guarantee that this event will generate a
notification or escalation. However, if you do not activate an event on this form, all
other notification and escalation settings are ignored for that event.
Chapter 2

Configuring the approval server

31

BMC Remedy Action Request System 7.6.04

To define the events that trigger notifications


1 Open the AP:Administration form in BMC Remedy User or a browser.
2 Click the Server Settings link in the navigation pane.

The AP:Admin-ServerSettings form appears.


3 Click the Notifications tab.
4 Select the appropriate option button for each event.

DisabledSelect Disabled if you never want the event type to trigger a


notification.

EnabledSelect Enabled for each event type that you want to send a
notification.

Enabled Including AlternateSelect this setting if you want the event to


trigger a notification for both the intended approver and any designated
alternates.

Configuring settings on the Escalations tab


The Escalations tab of the AP:Admin-ServerSettings form allows you to define
which types of approval events can trigger notifications.

To define approval events that can trigger notifications


1 Click the Escalations tab.
2 Select the appropriate option buttons to determine which event types are Disabled,

Enabled, or Enabled Including Alternate, as defined in Configuring settings on


the Notifications tab on page 31.
3 Click Save.

Configuring business times


The approval server uses the data in the business time forms to schedule approval
notifications. Business time in AR System is the ability to define periods of
availability and unavailability, workdays, and holidays to calculate business
schedules using AR System commands.
You must configure business times to assure that your approval notifications and
escalations calculate times correctly. For information, see the Configuration Guide,
Using Business Time in the AR System server, page 215.

32

BMC Remedy Approval Server Guide

Configuring previews

Configuring previews
The AP:PreviewInfo form allows requesters and approvers to get a list of the
completed and remaining approvals for any request. This is referred to as
previewing approvals.
To allow users to preview approval responses, you must perform the following
configuration actions:

Configure the AR System server and the approval server to use a Plug-in
Loopback RPC socket. See Configuring settings on the Basic tab on page 30.

Configure the approval process to generate a preview at the required time. See
Creating a process on page 98.

Design a form that will query the AP:PreviewInfo form. See Adding previews
to your approval application on page 168.

Create workflow that uses the Add-PGNA-Values command to gather


signatures. See Defining Parameterized Get Next Approver rules on page 126.

Configuring the approval server to work with


flowcharts
To enable flowchart views for approval requests, you must perform the following
configuration actions.

On the AR System Server Administration Console > System > General > Server
Information page:

On the Ports and Queues tab, check whether a private RPC private port has
been defined for the approval server. The values of Min Threads and Max
Threads for this port should be greater than one.
Also check whether the same port is used in the approval Plugin Loopback
RPC Socket setting on the AP:Admin-ServerSettings form. See Configuring
settings on the Basic tab on page 30.

NOTE
The suite installer defines the RPC port and sets the same in the approval Plugin
Loopback RPC Socket automatically. Confirm that these settings exist, and define
them if they do not.

On the Advanced tab, set the Default Web Path to:


http://ARSystemServerName:8080/arsys

For more information, see the Configuration Guide, Configuring AR System


servers, page 122.

Chapter 2

Configuring the approval server

33

BMC Remedy Action Request System 7.6.04

On the Basic tab of the AP:Process Definition form, select a value from the
Generate Preview list.

On the General Settings page of the BMC Remedy Mid Tier Configuration Tool:

Set the Data Visualization Module Server to the server where the Visualizer
plug-in is installed.

Select the appropriate authentication server.


See the Configuration Guide, Server InformationEA tab, page 144.

NOTE
You must have Flash version 9.x or later installed on the machine.
The flowchart view is backward compatible with mid tier 7.1.00 and 7.0.01. You
can use any version of BMC Remedy User to see the flowchart view for an
approval request, or view it through a browser.

NOTE
The Data Visualization Field cannot be seen using Firefox 2.0.0.11 on Mac 10.4.11;
this is an issue with the browser.

34

BMC Remedy Approval Server Guide

Chapter

Processing approval requests

Approval Central is the primary console for the users of BMC Remedy Approval
Server (approval server).
This section describes how approvers use Approval Central to process approval
requests, how approvers and process administrators specify alternate approvers,
and how process administrators carry out approval overrides.
The following topics are provided:

Approval Central (page 36)


Opening Approval Central (page 37)
AR System Object List in browsers (page 37)
Working with pending approval requests (page 38)
Processing More Information requests (page 45)
Using alternate approvers (page 50)
Performing overrides (page 54)

Chapter 3

Processing approval requests

35

BMC Remedy Action Request System 7.6.04

Approval Central
Approval Central is designed for process administrators and approvers, and can
be used to perform the following activities:

Search for approval requests by specifying certain criteria

View approval request details

Approve or reject requests

Put requests on hold

Define alternate approvers

Reassign a request to another approver

Create or respond to More Information requests

Process administrators use Approval Central to override approvers to respond to


requests when necessary. Approvers also use Approval Central when acting as
alternates for other approvers.
Figure 3-1: Approval Central as seen by the sample user Jack Miller

For more information, see Approval Central on page 255.

36

BMC Remedy Approval Server Guide

Opening Approval Central

Opening Approval Central


This section describes the different ways to open Approval Central.

To open Approval Central from the AR System Home Page


If the approval server is installed and configured with your AR System server, the
AR System home page form contains an Approval Central link. Click this link to
open Approval Central.

To open Approval Central in a browser


1 Launch your browser and enter a URL as follows:
http://hostName/arsys/forms/serverName/Approval Central

where hostName is the name of the web server where BMC Remedy Mid Tier is
running, and serverName is the name of the AR System server where the approval
server is running. Ask your AR System administrator for the exact URL.
2 In the BMC Remedy Mid Tier login window, enter your user name and password,

along with an authentication string if necessary, and click Log In.


You can use a similar procedure to access any other approval server forms, such as
the AP:Administration form.

To open Approval Central in BMC Remedy User


1 Open BMC Remedy User, and log in to the appropriate AR System server.
2 Choose File > Open > Object list.

The object list appears, showing the objects that you have access to. This list might
include the Approval Central entry point and the Approval Central form.
3 Select the Approval Central form, and click New or Search.

Because Approval Central is a display-only form, it always opens in Search mode.

AR System Object List in browsers


The AR System Object List displays a list of all forms (including Approval Central)
and other object types for which the user has permissions. The AR System
administrator can make the object list available in a browser, by entering the URL
http://hostName/arsys/forms (hostName is the name of the web server where
BMC Remedy Mid Tier is running).
For information about how to make the AR System Object List available in a
browser, see the BMC Remedy Mid Tier Guide, Enabling the AR System Object
List, page 87.
For information about AR System server objects, see the Form and Application
Objects Guide and the Configuration Guide.

Chapter 3

Processing approval requests

37

BMC Remedy Action Request System 7.6.04

Working with pending approval requests


This section describes how to search for specific approval requests, and provides
procedures for managing and responding to approval requests.
The examples in this section are from the sample applications Get Agreement and
Lunch Scheduler, which are installed with the approval server. For more
information about the sample applications, see Chapter 4, Using the Get
Agreement sample application and Chapter 8, Using the Lunch Scheduler
sample application.

Processing an approval request


Approvals typically follow this sequence:
Step 1 Someone submits a request that requires your approval.
Step 2 You receive notification of the approval request.
Step 3 You review the approval request and take one of the following actions:

If the approval request appears to be in order, you can approve it.

If you need more information, you can enter a question or comment for the
approval server to route to the requester or other individual (a More
Information request).

If the request appears unacceptable, you can reject it. Rejection usually ends the
process for this request, unless rules are in place that require further processing.
See Get Authority and Get Authority Regular rules on page 91, and
Signature Accumulator and Statistical Override rules on page 88.

If you are not the appropriate person to approve the request, you can reassign it.

Performing a search on Approval Central


When you open Approval Central, a query with the following search criteria is
executed automatically:

Acting As = MySelf

User = yourARSystemUserID

Approval Status = Pending or Approval Status = More Information or


Approval Status = Hold

Using this query, AR System searches for requests that are awaiting your action. If
any requests are found, they appear in the Pending Approvals table.
The Approval Tasks section provides more predefined searches. You can also use
the Search My Approvals link in the Action Menu section to open the Approval
Search section in the right pane. Specify your search criteria in this section, and
click the Search button to display a set of requests in the Approval Search Result
table.
38

BMC Remedy Approval Server Guide

Working with pending approval requests

For example, you can retrieve a list of only those requests pertaining to a particular
application, requests made by a specific requester, requests that are already
approved or rejected, or requests directed to another approver, for whom you are
designated as an alternate. For more information, see Approval Central on
page 255.
The following procedure is an example of how to retrieve a list of requests
pertaining to a particular application.

To see all requests in the AP-Sample2:Get Agreement application


1 Open Approval Central using one of the methods described in Opening

Approval Central on page 37.


2 In the Action Menu section, click Search My Approvals.
3 In the Approval Search section, select AP-Sample2:Get Agreement in the

Application field, and select (clear) in the Status field.


4 Leave the default values in the remaining fields, and click Search.

The Approval Search Result table then displays all requests that belong to the
AP-Sample2:Get Agreement sample application for the current user.
For information about how to add an application to the Application field, see
Connecting an application to the approval server on page 152.

Approving and rejecting requests from Approval Central


Approval Central contains the Approve, Reject, Hold, and Reassign buttons that
allow you to act on approval requests without opening them individually.

To use the Approve, Reject, Hold, or Reassign buttons


1 Open Approval Central using one of the methods described in Opening

Approval Central on page 37.


2 In the Pending Approvals table, use the check boxes to select the pending requests

that you want to act upon.


3 Click Approve, Reject, Hold, or Reassign.

If the related approval processes require approvers to enter a password, the


AP:Password dialog box appears.
4 If necessary, enter your password when prompted, and click Submit.

If you click Reassign, and the related approval processes are enabled for
reassignment, the AP:Reassign dialog box appears.
5 If necessary, enter the name of the person to whom you want to reassign the

requests, and click OK.


The selected requests disappear from the list of pending requests in the Pending
Approvals table.

Chapter 3

Processing approval requests

39

BMC Remedy Action Request System 7.6.04

WARNING
No undo option exists when you respond to a request. After you respond to a
request, you do not have any opportunity to change your mind.
If you click Approve and other approvers are required, AR System routes the
requests to the respective next approvers. If you click Approve and no further
approvers are required, the request statuses change to Approved, and the
approval process is done. If you click Reject, the request statuses change to
Rejected, and the approval process is done. If you click Hold, the request statuses
change to Hold until any further action is performed on them.
If you provide an incorrect password, the error Authentication failed.
Please enter your valid AR System password. (ARERR 45490) appears,
and no action is performed on the selected requests.

Rejection justification for approval requests


On Approval Central or AP:Show-Detail, approvers can provide a justification for
rejecting a request by entering some meaningful text in the Justification For Action
field and clicking Reject.
The justification is stored as a note in the Approval Activity Log, and pushed to:

AP:Question-Comment-Info as a comment of the Justification type

AP:Signature, from where the application can access it

A field on the application form, if and as defined in the process

Currently, this feature is associated only with the Reject action. If an approver
enters a justification and clicks any other action button, the request status changes
as appropriate, but the text is not stored at any location.
The mandate for providing a justification is configurable at the process level.
Process administrators can use the Rejection Justification area on the
Configuration tab of AP:Process Definition to specify:

whether an approver must provide a justification when rejecting a request

the field on the application form in which the justification is stored

If justification is required, but the approver does not enter any text in the
Justification For Action field on Approval Central before clicking Reject, the
AP:Rejection Justification dialog box appears. The following events could occur:

If the approver clicks Cancel, the following message is displayed:


Cancelling the action, because the justification required by the
current process was not provided. (ARWARN 46408)

The Reject action is cancelled, the request remains in the Pending state, and no
log entry is created.

If the approver clicks OK without entering some text in the Justification field, the
following message is displayed:
Please enter appropriate rejection justification. (ARNOTE 46409)

40

BMC Remedy Approval Server Guide

Working with pending approval requests

If the approver provides some text and clicks OK, the request is rejected. The text
is saved in AP:Question-Comment-Info as a comment of the Justification type.
The justification also appears in the Activity Log.

Applications can also enable approvers to provide rejection justification on the


three-way join form. To make this possible, application developers must:

Add a Character field of unrestricted length (to accept more than 255 characters)
on the three-way join form for an approver to enter the comment.

Provide the workflow to push the comment onto AP:Signature after the
approver clicks Reject.

If the process mandates a rejection justification, and the approver sets Approval
Status to Rejected and saves the request without providing a justification, the
Reject action fails. The following error is written to the approval log:
The processName process requires a rejection justification, which
the approver failed to provide.

See Creating the join forms on page 153 and Appendix D, Approval forms.
For general information about join forms, see the Form and Application Objects
Guide, Join forms, page 148.

Working with request details


The View Details button on Approval Central opens the AP:Show-Detail form,
which enables you to see more details about a request. You can also approve, reject,
or hold an approval request, add ad hoc approvers, reassign a request to another
approver, and create or respond to More Information requests using this form.
On Approval Central, the Source ID link that appears in the Approval Request
Summary section for a request opens the relevant application form. Click the Show
Signatures button on the application form (if implemented) to open the three-way
join form associated with the application request. This document also refers to this
view as the detail view. The following procedures use this detail view to
perform various actions on an approval request.

Setting the Approval Status in the detail view


After viewing the details of an approval request, you can approve or reject the
request by changing the Approval Status in the detail view.

To approve an approval request by changing the Approval Status field


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Pending Approvals table, select the pending request you want to work with,

and click its Source ID link in the Approval Request Summary section.
The appropriate request form opens (for example, AP-Sample2:Get Agreement).

Chapter 3

Processing approval requests

41

BMC Remedy Action Request System 7.6.04

3 Click the Show Signatures button.

The appropriate three-way join form opens (for example, AP-Sample2:Issue Detail
Signat).
Figure 3-2: Setting the Approval Status field

4 Click the drop-down arrow on the Approval Status field, and choose Approve, as

shown in Figure 3-2.


To ask for more information about the request, see Processing More Information
requests on page 45.
5 If the Password field is present, enter your password. Otherwise, proceed to the

next step.
If a password is required and you do not enter your password, or if you enter the
wrong password, AR System returns the following error:
Authentication failed. Please enter your valid AR System password.
(ARERR 45490)

NOTE
The AR System administrator must configure the password field to appear on the
three-way join form when it is required. See Show the password field in the detail
view on page 167.
6 Click Save.
42

BMC Remedy Approval Server Guide

Working with pending approval requests

You can use the same procedure to reject or hold a request by setting the Approval
Status to Rejected or Hold.
For information about how to configure an approval process to require a
password, see Creating a process on page 98.
When you return to Approval Central and refresh the search, this request is
removed from the table of pending requests.

WARNING
Once you respond to a request, you cannot undo or change your response.

Specifying additional approvers


Perform the following procedure if you must specify the next approver instead of
automatically routing the request. With some processes, such as an Ad Hoc
process, approvers can or must specify additional approvers. The process
administrator can also configure Parent-Child, Level, and Rule-Based processes to
allow users to add the next approver with the Allow Ad Hoc Next Approver field.
See Creating a process on page 98.
You must specify the additional approvers before or at the same time as you
approve or reject the approval request. After you have approved or rejected the
request, you no longer have access to the Next Approvers field.

NOTE
If the approval process includes rules that specify the next approver, the process
rules supersede any changes you make in the detail-signature view.
Specifying the next approver is not the same as reassigning an approval request.
The option to specify the next approver also requires you to approve or reject the
request. For information about reassigning requests, see Reassigning approval
requests on page 45.

To specify next approvers


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Pending Approvals table, select the pending request you want to work with,

and click its Source ID link in the Approval Request Summary section.
The relevant request form appears.
3 Click the Show Signatures button.

The appropriate three-way join form.

Chapter 3

Processing approval requests

43

BMC Remedy Action Request System 7.6.04

Figure 3-3: Adding multiple approvers

4 In the Next Approver field, enter the names of the next approvers.

You must enter one or more AR System login IDs. To specify multiple approvers,
separate each name with a semicolon (;).
5 If you specify multiple approvers, determine the appropriate option for the If

Multiple Approvers field.

One Must SignA single signature entry is created for all approvers. Only one
of those approvers needs to take action.

All Must SignSeparate signature entries are created for all approvers. Each
approver must take action for the request to proceed further.

NOTE
In an Ad Hoc approval process, if you do not complete the If Multiple Approvers
field, AR System requires all additional approvers to sign the request.
6 In the Approval Status field, select Approved.
7 Click Save.

Figure 3-3 on page 44 illustrates an example of this procedure. In this example, the
approver Jack Miller has approved the request, added two additional approvers,
and specified that both must approve the request separately.

44

BMC Remedy Approval Server Guide

Processing More Information requests

Reassigning approval requests


To reassign an approval request to a different approver, perform the following
procedure. The Reassign To field appears when the process allows you to reassign
approval requests.

To reassign an approval request


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Pending Approvals table, select the pending request you want to work with,

and click its Source ID link in the Approval Request Summary section.
3 In the request form, Click the Show Signatures button.
4 In the Reassign To field on the three-way join form, enter the name of the approver

to whom you want to reassign the request.


You can enter only one persons AR System login ID.
5 Click Save.

The approval server routes the request to the reassigned approver.

Processing More Information requests


If you need more information before approving or rejecting an approval request,
you can send a More Information request, which is an independently-routed
AR System record. The approval server uses the AP:More Information form to
manage More Information requests.
When you create a More Information request, the approval server links it to the
original approval request and changes the status of the approval request to More
Information. Thus, others can see that the request is paused until the More
Information request is answered.
Your response to the original approval is independent from the More Information
requests routing. In other words, you do not have to wait for the More
Information response before approving or rejecting the approval request.
However, if you do approve or reject the original approval request, the approval
server immediately closes any related outstanding More Information requests.
The procedures in this section describe the basic steps for requesting more
information and responding to More Information requests.

Requesting more information about approval requests

Viewing and responding to More Information requests on page 47

Viewing pending More Information requests and responses on page 48

The Questions and Comments features that make it easier to work with More
Information Requests. For more information, see AP:Show-Detail on page 271.

Chapter 3

Processing approval requests

45

BMC Remedy Action Request System 7.6.04

Requesting more information about approval requests


Use the following procedure to request more information before approving a
request.

To request more information about approval requests


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Pending Approvals table, select the pending request you want to work with,

and click its Source ID link in the Approval Request Summary section.
3 On the application request form that appears, click the Show Signatures button.
4 On the relevant detail form that appears, click Manage More Information.

NOTE
The Manage More Information control is not provided out-of-the-box with the
approval server; it is only included in the sample applications. To use this control
with a customized application, you must add it to the relevant three-way join form.
5 On the AP:Dtl-Sig-MoreInfoDialog form, click New Record to create a More

Information request.
6 On the AP:More Information form, specify values in the various fields as follows:
a In the To field, enter the name of the person from whom you want more

information.
This can be the original requester or any other person, but it must be that
persons exact AR System login ID.
b In the Question field, enter a description of the information you need.
Figure 3-4: Creating a More Information request

46

BMC Remedy Approval Server Guide

Processing More Information requests

c Click Save.

The More Information form closes, and the pending More Information request
appears temporarily in the More Information Requests table on the AP:Dtl-SigMoreInfoDialog form.
d Click Close.

AR System forwards the request to the person from whom you requested more
information. The original approval request is removed from your list of pending
approval requests in Approval Central until the recipient has responded to the
More Information request.

Viewing and responding to More Information requests


Use the following procedure to display and respond to the More Information
requests directed to you for an approval.

To view and respond to More Information requests to you


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


By default, the Pending Approvals table displays requests with the Pending, Hold,
and More Information, status.
2 To view requests with the More Information status only, in the Approval Tasks

section, click Needs Attention.


3 The Needs Attention Approvals table displays the list of More Information

requests that are awaiting your attention; select a request to view its details.
4 In the Approval Request Summary section, click Response.

The AP:More Information form opens in Modify mode, and More Information
requests directed to you are listed in the results table included on the form.
5 Select the request you want to respond to from the results list.

The details area of the form changes to show details of the selected More
Information request.
6 Type your answer in the Response field, and click Save.

The status of the More Information request automatically changes to Completed.


The request no longer appears in the More Information Requests table after the
search is refreshed. The approval server routes the response back to the More
Information requester.

NOTE
By default, the Public group does not have change permission to the Response field
of the AP:More Information form. The AR System administrator must set the
correct permissions on this field to allow the appropriate groups to respond to
More Information requests.

Chapter 3

Processing approval requests

47

BMC Remedy Action Request System 7.6.04

Figure 3-5: Viewing and responding to More Information requests

Viewing pending More Information requests and responses


When you submit a More Information request, the status of the related approval
request changes to More Information. When the recipient responds to the More
Information request, the status of the related approval request changes back to
Pending.

To view a More Information response


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 Select the appropriate request from the Pending Approvals table, and click View

Details.
3 On the AP:Show-Detail form, open the Activity Log tab.
4 Click the row pertaining to your Question or Comment.

The response is visible in the appropriate field of the Activity Log Details section.
You can access More Information requests that you have submitted by finding the
related approval request in Approval Central, and clicking the Manage More
Information button in the details view to access the related More Information
request.

NOTE
The Manage More Information control is not provided out-of-the-box with the
approval server; it is only included in the sample applications. To use this control
with a customized application, you must add it to the relevant three-way join form.

48

BMC Remedy Approval Server Guide

Processing More Information requests

To view a pending More Information request


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


By default, the Pending Approvals table displays a predefined number of requests,
including those in the Pending, More Information, and Hold states.
2 To view More Information requests only, click the Needs Attention link in the

Approval Tasks panel.


This action also displays only a predefined number of requests at a time.
3 To view the complete list of More Information requests awaiting your attention,

perform a search as follows:


a More In the Action Menu section, click Search My Approvals.
b In the Approval Search section, select More Information in the Status field, and

click Search.
The Approval Search Result table displays the requests for which the status is
More Information.
4 In the Approval Search Result table, select a request and click View Details.
5 On the AP:Show-Detail form, open the Activity Log tab.
6 Click the row pertaining to your Question or Comment.

The Activity Log Details section displays the corresponding details.

Viewing all More Information requests you submitted


You can search the AP:More Information form to find and view all More
Information requests you have sent, regardless of the request status.

To retrieve all your More Information requests


1 In BMC Remedy User or a browser, open the AP:More Information form.
2 Enter your AR System user name in the From field, and click Search.

A list of the More Information requests you have sent appears in the results list
area. This includes both pending and completed More Information requests.
3 Select a request from the results list.

The details of the request appear in the details area of the window, as shown in
Figure 3-6.

Chapter 3

Processing approval requests

49

BMC Remedy Action Request System 7.6.04

Figure 3-6: Displaying More Information requests you have sent

Using alternate approvers


Alternate approvers are approvers who serve in your place if you are unavailable.
You can designate your own alternates, or the process administrator can designate
them for you. You can also serve as an alternate for another approver.

Designating alternate approvers for yourself


You can designate one person to act as an alternate for all approval processes, or
you can specify separate alternates for each approval process. You also specify the
time period for which the alternate can grant approvals for each process.

NOTE
If your alternate designates an alternate, authority to sign your approvals is not
passed on. Only the specific person you designate can act as your alternate.

50

BMC Remedy Approval Server Guide

Using alternate approvers

Use the procedure in this section to create an alternate approver for yourself. If you
want multiple alternates, repeat this procedure for each alternate, as shown in
Figure 3-7.
Figure 3-7: Creating an alternate approver

To designate alternate approvers


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Action Menu section, click My Alternate Approvers.

The AP:Alternate form opens in New mode.


3 In the Alternate field, enter the AR System login name of the person to designate

as your alternate.
4 Use the Start Date and End Date fields to specify the time frame in which you want

the alternate to act on your behalf.


5 In the Covering field, select either of the following options:

AllTo authorize the alternate to approve all processes for which you have
signature authority.

SpecificTo authorize the alternate to approve a specific process. Then select a


process from the Process list.

6 In the Notify Alternate field, select Yes to send notifications to the alternate for

each new approval, or No to prevent notifications to the alternate.


7 Click Save.

NOTE
A time lapse of up to 60 minutes past the defined End Date might occur before an
alternate loses the alternate privileges. For performance reasons, this interval is set
to 60 minutes in the approval server.

Chapter 3

Processing approval requests

51

BMC Remedy Action Request System 7.6.04

Viewing and modifying alternate approver definitions


Use the procedures in this section to view or modify existing information about an
alternate approver.

To view and modify the record for an alternate approver


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Action Menu section, click My Alternate Approvers.

The AP:Alternate form opens in New mode.


3 Click New Search to change to Search mode, and click Search.

The results list appears, containing a list of your past, current, and cancelled
alternates.
4 To see details, select the record you want to view; the record details appear in the

details pane.
5 Modify the fields you want to change.
6 If you want to cancel this approver, select Cancelled from the Status field.
7 Click Save to save your changes, or Close to close the record without any changes.

NOTE
Your administrator might need to modify the permissions on the fields in the
AP:Alternate form to allow submitters to make changes to requests in the form.

Viewing requests for which you are an alternate approver


If you are acting as an alternate approver, you have the same signature authority
as the approver for whom you are serving. Your authority as an alternate approver
exists for a specific time period, and for the designated approval processes.
By default, Approval Central displays requests assigned to other approvers for
whom you are designated as an alternate approver. You can identify such requests
by looking at the Acting As column in the approval requests table. The requests for
which there is no value in the Acting As column, are directly assigned to you.
Figure 3-8 on page 53 depicts the Approval Central view of Violet Anderson,
whom Jack Miller and Larry Goldstein designated as an alternate approver for a
certain period. Approval Central displays only a predefined number of requests at
a time. To view all requests on which you can act as an alternate approver, perform
a search as described in the following procedure.

52

BMC Remedy Approval Server Guide

Using alternate approvers

Figure 3-8: Acting as an alternate approver

To view all requests for which you are an alternate approver


1 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


2 In the Action Menu section, click Search My Approvals.
3 In the Approval Search section:

In the Acting As field, select Alternate.

In the User field, type the AR System user name of the person for whom you are
acting as the alternate.

In the Application field, select the appropriate application if necessary.

In the Process field, select the appropriate process if necessary.

Verify that the Status field is set to Pending.

Click Search.

The resulting requests are those on which you can act as an alternate approver, not
those that are directly assigned to you.

Chapter 3

Processing approval requests

53

BMC Remedy Action Request System 7.6.04

Defining alternates for other approvers


Process administrators can define alternates for other approvers within any
process for which the process administrator has Full Admin authority.

To define alternates for other approvers


1 Open the AP:Alternate form in New mode.
2 Create an alternate as described in Designating alternate approvers for yourself

on page 50.
3 In the For field, replace your user name with the AR System user name of the

person this alternate will be substituting for.


4 Click Save.

Performing overrides
The override capability of the approval server allows a process administrator to
move an approval process forward when the normal approver has not responded.
An override is useful in an unexpected situation, such as when the normal
approver is unavailable but did not designate an alternate.
A single-signature override closes one approver signature, similar to acting as an
alternate approver for one signature line, and allows the approval request to
continue within the regular process. In this case, an override rejection terminates
the request just as if the normal approver had rejected it. An override approval
moves the request forward just as if the normal approver had approved it. If more
approvers exist, the request is routed to them.
A global override closes all open signatures, stops routing the request, and
terminates the approval process for that request. The global override is useful for
unusual situations, such as ending an approval process for a request that is no
longer necessary.
A process administrator can assign override-only authority to any user without
granting other approval process administrator privileges. For more information,
see Configuring process administrator capabilities on page 26.

54

BMC Remedy Approval Server Guide

Performing overrides

Performing an override to a single signature


If you have override capability for an approval process, you perform the same
steps to approve or reject the request as the original approver; however, you must
specify that you are performing an override.

To perform an override to a single signature


1 Log in to AR System as the process administrator for the process you need to

override (such as the process administrator or AR System administrator).


2 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


3 In the Action Menu section, click Search My Approvals.
4 In the Approval Search section:

In the Acting As field, select Override.

In the User field, enter the AR System user name of the user whose pending
approvals you want to access.

In the Application field, select the appropriate application if necessary.

Click Search.

The Approval Search Result table displays all pending requests for the specified
user. You can now approve or reject these requests with override authority.

Performing a global override


If you have global override capability, you perform the same steps to approve or
reject the request as the original approver; however, you must specify that you are
performing a global override.

To perform global overrides


1 Log in to AR System as the process administrator for the process you need to

override (such as the process administrator or AR System administrator).


2 Open Approval Central by using one of the methods described in Opening

Approval Central on page 37.


3 In the Action Menu section, click Search My Approvals.
4 In the Approval Search section:

In the Acting As field, select Global Override.

In the Application field, select the appropriate application if necessary.

Click Search.

The Approval Search Result table displays all pending requests for the application
selected. You can now approve or reject these requests with override authority.

Chapter 3

Processing approval requests

55

BMC Remedy Action Request System 7.6.04

56

BMC Remedy Approval Server Guide

Chapter

Using the Get Agreement


sample application
This section demonstrates how to perform basic approval functions by using Get
Agreement, one of the sample applications bundled with BMC Remedy Approval
Server (approval server). The Get Agreement application demonstrates how
requesters and approvers work with approval and More Information requests in
an Ad Hoc approval process.
The following topics are provided:

Overview of the Get Agreement application (page 58)


Accessing Approval Central (page 58)
Creating new approval requests (page 59)
Approving approval requests (page 60)
Reassigning approval requests (page 61)
Requesting more information (page 62)
Approval Status and More Information requests (page 63)
Responding to More Information requests (page 63)
Viewing responses to More Information requests (page 65)
Checking status of requests (page 66)

Chapter 4

Using the Get Agreement sample application

57

BMC Remedy Action Request System 7.6.04

Overview of the Get Agreement application


If you installed the approval server sample applications, you can use them to
understand and test the approval server functionality. The Get Agreement sample
application demonstrates an Ad Hoc process, in which the requesters and
approvers choose who should approve the request. For more information about
the Ad Hoc process type, see Ad Hoc process on page 78.
The procedures in this section use a set of sample users: Frank Williams, Jack
Miller, Larry Goldstein, Violet Anderson, and Sue Smith. To follow the sample
application procedures using these names, the AR System administrator must
create the AR System user names, and they must be issued either floating or fixed
write licenses. Because this is an Ad Hoc process, you can also substitute licensed
user names that already exist on your system when you try these procedures.
In the sample procedures, Frank Williams (the requester) requests a new
computer. The approvers use Approval Central to approve or reject the approval
request, and to reassign an approval request to another approver. The sample
users also send and respond to More Information requests.
The sample application demonstrates the use of Approval Central, an application
request form (in this case, AP-Sample2:Get Agreement), and related forms, such as
the three-way join form (AP-Sample2:Issue Detail Signat) and AP:More
Information forms. It also demonstrates how to display the status of an approval
request and how to identify the actions taken by each approver.

NOTE
The Questions, Comments with attachments, Notes, and Multi-process preview
features are available out-of-the-box with this sample application. For more
information, see AP:Show-Detail on page 271.

Accessing Approval Central


Most of the procedures in this section require that you start by opening Approval
Central. To do so, use the Approval Central link on the AR System Home Page, or
open the Approval Central form in a browser or in BMC Remedy User.
See Opening Approval Central on page 37.

58

BMC Remedy Approval Server Guide

Creating new approval requests

Creating new approval requests


In this section, you use the sample application to start the approval process by
creating a new approval request.

To create a new approval request


1 Log in to the appropriate AR System server as the sample user Frank Williams.
2 In a browser, open AP-Sample2:Get Agreement in New mode using the URL:
http://hostName/arsys/forms/serverName/AP-Sample2:Get Agreement
hostName is the name of the web server where BMC Remedy Mid Tier is running,
and serverName is the name of the AR System server where the approval server is

running.

NOTE
In this sample application, the Get Agreement form is the application request form.
Figure 4-1: The Get Agreement form in New mode

3 Type I need a new computer in the Summary field.


Chapter 4

Using the Get Agreement sample application

59

BMC Remedy Action Request System 7.6.04

4 Type a longer description in the Details field (optional).


5 In the Initial Approvers field, type
Jack Miller; Larry Goldstein; Violet Anderson

Since this is an Ad Hoc process, you must enter at least one approver. In case of
multiple approvers, separate the names with semicolons.
6 Click Save to save the request and begin the approval process.

Approving approval requests


This section demonstrates how an approver responds to a request. It requires that
you followed Creating new approval requests on page 59.

To approve an approval request


1 Log in to AR System as the sample user Jack Miller and open Approval Central.

By default, the Pending Approvals table shows requests with the Pending, Hold,
or More Information status for the current user. Because Jack Miller was included
in the list of approvers, the I need a new computer request appears in the table.
Figure 4-2: Pending requests for Jack Miller on Approval Central

2 In the Pending Approvals table, select the appropriate request.


3 Click Approve.

After approving, Franks request no longer appears in the list of pending Get
Agreement approvals for Jack Miller.

60

BMC Remedy Approval Server Guide

Reassigning approval requests

Reassigning approval requests


This section shows how an approver can transfer an approval request to another
approver without otherwise responding to the request. It requires that you
followed Creating new approval requests on page 59.

NOTE
The process specifies whether or not a request can be reassigned.

To reassign an approval request


1 Log in to AR System as the sample user Violet Anderson, and open Approval

Central.
2 From the Pending Approvals table, select the request I need a new computer.
3 In the Approval Request Summary section, click the Reassign button.
4 If prompted, enter your AR System password.
Figure 4-3: Violet Anderson reassigns Frank Williams request to Sue Smith

5 In the AP:Reassign dialog box, type Sue Smith, and click OK.
6 After returning to Approval Central, click Search to refresh the list of pending

approval requests.
The reassigned request disappears from the Approval Requests table.

Chapter 4

Using the Get Agreement sample application

61

BMC Remedy Action Request System 7.6.04

Requesting more information


This section demonstrates how to seek more information about approval requests.
It requires that you followed Creating new approval requests on page 59 and
Approving approval requests on page 60.
To request more information about an approval request, you can create a separate
More Information request. The AP:More Information stores the More Information
request, and allows approvers to ask questions and have them answered before
acting on an approval request.

To create a More Information request


1 Log in to AR System as the sample user Larry Goldstein and open Approval

Central.
2 Select the I need a new computer request from the Approval Requests table, and

click View Details.


3 On AP:Show-Detail, open the Activity Log tab and click Add.
Figure 4-4: Larry Goldstein asks Violet Anderson a question about Frank Williams request

62

BMC Remedy Approval Server Guide

Approval Status and More Information requests

4 In the Activity Log Details panel, perform the following steps:


a In the Type field, select Question.
b In the Question To field, specify the login name of the person from whom you

need more information.


c In the Question field, enter appropriate text.
d Click Save.

An entry is added to the Activity Log table.


5 Click Close.

Approval Status and More Information


requests
After you send a More Information request, the Approval Status of the related
approval request changes from Pending to More Information. If your Approval
Status field in the Search Criteria area of Approval Central is set to Pending (the
default), the approval request is removed from the approval requests table when
you send a More Information request. However, you can still find and open the
approval request by changing the Approval Status to More Information in the
Search Criteria area, and clicking Search. To see More Information requests
assigned to them, approvers can click the Pending Approvals, Past Due, or Due
Soon link on Approval Central.

NOTE
Larry could approve or reject the approval request without waiting for Violets
response to the More Information request. If he does so, Larrys More Information
request will be closed when Franks approval request is done (all approvers have
responded), regardless of whether Violet has seen the More Information request.

Responding to More Information requests


This section demonstrates responding to a More Information request. It requires
that you followed Creating new approval requests on page 59 and Requesting
more information on page 62 in that order.

To respond to a More Information request


1 Log in to AR System as the sample user Violet Anderson, and open Approval

Central.
2 In the Approval Tasks panel, click the Needs Attention link.

Chapter 4

Using the Get Agreement sample application

63

BMC Remedy Action Request System 7.6.04

3 Select the I need a new computer request, and click Response.


4 In the AP:More Information form, enter the appropriate text in the Response field,

and click Save.


The AP:More Information form closes. The More Information request is no longer
visible to Violet after she responds to it. Also, after Violet responds to the More
Information request, the Approval Status of the request changes back to Pending.
Figure 4-5: Violet Anderson responds to Larry Goldsteins question

NOTE
To save an entry in the Response field of AP:More Information, the user must be a
member of a group with Change permission to the field. The AR System
administrator might need to set the appropriate group-based permissions on the
Response field. For information about changing field permissions, see the Form
and Application Objects Guide, Field permissions, page 32.

64

BMC Remedy Approval Server Guide

Viewing responses to More Information requests

Viewing responses to More Information


requests
This section describes how to view the response to a More Information request that
you created. It requires that you followed Creating new approval requests on
page 59, Requesting more information on page 62, and Responding to More
Information requests on page 63.

To view the response to a More Information request


1 Log in to AR System as the sample user Larry Goldstein, and open Approval

Central.
2 Select the approval request for which you sent a More Information request, and

click View Details.

NOTE
Until the recipient responds to the More Information request, the Approval Status
of the associated approval request is More Information, rather than Pending. If you
do not see the approval request you are looking for in the approval requests table
on Approval Central, click the Search My Approvals link in the Action Menu panel
and search for More Information requests.
3 On AP:Show-Detail, open the Activity Log tab.
4 In the activity log table, select the appropriate entry.

If your question has been answered, the answer will appear in the Response field
in the Activity Log Details panel.
Figure 4-6: Larry Goldstein views Violet Andersons response to his question

TIP
Optionally, to see the response in the AP:More Information form, click Needs
Attention on Approval Central, select the appropriate request, and click View.

Chapter 4

Using the Get Agreement sample application

65

BMC Remedy Action Request System 7.6.04

Checking status of requests


This section shows how to verify the status of an approval request that you created.
It requires that you have followed Creating new approval requests on page 59.
Before trying you check the status of Frank Williams request, perform the
following procedures (see Approving approval requests on page 60):
Step 1 Log in to AR System as Larry Goldstein, and approve the I need a new computer

request.
Step 2 Log in to AR System as Jack Miller, and approve the I need a new computer

request.

To check the status of an approval request you have sent


1 Log in to AR System as Frank Williams, open the AP-Sample2:Get Agreement

form in Search mode, and click Search.


2 In the results list that appears, select Franks request for the new computer.

The current status of the approval request appears in the Status field. If all three
approvers have approved the request for a new computer, the status of the request
(in the detail area of the window) is now Approved. If any of the approvers have
not responded to the approval request, the status of the request remains Pending.

66

BMC Remedy Approval Server Guide

Checking status of requests

Figure 4-7: Franks approval request in the Get Agreement application request form

3 To determine which approvers have responded to the approval request, click

Show Approver Signatures.


The detail-signature form opens in Search mode, with a results list that contains
one entry for each approver on the request. In this results list, the Approval Status
column shows the status of the request for each approver.

Chapter 4

Using the Get Agreement sample application

67

BMC Remedy Action Request System 7.6.04

Figure 4-8: Viewing the status for each approver in the Get Agreement application

4 To determine which approver is associated with each status, select an entry from

the results list.


The approvers name appears in the Approvers field, in the detail area of the
window. In the example shown in Figure 4-8 on page 68, Frank can see that this
request is Pending for Violet Anderson.

68

BMC Remedy Approval Server Guide

Chapter

Introduction to approval
forms, processes, and rules
This section introduces the concepts that process administrators must understand
to configure and maintain approval processes for BMC Remedy Approval Server
(approval server).
The following topics are provided:

Approval server data and forms (page 70)


Approval processes (page 72)
Approval server rules (page 82)
Approver fields (page 94)

Chapter 5

Introduction to approval forms, processes, and rules

69

BMC Remedy Action Request System 7.6.04

Approval server data and forms


The approval server uses data created by the process administrator and data
generated during the approval process to carry out each approval process. This
section describes both types of approval server data.

Approval data and audit


As an approval request is routed through the approval process workflow, the
approval server collects data about the request in the request form and in the
approval server supporting forms. Some of this data is temporary, for use only
during the process, while other data, such as signatures, is saved for audit
purposes.
Because approval server processes are designed to implement business processes
and rules, you can use the approval server data as an audit trail for any process that
uses the approval server. The approval server collects the following data:

The original request

Electronic signatures of every person who approves or rejects a request

More information requests and their responses

Dates and times for each approval activity

You can also use approval server logging to record data about all requests and
responses, as well as to track the approval server configuration changes made by
the process administrator or AR System administrator. For information about how
to turn on approval server logging, see Configuring server settings on page 27.

Approval server supporting forms


A set of standard forms and related workflow objects is installed along with the
approval server. Most approval server objects are named with the prefix AP, and
sample application objects are named with either AP-Sample or AP-Sample2.
Approval server forms are described in more detail in Chapter 9, Adding
approvals to your application and Appendix D, Approval forms. This section
introduces some of the basic forms for ease of reference.

Approval Central
See Approval Central on page 36.

Detail form
All data about an approval request are stored in the AP:Detail form. You can use
this form to determine the status of a request, and to see a history of activity on the
request for any approval process.

70

BMC Remedy Approval Server Guide

Approval server data and forms

Signature form
All data about signatures associated with an approval request is stored in the
AP:Signature form. Administrators can use this form to review the responses to a
request.

NOTE
Modify signatures only through Approval Central.

Detail-Signature form
The AP:Detail-Signature join form joins data from the AP:Detail and AP:Signature
forms. You link this form to your applications approval request form to create a
three-way join form when you add approvals to your application.

Approval request form


Any application that uses the approval server must have an approval request form
that users open to enter their approval requests.
For example, in the sample applications, the application request forms are APSample2:Get Agreement and AP-Sample:Lunch Scheduler.

Three-way join form


When you link your application to the approval server, you must create an inner
join form by linking your application request form to the AP:Detail-Signature
form. Because the AP:Detail-Signature form is also a join form, this join is referred
to as a three-way join.
For example, in the Get Agreement sample application the three-way join form is
AP-Sample2:Issue Detail Signat. It joins AP-Sample2:Get Agreement with
AP:Detail-Signature.
See Creating the join forms on page 153. For general information about join
forms, see the Form and Application Objects Guide, Join forms, page 148.

NOTE
If you change the status of a request from an applications three-way join form, the
change is not reflected immediately on Approval Central. Users must click on any
link on Approval Central or refresh the page to see the change. To make such a
change visible automatically, application developers must provide workflow that
sends the refresh event to the Approval Central form on the Modify or Close event
of the three-way join form. Without such workflow, the Approval Central form
cannot know about changes to a request, because the status change activity does
not occur on the form.

Chapter 5

Introduction to approval forms, processes, and rules

71

BMC Remedy Action Request System 7.6.04

More Information form


The AP:More Information form stores and displays More Information requests
and responses that pertain to the related approval request form.

Signature authority form


For Parent-Child and Level process types, you create a signature authority form to
define the relationships between approvers or levels.
For example, the Lunch Scheduler sample application uses the
AP-Sample:Signature Authority form.
See Approval process types on page 75.

Application Pending form


The Application Pending form stores commands from any Application-Command
process. Whenever an Application-Command process runs, AR System creates a
request in this form containing details about the command. The Application
Dispatcher retrieves commands from this form and passes them to the approval
server for processing. If the Application Dispatcher is not in use, the approval
server retrieves commands directly from this form.

Approval processes
An approval process is the routing of an approval request through a defined series
of steps until the process is done. The approval process requires signatures and is
governed by the approval server rules and behavior. You can use the approval
server to automate any business process, and you can customize the process to
implement the operational guidelines of your organization. By using the approval
server, you can make sure that any process follows well-defined rules, that the
right people are notified and the proper signatures are obtained, and that you can
provide an audit trail of requests and the decisions made by approvers.

Difference between processes and rules


Understanding the difference between an approval process and the rules it uses is
critical to implementing a business process with the approval server.

72

An approval process defines the routing of any item that requires signatures. An
approval process can consist of many operations, transitions, and decision
points, each contributing toward a defined destination. The approval process
ensures that all the necessary steps take place to implement a business operation
that requires signatures or approvals, such as approving new hires or signing
purchase orders. In each case, the overall process is the same each time it is
performed.

BMC Remedy Approval Server Guide

Approval processes

The approval server provides four types of processes. See Approval process
types on page 75.

Approval rules augment the standard behavior of the approval server, and
govern how an approval request is handled at various stages of the approval
process. You use rules to retrieve and save approval data and to make decisions
during the process, such as who the next approver is, whether more signatures
are needed, and whether the routing process is complete.
The approval server provides 13 types of approval rules. See Approval server
rules on page 82.

Approval process stages


The approval process ensures that all the necessary steps take place to complete
any approval, while rules govern how the request is handled at various stages of
the process.
Figure 5-1 illustrates the five stages of any approval process. The approval server
checks for rules belonging to each stage during the approval process. Any given
approval process does not require rules in all five stages, but most approval
processes include rules in at least the approver response and Process Done stages.
Depending on the process design and the rules used, the approval cycle can
include several iterations of the next approver, approver response, and
Completion Check stages.
Figure 5-1: Approval process stages
Submit
Request

Requester

Requester

1
Self Check

Another
Approver

Requester
not approved

More Information
Request (optional)

Requester
approved

Yes

No
Process
Done

Approver
Response

Next
Approver

More
approvers?

Someone
Entirely
Arbitrary

Approval
Cycle

4
Completion
Check

Approved
Rejected

Chapter 5

Introduction to approval forms, processes, and rules

73

BMC Remedy Action Request System 7.6.04

An approval process starts when someone submits an approval request.

Stage 1, Self CheckIf the process includes either Auto Approval or Self
Approval rules, the approval server immediately performs them to determine
whether the requester has sufficient authority to approve his or her own request.
If so, the approval process is done and the approved workflow is returned to the
requester.

Stage 2, Next Approver (routing)If no Auto Approval or Self Approval rules


are included in the process, or if the Self Check stage determines that the request
must be routed to an approver, the Next Approver stage begins. For most
process types, the approval server uses one or more next approver rules to start
a cycle of identifying people who need to approve the request. (The exception to
this is the Ad Hoc process type, as explained in Approval process types on
page 75.) The Next Approver stage is repeated during the approval cycle until
all approvers have received the request.

Stage 3, Approver ResponseIn this stage of the process, approvers either


approve or reject an approval request. This action completes the signature line
for that approver. If an approver approves the request, the approval process
continues. If an approver rejects the request, the approval process is usually
done. (You can override this behavior with Signature Accumulator and
Statistical Override rules).
The Approver Response stage is repeated as necessary, and is closely integrated
with the Completion Check stage.

Stage 4, Completion CheckThe Completion Check stage accepts the results of


the Approver Response stage, and checks to see if the routing of a request is
complete. Routing is complete if all required approvers have received the
request, whether they have responded. If all required approvers have not
received the request, the process returns to the Next Approver stage.
The Completion Check stage is repeated as necessary until the Completion
Check passes.

Stage 5, Process DoneThe approval process is done when the request is


approved by all (or enough) required approvers, or when it is rejected. It is also
done if an error state is recorded or if the request is cancelled. During this stage,
the approval server determines whether the approval was successful, and takes
appropriate action, such as delivering a notification of the completed request to
the requester.

NOTE
The difference between complete and done is important. When a request is
complete, it has been routed to all approvers. Even when routing is complete, all
required approvers have not necessarily responded. The request is done when all
required approvers have approved or rejected the request.

74

BMC Remedy Approval Server Guide

Approval processes

Approval process types


The approval server provides four process types that you can choose from when
designing an approval process. These process types differ in how the approval
server identifies the next approver. They are known as Parent-Child, Level, Ad
Hoc, and Rule-Based. Each is introduced in this section.
For an example of each process type, examine the sample applications installed
with the approval server. For information about how to create, modify, and delete
processes, see Chapter 6, Defining an approval process. For information about
rules and how they are used with each process type, see Approval server rules
on page 82. For information about creating rules, see Chapter 7, Defining
approval rules.

Parent-Child process
The Parent-Child process type uses the relationships between requesters and
approvers, and between approvers and other approvers, in conjunction with a Get
Next Approver rule, to determine the routing of an approval request. You define
these relationships in a signature authority form.
The Management Cost Authorization process in the Lunch Scheduler sample
application is an example of a Parent-Child rule. It uses the Manager Login Name
field on the AP-Sample:Signature Authority form to define the parent login
name of each sample user.
In a process where each approver has a defined relationship to the next approver,
such as employee to manager and manager to director, the most appropriate
process type is usually Parent-Child. In this type of process, the approval request
is routed up an approval hierarchy from the child (requester or previous
approver with lower authority) to the parent (approver with higher authority).
A manager-employee relationship is often the hierarchy represented with a
Parent-Child approval process.

Chapter 5

Introduction to approval forms, processes, and rules

75

BMC Remedy Action Request System 7.6.04

Example of a Parent-Child process


Figure 5-2 illustrates an example Parent-Child process, in which an engineering
change must be approved by a hierarchy of approvers.
Figure 5-2: Parent-Child hierarchy

In a Parent-Child process, the approval server automatically routes the request to


the next approver according to the defined relationship. Persons represented by
X in the diagram do not receive the approval request because they do not have
parent relationships with the requester or any approvers.
A rejection from any approver rejects the request for everyone in the hierarchy.
This is also true if the process uses two or more separate approval hierarchies.
Process administrators can configure notifications to inform all approvers when
any other approver has rejected a request.
The following considerations apply to a Parent-Child process:

76

A Parent-Child process requires a Get Next Approver rule that defines how to
find the next approver. This rule must include the name of the field containing
the identity of the parent and must return the Approver List, which is a string of
individuals or roles. See Defining Get Next Approver rules on page 121.

When an approver marks an approval request as approved, the approval server


automatically checks for the parent of that approver and, if one is found,
routes the request to that person.

When it generates the first Approver List for a Parent-Child process, the
approval server assumes that the previous approver is the originator of the
approval request (the requester). This means that the parent of the requester
becomes the first approver.

BMC Remedy Approval Server Guide

Approval processes

Level process
The Level process type uses a hierarchical set of organizational levels, in
conjunction with a Get Next Approver rule, to determine the routing of an
approval request. The process administrator defines the organizational levels and
their members in a signature authority form.
The Major Account Level Approval process in the Lunch Scheduler sample
application is an example of a Level process. It uses the Account Approval Level
field of the AP-Sample:Signature Authority form to define organizational levels
and the sample users who belong to them.
If anyone in a certain organizational position, such as a job level, can approve a
request, the Level process type is often the best fit. In a Level process, the approval
server delivers the request to all approvers in the next level. When the defined
number of approvers in any level have approved the request, the approval server
routes the request to the next level.

Example of a Level process


Figure 5-3 illustrates a request for a soft drink machine in a company courtyard,
which must be approved by the refreshment, landscape, and maintenance
committees. The Level process defines the order in which the committees see the
request.
Figure 5-3: Level process with three levels

In a Level process, a request must be approved by at least one approver in each


level before it passes to the next level. The approvers for a given level can consist
of individuals or roles. A Level process does not dictate the number of approvers
on each level. You can set up routing to the next level to require signatures from
any number of individuals in each level. For information about configuring roles,
see Defining roles on page 106.
A Level process uses a level value to indicate the position of individuals or roles.
The approval server uses the value in the level field to determine an approval
sequence, starting with level 0. The highest level is 1000. The approval server skips
over unused levels.

Chapter 5

Introduction to approval forms, processes, and rules

77

BMC Remedy Action Request System 7.6.04

The following considerations apply to a Level process:

A Level process requires a Get Next Approver rule that defines how to find the
next approver. This rule must identify the name of the field containing the level
identifier, and must return two values: a level indicator, and a string of
individuals or roles. See Defining Get Next Approver rules on page 121.

The process rules must be configured to determine whether a request should be


routed to more than one person in each level.

Ad Hoc process
In an Ad Hoc process, no Get Next Approver rule is used, and the process
administrator does not define approver or organizational relationships. Instead,
the requester and the approvers designate the next approver or a set of approvers
while working with the request. The requester enters at least one approver when
creating the request. Approvers can add additional approvers when they respond
to the request.
The Issue Approval process in the Get Agreement sample application is an
example of an Ad Hoc process.
Figure 5-4: Routing two requests in the same Ad Hoc process

NOTE
An Ad Hoc process is not the same as an ad hoc override. Ad hoc overrides allow
specific approvers to alter a predetermined routing. An Ad Hoc process includes
no predetermined routing. See Get next approver manually on page 86.

78

BMC Remedy Approval Server Guide

Approval processes

When entering approvers, users must enter the exact AR System login ID of the
next approver. To prevent typographical errors and allow the user to select from a
list, the AR System administrator should construct field menus containing the
appropriate approvers for an Ad Hoc process. See the Form and Application
Objects Guide, Creating menus, page 299.

Rule-Based process
The Parent-Child, Level, and Ad Hoc process types are partially preconfigured
and, therefore, are relatively simple to implement. A Rule-Based process is similar
to a Parent-Child process, except that a Rule-Based process relies on rules that you
create to define the relationships between approvers. This option enables you to
define a routing method that allows more complexity than predefined
relationships. However, a Rule-Based process requires more thought and work to
implement.
The Special Overdue Approval process in the Lunch Scheduler sample application
is an example of a Rule-Based process.

Summary of process types


The approval server handles approval requests with one of four process types.
Processes and their rules are configured by a process administrator.
Table 5-1: Summary of process types
Process type

Routing method

Determining next approver

Parent-Child

Hierarchy of individuals. The


process administrator defines
the relationships between
individuals.

Get Next Approver and Parameterized


Get Next Approver rules determine
the relationship of the next approver to
the current owner.

Level

Hierarchy of organizations. The Get Next Approver and Parameterized


process administrator defines
Get Next Approver rules determine
the levels and their members.
the next level and approvers.

Ad Hoc

Routing is based on the


approvers entered by the
requester or approvers.

Determined manually by users.

Rule-Based

Custom, as determined by the


Process Administrator.

Custom, as determined by the Process


Administrator. Parameterized Get
Next Approver rules can add
approvers.

Chapter 5

Introduction to approval forms, processes, and rules

79

BMC Remedy Action Request System 7.6.04

Signatures for multiple approvers


An approval request can be assigned to multiple approvers. Administrators can
specify how to manage responses to such a request at the process, rule, or role
level. Administrators use the If Multiple Approvers setting for this purpose.
The options are:

One Must SignThe approval server creates a single signature entry for all the
relevant approvers. Only one of the approvers needs to take action.

All Must SignThe approval server creates a separate signature entry for each
approver. All approvers must take action for the request to proceed further.

(Process-level only) Allow Only One ApproverThe approval server creates a


single signature entry for an approver. If a requester specifies multiple
approvers for a request, the approval server returns an error.

Action date for a process or signature


Each approval server process and signature can be associated with an action date.
The action date enables approvers to know in advance the duration within which
to take action on requests assigned to them. Process administrators can use this
value to determine whether a process is on track or needs intervention (automatic
or manual). This helps in addressing requests and driving them to completion in a
timely manner.
In BMC Remedy Approval Server 7.5.00, the action date is based on the Automatic
Action interval defined for a process. For more information, see the BMC Remedy
Action Request System 7.5.00: BMC Remedy Approval Server Guide.
Beginning with release 7.6.04, the action date is calculated by using the following
fields on the tabs of AP:Process Definition:

ConfigurationProcess Due, Signature Due, Buffer Period, and Enable Preview

Signature EscalationsAutomatic Action and Notification (First) intervals

Applications can override the Process Due interval by directly passing the desired
Process Due Date as a parameter of the New-Details command. For more
information, see New-Details on page 187.
The action dates for processes and signatures are stored in the following fields:

Process Due Date (ID 11000) on AP:Detail

Signature Due Date (ID 12000) on AP:Signature

NOTE
Using Enable Preview to determine the action date might increase the processing
time for a new request due to the steps required to retrieve the list of future
approvers.
When working with notifications and escalations, make sure that the appropriate
notification and escalation types on AP:Admin-ServerSettings are enabled.

80

BMC Remedy Approval Server Guide

Approval processes

How action date for a Parent-Child or Level process is


calculated
When the first signature is created for a request, the Process Due Date is either
derived from the Process Due period defined on AP:Process Definition, or set to
the value sent by the application through New-Details. If the application specifies
the Process Due Date value, the value in Process Due field is ignored.
If Enable Preview is set to Yes, the total number of approvals in the process is
calculated by fetching the future approvers with the help of the Preview feature.
The effective Signature Due period is calculated as follows:
signatureDue = (Process Due / totalNumberOfApprovals)

This value is then compared with the one specified in the Signature Due field, and
the minimum of the two is considered.
effectiveSigntaureDue = MIN (Signature Due, signatureDue)

If no value is entered in the Signature Due field, the derived signatureDue is used
for further computation.
The action date for a signature is calculated as follows:
Action Date = MIN (effectiveSignatureDue,
Automatic Action interval-Buffer Period,
Escalation interval-Buffer Period)

For more information, see Signature Escalations tabs on page 242.

How action date for an Ad Hoc process is calculated


When the first signature is created for a request, the Process Due Date is either
derived from the Process Due period defined on AP:Process Definition, or set to
the value sent by the application through New-Details. If the application specifies
the Process Due Date value, the value in Process Due field is ignored.
The value of Enable Preview is ignored, because the ad hoc nature of the process
makes it impossible to identify the future approvers.
The action date for a signature is calculated as follows:
Action Date = MIN (Signature Due,
Process Due date-Buffer Period,
Automatic Action interval-Buffer Period,
Escalation interval-Buffer Period)

For more information, see Signature Escalations tabs on page 242.

Chapter 5

Introduction to approval forms, processes, and rules

81

BMC Remedy Action Request System 7.6.04

Approval server rules


The approval server includes 13 rule types that are used in various stages of an
approval process. A given process does not usually include all types of rules, and
some do not include all five process stages. This section introduces the rule types
included with the approval server, and describes how they function in the
approval process.
Figure 5-5 illustrates how each rule type fits into the overall approval process.
Figure 5-5: Rule types in the approval process
2
Prep. Get
Next Approver

Get Next
Approver

Parameterized
Get Next
Approver

Ad hoc?
No
Yes

Invalid
Requester

Validate
Approver?

Valid
Submit Request
Signature
line error
Approver
Response

1
Auto Approval?

No

(Wait for)
Correction

Get
Authority
Yes

Yes

Signature
Accumulator

Get
Authority
Self

No

More
approvers?

Approval
Cycle
Self
approval?

5
Process
Done

Yes

Rejected
Statistical
Override

Yes

No
No

Approved
Outstanding
signatures?
Get Authority

Yes

4
No

Get Authority
Regular

Completion

Self Check stageRules that test for automatic approval and self
approval
The approval server uses the Self Check stage of an approval process to prevent
unnecessary routing. Rule types that you can use in the Self Check stage include:

82

Auto Approval

Get Authority or Get Authority Self

Self Approval

BMC Remedy Approval Server Guide

Approval server rules

The Auto Approval and Self Approval rule types use different methods to
determine whether the requester has sufficient authority to approve his or her own
request. The Get Authority and Get Authority Self rules gather data to be used by
the Self Approval rule.
Figure 5-6: Details of Self Check stage rules
Submit Request

Requester

1
Auto Approval?

Yes

No

Next
Approver

Approval
Cycle

Get
Authority
Self

Self
Approval?

Process
Done

Get
Authority

No

Yes

Auto Approval rules


The approval server first tests for an Auto Approval rule. Automatic approval
occurs when any user has authority to approve a given request, independent of the
users role in the organization or within the AR System. When an Auto Approval
rule condition is met, the request is done, and moves directly to the Process Done
stage. In Auto Approval rule, the rule condition contains the authority criteria,
which applies to all users.
For example, if an Auto Approval rule says that everyone in the company can be
reimbursed for a business lunch up to $40, and Frank requests approval for a $25
lunch, the Auto Approval condition is met and the approval server uses the Auto
Approval rule to automatically approve Franks request.
The Management Cost Authorization process of the Lunch Scheduler sample
application contains an example of an Auto Approval rule. To create an Auto
Approval rule, see Defining Auto Approval rules on page 114.

Self Approval rule


When a request fails the Auto Approval rule or no Auto Approval rule is present,
the approval server tests for a self approval condition. A Self Approval rule
executes only when the current user is the owner of the approval request. Its test
uses Get Authority or Get Authority Self rules together with Self Approval rules.
Chapter 5

Introduction to approval forms, processes, and rules

83

BMC Remedy Action Request System 7.6.04

Get Authority and Get Authority Self rules


These two rule types collect data, such as a monetary amount, that determines the
limits of the current approvers authority. The information collected by either the
Get Authority or Get Authority Self rule is used by any Self Approval rules that
exist in the process.
The difference between Get Authority and Get Authority Self rules is in when they
run during the approval process. The approval server runs Get Authority rules
during both the Self Check stage and the Completion Check stage of the approval
process. It runs Get Authority Self rules only in the Self Check stage. You
determine which rule type to use based on the data you need to gather in each
stage of the approval process.
You can use a combination of get authority rule types in a process that requires
more than one type of get authority check. For example, a companys business
rules might require one set of self approval levels for expenses (such as $100 for
regular employees, $200 for managers and above), but another set of approval
limits for major purchases (such as up to $5000 for managers and higher expenses
requiring three approvers including a Vice President). A process to support these
business rules would include two different signature authority forms. A Get
Authority Self rule would support the Self Approval rule, and a Get Authority rule
would support the Get Next Approver rules.
The Cost Get Approval Authority rule in the Lunch Scheduler sample application
is an example of a Get Authority rule. To create Get Authority rules, see Defining
all Get Authority rules on page 116.

NOTE
A third type of get authority rule, called Get Authority Regular, is performed only
during completion processing. See Get Authority and Get Authority Regular
rules on page 91.

Self Approval rules


Self Approval rules test data collected by the Get Authority or Get Authority Self
rules to determine whether the requester has sufficient authority to approve the
request. When a Self Approval rules conditions are met, the request is done.
The following is an example of a self approval rule: If Frank requests approval for
a $50 business lunch, the condition of the $40 Auto Approval rule is not met. In this
case, the Self Check stage continues with a Get Authority or Get Authority Self rule
to collect Franks employee status. The data gathered shows that Frank has
authority to approve lunches up to $100. The Self Approval rule uses this data to
test whether Frank has authority to approve his own $50 lunch.
The Cost Approve for Myself rule in the Lunch Scheduler sample application is an
example of a Self Approval rule. To create a Self Approval rule, see Defining Self
Approval rules on page 118.

84

BMC Remedy Approval Server Guide

Approval server rules

Next Approver stageRules that get the next approver


In the Next Approver stage, the approval server determines to whom the request
must be routed next and creates the appropriate electronic signature lines.
Depending on the process type and the rules it contains, the approval server can
automatically determine the next approver, or allow the current approver to select
the next approver. If the next approver is a role, more than one individual can be
eligible to sign one signature line. In this case, the first role member who responds
determines the outcome for that signature line. See Defining roles on page 106.
Rule types used in the Next Approver stage include:

Prep Get Next Approver

Get Next Approver

Parameterized Get Next Approver

Validate Approver

Get next approver automatically


To cause the approval server to determine the next approver, you use Prep Get
Next Approver and Get Next Approver rules.

Prep Get Next Approver rules


A Prep Get Next Approver rule gathers information to be used by Get Next
Approver rules. (In the rule name, prep is an abbreviation for prepare.) In
AR System workflow terms, Prep Get Next Approver rules use a Set Field action
to place values in certain fields. The Overdue Prep Get Next rule in the Lunch
Scheduler sample application is an example of a Prep Get Next Approver rule. To
create a Prep Get Next Approver rule, see Defining Prep Get Next Approver
rules on page 120.

Get Next Approver rules


Get Next Approver rules are the heart of approval processing. They route requests
to the next valid approver and create a signature line for each required approver.
When configuring an approval process, the process administrator defines a list of
valid approvers. Get Next Approver rules use this approver data to determine who
is next in the approver list and to create signature lines for each approver.
The sample applications contain the following examples of Get Next Approver
rules, in each type of process where these rules are used:

Cost Get Next Approver, in the Management Cost Authorization process (a


Parent-Child process)

Level Get Next Level, in the Major Account Level Approval process (a Level
process)

Overdue Assign Approvers, in the Special Overdue Approval process (a RuleBased process)

To create a Get Next Approver rule, see Defining Get Next Approver rules on
page 121.
Chapter 5

Introduction to approval forms, processes, and rules

85

BMC Remedy Action Request System 7.6.04

Get next approver manually


For some approval processes, it is appropriate to allow requesters or approvers to
specify the next approver, or to add an approver at another level. In this case, the
approval server identifies the next approver based on what the user enters.
Several situations allow approvers to designate additional approvers. These are:

An Ad Hoc process, which requires all approvers to be added by the users, as


described in Ad Hoc process on page 78.

An ad hoc override, in which you configure the process to allow approvers to


alter the predetermined routing. This is controlled by the Allow Ad Hoc Next
Approver? field on the Basic tab of the Process Definition form. See Creating a
process on page 98.

A Parameterized Get Next Approver rule, which works together with the
preview feature and an application command to pass run-time variables to the
approval server.

When the process allows users to add approvers, use a Validate Approver rule to
verify the added approver against a list of valid approvers.

Parameterized Get Next Approver rules


A Parameterized Get Next Approver rule enables approvers to add another
approver anywhere in the approval hierarchy (not necessarily the next approver)
at runtime. This rule type works together with the preview feature, and uses the
Add-PGNA-Values application command to provide variables to the approval
server. See Appendix B, Application commands.
The Parameterized Get Next Approver rule works exactly like a Get Next
Approver rule, with the following exceptions:

Run-time variables can be part of the qualification and Set Fields operations.

Approvers can be added to any level, not just the next level.

After any Get Next Approver rules are executed, the server executes all
Parameterized Get Next Approver rules. If a Parameterized Get Next Approver
rule exists, but the current record does not have any parameters, the rule is
skipped.
To create a Parameterized Get Next Approver rule, see Defining Parameterized
Get Next Approver rules on page 126.

Validate Approver rules


The approval server uses Validate Approver rules to protect against inappropriate
ad hoc assignments. If the test to validate the approver fails, the user assigning the
invalid approver receives an error and must correct it before the request can
proceed.
The Issue Validate Approvers rule in the Get Agreement sample application is an
example of Validate Approver rules. To create a Validate Approver rule, see
Defining Validate Approver rules on page 129.

86

BMC Remedy Approval Server Guide

Approval server rules

Figure 5-7 illustrates how rules and ad hoc approver entries are used in the Next
Approver stage of an approval process.
Figure 5-7: Get Next Approver rules

Prep. Get
Next Approver

Get Next
Approver

Parameterized
Get Next
Approver

Ad hoc?
No
Yes

Invalid

Validate
Approver?

Submit Request
Valid
Requester
Self Check

Not
approved

Signature
line error

(Wait for)
Correction

Approved

Approver
Response

Yes
Approved

More
approvers?

Approval
Cycle

No
Process
Done

Completion
Check
Rejected

NOTE
Process administrators should set up notifications to indicate when an erroneous
ad hoc selection is waiting for correction.

Approver Response stageRules that work with signatures


When a request enters the Approver Response stage of the approval process, the
Approval Status for the next approvers signature is Pending. The approver can
approve or reject the request, request more information, or place a request on hold.
When an approver responds in one of these ways, the signature line for that
approver is changed to Approved, Rejected, Hold, or More Information.

Chapter 5

Introduction to approval forms, processes, and rules

87

BMC Remedy Action Request System 7.6.04

The approval server sets the signature value automatically, depending on the
approvers response. You do not have to define a rule to implement this behavior.
By default, the approvers response determines whether the request passes into the
Completion Check stage, or remains in the Approver Response stage.

ApprovedWhen an approver approves a request, the request passes to the


Completion Check stage, where the approval server determines whether more
signatures are required. See Completion Check stageRules that test for
completion on page 91.

RejectedIf an approver rejects a request, the request moves to the Process


Done stage. No more routing occurs, and the request is withdrawn from
approvers who have placed the request on hold or requested more information.

HoldWhen an approver places a request on hold, the approval server changes


the signature line to Hold, but no other action occurs. Process administrators
should establish escalations to prevent requests in Hold status from being
neglected indefinitely.

More informationIf an approver requests more information, the approval


server changes the approval status to More Information, but no other action
occurs within the approval processing for that approver. The approval server
allows an approver to hold, approve, or reject a request without waiting for the
More Information response. When this occurs, the More Information request is
terminated.

You can override the default behavior of the approval server in this stage. To do
so, you use the following rule types:

Signature Accumulator

Statistical Override

Signature Accumulator and Statistical Override rules


Signature Accumulator and Statistical Override rules can use ratios between
approved and rejected signatures to determine the outcome of a process. These
rules preempt the usual routing to bring the approval process to a conclusion
based on statistics that you define. These two rule types are also known
collectively as statistical decision-making rules.
An example of a statistical decision making rule is: If more than 50% of the
approvers approve the request, then approve the process. With this rule in place,
if the approval request has a list of five approvers, and the first two approvers
reject the request, the remaining approvers are still given a chance to approve it. If
the last three approvers approve the request, the request is approved overall.
Signature Accumulator and Statistical Override rules run during the Approver
Response stage (whenever an approver responds to a request). If any Statistical
Override rules are defined, then the statistical decision-making approval process
begins. If no Statistical Override rules exist, the approval server follows its default
logic, and the request moves to the Completion Check or Process Done stage.

88

BMC Remedy Approval Server Guide

Approval server rules

Signature Accumulator rules


A Signature Accumulator rule collects statistical information about the signature
records associated with an approval process, for use in a Statistical Override rule.
You define the criteria for counting signatures.
In a Level process, only signatures associated with the current level are included
in the set. These are referred to as current signature records. In all other process
types, all signatures associated with the detail record are included in the set.
For each signature record, the approval server applies each existing Signature
Accumulator rule, provided the Run If qualification passes. For example, if the
approval server finds four signatures to check, the server runs all the Signature
Accumulator rules on the first signature, then on the second signature, and so on
until all the signatures are finished.
Examples of Signature Accumulator rules are included in the sample applications.
They are Issue Increment Signature Limit and Issue Retrieve Signature Limit, in
the Get Agreement Sample application. For information about using these
examples, see Example of decision-making rules in a sample application on
page 133. To create a Signature Accumulator rule, see Defining Signature
Accumulator rules on page 131.

Statistical Override rules


A Statistical Override rule preempts the default behavior of the approval process
and causes the process to be approved or rejected before all pending signatures
have been completed. To do so, the rules check whether the statistical conditions
required for making a decision have been satisfied.
Statistical Override rules can perform one of three actions: approve, reject, or do
nothing. If a Statistical Override rule approves or rejects a request, the request is
done and moves to the Process Done stage. If the conditions for approving or
rejecting are not met, the process continues the default behavior of checking for
more signatures to gather.
When the Statistical Override rule approves or rejects a request, the normal
approval process is preempted by performing the following actions:
Table 5-2: Process and signature considerations in the Statistical Override rule
Process type Signatures considered Approving requests
Level

Rejecting requests

Only signatures for


the current level

Preempts the approval server Preempts the approval server to reject


to proceed to the next level.
the request and stop the processing.

Parent-Child All signatures, at all


times

Preempts the approval server Preempts the approval server to reject


to proceed to proceed to next the request and stop the processing.
parent.

Ad Hoc

All signatures, at all


times

Preempts the approval server Preempts the approval server to reject


to approve the request.
the request and stop the processing.

Rule-Based

All signatures, at all


times

Preempts the approval server Preempts the approval server to reject


to proceed to the next set of
the request and stop the processing.
approvers.

Chapter 5

Introduction to approval forms, processes, and rules

89

BMC Remedy Action Request System 7.6.04

WARNING
If you define Statistical Override rules, you must also define a rule to approve or
reject the process if no pending signatures exist. If a rule is not defined to handle
this condition, the approval server considers this as an error condition.
Figure 5-8 illustrates how the approval server uses both types of statistical
decision-making rules in the Approver Response stage.
Figure 5-8: Statistical decision-making rules in Approver Response stage
Approver
Response
(Approval/
Rejection/
Cancellation)

Stat
Override
Rules?

No

Default
Logic

Yes

Signature
Accumulator

Statistical
Rules

Statistical
Override

Preempt?

No

Yes

No

Approve?

Yes

No

Cancel Active
Signatures

Reject

More
Signatures?

Error

Yes

Wait for more


Signatures

Default
Logic

Statistical Override rules evaluate the data gathered for the active signature record
by a Signature Accumulator rule or by the approval server. If the Statistical
Override rules can be based solely on the statistical data that the approval server
gathers by default, you do not need to define a Signature Accumulator rule.
The following statistical data is available by default:

90

Total Signatures

Total Approved

Total Rejected

Total Pending

BMC Remedy Approval Server Guide

Approval server rules

Total Hold

Total More Information

Total Canceled

Total Closed

Total Error

Examples of Statistical Override rules are included in the sample applications.


They are Issue Statistical Approval and Issue Statistical Boundary Condition in the
Get Agreement Sample application.
For information about using these examples, see Example of decision-making
rules in a sample application on page 133.
To create Statistical Override rules, see Defining Statistical Override rules on
page 132.

Completion Check stageRules that test for completion


The Completion Check stage of an approval process determines whether
conditions exist to stop routing a request to additional approvers. If a completion
check is successful, routing stops and no additional approvers will see the request.

Example of Completion rules


For example, when Jack approves a business expense for $100, a rule determines
whether Jack has sufficient authority to approve a request for that amount. If so,
the process passes the Completion Check stage. If not, the completion check fails
and the routing of this request continues to another approver.
Rule types used in the Completion Check stage include:

Get Authority

Get Authority Regular

Completion rule

Get Authority and Get Authority Regular rules


In the Completion Check stage, the approval server runs Get Authority or Get
Authority Regular rules to collect information. Get Authority rules are described
in Get Authority and Get Authority Self rules on page 84.
Like Get Authority rules, Get Authority Regular rules collect data that is used by
the Completion rule. The approval server runs Get Authority Regular rules only
during the Completion Check stage of an approval process.

Chapter 5

Introduction to approval forms, processes, and rules

91

BMC Remedy Action Request System 7.6.04

Completion rules
Completion rules test whether sufficient authorization exists to stop routing an
approval request. A process is complete when the approval server has routed the
request to all required approvers even if they have not yet all responded.

No CompletionIf the Completion rule condition is not met, the Get Next
Approver rules are performed and the request is routed to the next approver. If
no new approvers are found by the Get Next Approver rules, the approval
server checks the Approval Success field of the Process Definition form.

If this field is set to No More Approvers, the process is done with a status of
Approved.

If the Approval Success field is set to Completion Rule, the process is done
with an error state, because no more approvers exist and no Completion rule
has succeeded.

Successful CompletionIf the Completion rule condition is met, the request is


not routed to any further approvers. If outstanding signatures exist when the
routing Completion rules are fulfilled, the request remains active until either all
approvers approve or one rejects the request.

A process that requires a fixed number of signatures will complete successfully


when the process exhausts the Approver List. For example, you can create a
process that completes routing when any five approvers respond, instead of
completing with one approver of a specific authority.

Examples of the routing completion check


The rules governing approval of a business lunch might be determined by the
amount of the request. If Frank requests approval of a $150 business lunch, and
Jack has authority to approve requests for $150 or less, the process passes the
completion check when Jack approves the request. If Jack does not have authority
to approve requests of $150, the approval process does not pass the completion
check when Jack approves it, and the process returns to the Get Next Approver
stage. In this example, the Completion rule uses data gathered by a Get Authority
rule to test for completion against a specific dollar amount.
Alternatively, the same request might require signatures from two steps up the
management hierarchy. When Franks manager and his managers manager have
approved the request, no more approvers are required, and the process is
complete. In this case, the Completion rule uses data gathered by a Get Authority
rule to test the approver relationships.
The Cost Completion and Level Completion rules in the Lunch Scheduler sample
application are further examples of Completion rules. For information about
creating a Completion rule, see Defining Completion rules on page 138.
Figure 5-9 illustrates how the approval server uses the Completion, Get Authority,
and Get Authority Regular rule types during the Completion Check stage.

92

BMC Remedy Approval Server Guide

Approval server rules

Figure 5-9: Completion Check stage of an approval process


Submit Request

Requester

Requester
not approved

Self Check

Next
Approver

Requester
approved

Approver
Response

Yes
No

Signature
Accumulator

More
approvers?

Approval
Cycle
No

Process
Done

Rejected
Statistical
Override?

Completion
Approved
Yes
No

Outstanding
signatures?

Yes
Get Authority

Get Authority
Regular

Process Done stage


A process is done when a request has generated a final result, such as Approved,
Rejected, Error, or Cancelled. Approval Process Done rules allow a process to take
action on the original request when the approval server is done handling the
request. For example, when a process is done, you use an Approval Process Done
rule to change the approval status on the approval request form. The only rule type
used to implement the Process Done stage is the Approval Process Done rule.
The sample applications contain many examples of Approval Process Done rules,
including, for example, Cost Approved, Cost Rejected, Issue Approved, and Issue
Rejected. To create an Approval Process Done rule, see Defining Approval
Process Done rules on page 139.

Chained processes
You can initiate a new approval process automatically when the first process is
done. For example, if a manager approves a new computer purchase, the IT
department can start another chained approval process that determines the exact
model of computer to buy. For a description of chained processes in the Lunch
Scheduler application, see Chaining approval processes on page 147.

Chapter 5

Introduction to approval forms, processes, and rules

93

BMC Remedy Action Request System 7.6.04

Approver fields
This section describes how the approval server manages the sizes of approver
fields and a utility that is used for this purpose.

Lengths of approver fields


By default, approver names are limited to 255 characters and the list of members
in an approval server role is limited to 512 characters. The approval server checks
the lengths of the fields listed in Table 5-3 at startup, and enforces this length as the
maximum limit.
Table 5-3: Approver fields checked for maximum length at startup
Field ID

Field name

Form name

12401

Member List

AP:Role

13203

Original Approvers

Next Approvers

13205

Approvers

13207

AP:Signature
AP:PreviewSignatures
AP:Signature
AP:PreviewSignatures
AP:Signature
AP:PreviewSignatures
AP:PreviewInfo

14511

GNA Approvers

AP:Signature

14512

PGNA Approvers

AP:Signature

You can increase the length of these fields to the maximum limit permitted by the
database (VARCHAR limit) by manually executing an approval server utility. See The
apchgschema utility on page 95.
In release 7.5.00 or earlier, the approval server only checks the size of the
Approvers field at startup, and enforces this length as the maximum limit for
approver names. If the default limits are insufficient, you need to increase the field
lengths manually.
Table 5-4: VARCHAR limits for special fields on supported databases
Database

VARCHAR limit

IBM

4000

IBM

DB2

Informix

Microsoft SQL Server

255
8000
Note: Even though the VARCHAR limit on SQL Server is 8000

characters, apchgschema sets the field length to 4000


characters to support Unicode.

94

Oracle

4000

Sybase

255

BMC Remedy Approval Server Guide

Approver fields

To use longer approver names with previews, make the following changes:

For regular previews, increase the length of the Approvers and Original
Approvers fields on AP:PreviewSignatures.

For real-time previews, increase the length of the Approvers field on


AP:PreviewInfo.

The apchgschema utility


During a fresh installation or upgrade to release 7.6.xx, the apchgschema utility is
placed at the following location:

WindowsapprovalServerInstallDir\bin\apchgschema.bat

UNIXapprovalServerInstallDir/bin/apchgschema.sh

Administrators can run this utility to set the length of approver fields on certain
forms to the maximum limit allowed by the database. Table 5-3 on page 94 lists the
forms and their approver fields that are affected.
The syntax for apchgschema is as follows:
apchgschema -s serverName -u userName [-p userPassword]
[-portnum tcpPortNumber] -i ARSystemInstallDir
[-l absoluteLogFilePath]

Table 5-5 describes the parameters that administrators need to supply when
running the apchgschema utility.
Table 5-5: Parameters for the apchgschema utility
Parameter Description
-s

Mandatory; name or IP address of the AR System server to log into (or


localhost, if applicable).

-u

Mandatory; specify the AR System user name.


This user must belong to an administrator group, otherwise the utility can
not be run successfully, and the following error is displayed at the command
prompt and written to apchgschema.log:
Admin verification failed: userName

-p

Optional; specify the password for the aforementioned user.


Omit this parameter if the user account does not have a password.

-portnum Optional; TCP port number of the server being logged into.
This parameter is required if the AR System server is configured to listen on
a particular TCP port.

Chapter 5

Introduction to approval forms, processes, and rules

95

BMC Remedy Action Request System 7.6.04

Table 5-5: Parameters for the apchgschema utility


Parameter Description
-i

Mandatory; path to the directory where AR System is installed.


The utility further searches for the approval server directory.

-l

Optional; absolute path to your custom log file.


The utility writes the details of all its activities into this file.
If this value is not provided, the utility records its activities in the default
apchgschema.log file, at the following location:

WindowsARSystemInstallationDir\Arserver\Db
UNIXARSystemInstallationDir/db

Here is a sample apchgschema command:


apchgschema -s myARServer -u myAPAdmin -p myAPPassword
-portnum 8080 -i C:\BMC Software\ARSystem\
-l C:\BMC Software\ARSystem\approval\myAPUtilLogFile.log

NOTE
The apchgschema utility increases the lengths of the approver fields provided that
the current lengths are not already set to the maximum VARCHAR limit, or to
unrestricted or 0 (zero).
In case of the Member List field, if the maximum length supported by the database
is less than 512 characters, the current field length is not modified. This ensures
that the corresponding data remains intact.

96

BMC Remedy Approval Server Guide

Chapter

Defining an approval process

This section describes the procedures to create and modify processes in


BMC Remedy Approval Server (approval server).
The following topics are provided:

Using the Process tab on AP:Administration (page 98)


Creating a process (page 98)
Working with existing processes (page 103)
Defining roles (page 106)

Chapter 6 Defining an approval process

97

BMC Remedy Action Request System 7.6.04

Using the Process tab on AP:Administration


To create and manage processes, you use the Process tab on the AP:Administration
form. When you select the Process tab, a table field appears. To populate the table
with all existing processes, click Refresh. You can sort this list on any column,
including the process name, the linked approval request form, the process type,
the process status (active or inactive), or the process ID. If you installed the sample
applications, all the sample application processes appear on this list.
The buttons on the Process tab take the following actions:

ViewOpens the AP:Process Definition form for the selected rule in Modify
mode. You must select a process from the list to use this button. Use this option
to view and modify existing processes.

SearchOpens a blank AP:Process Definition form in Search mode. Use this


option to search for a process using a field that does not appear in the processes
list.

CreateOpens the AP:Process Definition form in New mode. Use this option to
create a new process.

DeleteDeletes the selected process. You must select a process from the list to
use this button.

RefreshRefreshes the current list of processes. Use this button to refresh the
list, for example, after adding a new process.

Creating a process
To create a new process, click Create on the Process tab of the AP:Administration
form. This opens the AP:Process Definition form in New mode.
For more information, see AP:Process Definition on page 231.
AP:Process Definition contains the following tabs:

BasicUse this tab to define basic information about the process, including the
process name and type, the associated form, and approval success criteria.

ConfigurationUse this tab to specify:

98

Process intervals to calculate the Action Date for a request

Menus to generate lists of users that appear when creating a More


Information request (by adding a question or comment), reassigning a
request, and assigning a request to an ad hoc approver

The mandate for rejection justification and the application forms field on
which to push an approvers input

Signature Escalations (Normal, Urgent, and Low)Use these tabs to schedule


notifications and automatic actions for pending requests.

BMC Remedy Approval Server Guide

Creating a process

More Info EscalationsUse this tab to schedule notifications for requests in the
More Information state.

Administrative InfoThe fields on this tab contain the change history and help
text (if any) for the process. Use the Help Text field to document the process.

In most cases, you need only one process for your approval request, but it is
possible to create multiple processes. For an example of an application that uses
three separate approval processes, see the Sample Lunch Scheduler form that is
described in Sample process descriptions on page 146.

NOTE
Before you can create a process, the approval request form that you link your
process to must exist on the AR System server, and must appear in the list of forms
on the Form tab of AP:Administration. To link the approval request form for your
application to the approval server, see Adding the approval request form to
AP:Administration on page 157.

Defining process basics


Use the Basic tab on AP:Process Definition to define basic information such as the
process name and type, the associated form, and approval success criteria.

To create a process
1 Open the AP:Administration form.

See Using the approval server Administration form on page 24.


2 On the Process tab, and click Create to open the AP:Process Definition form in New

mode.
3 In the Basic tab, specify appropriate values in the various fields.

See AP:Process Definition on page 231.


4 Click Save.

Figure 6-1 on page 100 depicts the basic process definition for the sample
Management Cost Authorization process.

Chapter 6 Defining an approval process

99

BMC Remedy Action Request System 7.6.04

Figure 6-1: Process Definition formBasic tab

Setting process intervals


Use the Configuration tab of the Process Definition form to configure process
intervals.

To set process intervals


1 On AP:Administration, select a process and click View.

For more information, see Creating a process on page 98 and AP:Process


Definition on page 231.
The selected process opens in Modify mode.
2 Click the Configuration tab.
3 Enter a number in the Process Due field, and select what this number represents

from the Unit list.


For example, if you want the process to be due five days after the first signature is
created, enter 5 in the Interval field, and select Days from the Unit list.

100

BMC Remedy Approval Server Guide

Creating a process

NOTE
The Process Due interval is required as a minimum for the action date feature.
If this field is left blank, no action date is associated with the process or its
corresponding requests.
4 Enter a number in the Signature Due field, and select what this number represents

from the Unit list.


For example, if you want every signature to be due in two days, enter 2 in the
Interval field, and select Days from the Unit list.
5 Enter a number in the Buffer Period field, and select what this number represents

from the Unit list.


This value is used as a delta to be deducted from all other intervals, except
Signature Due, to derive the minimum of all the required process intervals.
6 In the Enable Preview field, select Yes if you want to consider future approvers

when calculating the Signature Due date. Select No if you want if you want to use
the value in the Signature Due field only.
7 Click Save.

Besides these process intervals, you also need to specify certain values in the
Signature Escalation tabs and on AP:Notification and AP:Admin-ServerSettings.

Creating signature escalations


Use the Signature Escalations tabs to configure settings for notifications and
actions when a signature line has been waiting too long without a response. For
example, you can set up a notification to be sent when a request has been
outstanding for two days.
This procedure applies to any of the notification priority levelsNormal, Urgent,
or Low.

To enter signature escalations


1 Open the Process Definition form if it is not already open. See Creating a process

on page 98.
2 On the Basic tab, select a process from the list and click View.

The selected process opens in Modify mode.


3 Click the tab for the notification priority level on the Process Definition form:

Normal, Urgent, or Low.

NOTE
If you do not enter parameters for either urgent or low priority notifications, the
parameters you enter for normal priority are used. You can use the urgent or low
priority sections to enter only parameters that are different than those you set for
normal priority.

Chapter 6

Defining an approval process

101

BMC Remedy Action Request System 7.6.04

4 Select or enter the names of the business calendar and the holiday calendar you

want to use for signature escalation notifications.


These names must match existing schedule names from the Business Time
Workdays or Business Time Holidays forms. For information about configuring
business times, see the Configuration Guide, Using Business Time in the
AR System server, page 215.
5 To change the state of an approval request automatically if no signature action

occurs after a specified interval, enter the Automatic Action parameters:


a Enter a number in the After Interval field to indicate when you want the state

changed, and select what this number represents from the Unit list.
For example, if you want the state to change two days after the approval request
enters a certain state, enter 2 in the After Interval field, and select Days from
the Unit list.
b In the Change State field, use the drop-down list to select the state that you want

to apply to the approval request.


The options are Pending, Approved, or Rejected.
If you set these parameters, approvers can see the resulting date and time after
which the state of the approval request changes automatically. This reflects on
AP:Show-Detail > Action Date field and Approval Central > Action Date column.
For more information, see AP:Show-Detail on page 243 and Approval Central
on page 255.
6 To send notifications when a signature line has been outstanding (in any state) for

too long, specify the Notification: Still Outstanding parameters:


a Enter a number in the First Interval field to indicate when you want the first

notification sent, and select what this number represents from the Unit list.
b If you want a second notification sent, enter a number in the Repeat Interval

field and select what this number represents from the Unit list.
This reflects on Approval Central > Past Due requests > Action Date column. For
more information, see Approval Central on page 255.
7 If you want to send notifications when the approval request remains in a certain

state (Pending, Error, Hold, or More Information) too long, specify the
Notification: Still in State parameters:
a Enter a number in the First Interval field for the desired state to indicate when

you want the first notification sent, and select what this number represents from
the Unit list.
b If you want a second notification sent, enter a number in the appropriate Repeat

Interval field and select what this number represents from the Unit list.

102

BMC Remedy Approval Server Guide

Working with existing processes

Creating More Information escalations


Use the More Info Escalations tab to configure settings that control notifications
when a More Information request has been waiting too long without response. For
example, you can set up a notification to be sent when a More Information request
has been outstanding for two days.

To enter More Information escalations


1 Open the Process Definition form if it is not already open. See Creating a process

on page 98.
2 Click the More Info Escalations tab.
3 Select or enter the names of the business calendar and the holiday calendar you

want to use for More Information Escalation notifications. These names must
match existing schedule names from the Business Time Workdays or Business
Time Holidays forms. For information about setting up business times, see the
Configuration Guide, Using Business Time in the AR System server, page 215.
4 If you want to send notifications when a signature line has been outstanding (in

any state) for too long, specify the Notifications: Still Outstanding parameters:
a Enter a number in the First Interval field to indicate when you want the first

notification sent, and select what this number represents for the Unit list.
For example, if you want the first notification sent two days after the approval
request enters the More Information state, enter a 2 in the First Interval field
and select Days from the Unit list.
b If you want a second notification, enter a number in the Repeat Interval field and

select what this number represents from the Unit list.


5 Click Save.

Working with existing processes


The following sections describe how to modify, delete, or rename an existing
process.

Viewing and modifying a process


Follow these steps to view or modify an existing process.

To modify a process
1 Open the AP:Administration form. See Using the approval server Administration

form on page 24.


2 Click the Process tab, and click Refresh.
3 Select the process from the list and click View.

Chapter 6

Defining an approval process

103

BMC Remedy Action Request System 7.6.04

The Process Definition form opens in Modify mode, displaying the entry for the
selected process.
4 Modify the appropriate process fields as needed. See Creating a process on

page 98 for information about field values.


5 Click Save.

Deleting processes
This section describes how to delete an existing process.

NOTE
The delete operation is permanent and cannot be undone. When you delete a
process, all of its associated rules are deactivated.

To delete a process
1 Open the AP:Administration form and click the Process tab.
2 Click Refresh to populate the list of processes.
3 Select the process you want to delete.
4 Click Delete.
5 Click Yes when prompted to confirm the deletion.

The process is deleted and no longer appears in the list of processes.

Renaming an approval process or form


If you must rename an approval process or an approval form, you can apply the
new process or form name to all existing requests in the process, or only to active
requests.

NOTE
If you need to rename a process or approval form, you must also edit any related
workflow, such as the filter that starts the process, to correct the process name.

To rename a process or form


1 Open the AP:Administration form.

See Using the approval server Administration form on page 24.


2 Click Rename in the navigation pane.

The approval server Rename dialog box (AP:Admin-Rename form) appears as


shown in Figure 6-2.

104

BMC Remedy Approval Server Guide

Working with existing processes

Figure 6-2: Renaming a process

3 Select Process to rename a process, or Form to rename a form.


4 In the field labeled Select GUID of the process to be renamed, click the drop-

down menu.

If you are renaming an approval process, a list of the existing processes appears
by name. Select the process name. AR System supplies the process GUID. Click
the GUID to select the process.

If you are renaming a form, a list of all forms on the AR System server appears.
Select the approval form to be renamed.

5 Type the new process or form name in the field labeled Enter new process name

or Enter new form name.


6 In the Scope of Update field, select whether you want to rename the process or

form for all requests, or only active requests.

All RequestsThis option updates both currently active and completed detail
and signature records. This option takes more time but will make sure that all
detail records reference the new name.

Only Active RequestsThis option updates only the currently active detail and
signature records.

7 To change the name of the process or object as well as the related requests, make

sure that the Including Object Itself check box is selected.


If you have already manually changed the process or form name, clear this check
box. In this case, AR System renames only the related requests. In this case, you
must enter the current process or form name in the field labeled Enter new
process name or Enter new form name.
8 Click Rename to complete the action.

Chapter 6

Defining an approval process

105

BMC Remedy Action Request System 7.6.04

Defining roles
The approval server can route a request to a role instead of an individual. When
you use a role, the request is routed to all members of the role. You specify whether
one member of the role can approve a request or whether all members must
approve it.
The Overdue Oversight role is an example of the use of roles in the Lunch
Scheduler sample application. It works with the Rule-Based process to route
approvals for an overdue account to the members of the Overdue Oversight role.

To define a role
1 Open the AP:Administration form. See Using the approval server Administration

form on page 24.


2 Click the Role tab, and click Create.

The AP:Role form appears in New mode.


Figure 6-3: Defining an approver role

3 Enter a Role Name in the Role Name field.

The name should be descriptive of a job or a responsibility, for example, MIS


Management.
4 Select an option from the If Multiple Approvers list.

This determines how many signature line records the approval server creates for
the role when building an Approver List.

106

BMC Remedy Approval Server Guide

Defining roles

The options are:

One Must SignUse this value to create a single signature line record for the
role. The signature line is complete when one of the members of the role acts
upon the approval request.

All Must Sign (default)Use this value to create a separate signature line for
each member of the role.
This option is overridden when the If Multiple Approver setting for the process
is defined as One Must Sign. When this is the case, the role follows the One
Must Sign process setting. See Creating a process on page 98.

NOTE
If you include a role in the member list of another role, the If Multiple Approvers
option of the parent role will take precedence. For example, suppose that Role A
is defined with If Multiple Approvers set to All must sign and you include Role
A in the member list of Role B. Role B is defined with If Multiple Approvers set to
One must sign. In this example, the approval server uses the settings for Role B.
5 In the Status field, select Active or Inactive. Active is the default value.
6 In the Member List field, type the names of the role members.

You must enter valid user names or role names, and separate entries with a
semicolon or a hard return. Click the Text Box button to open an expanded text
box. This field has a maximum length of 255 characters.
7 Click Save.

Chapter 6

Defining an approval process

107

BMC Remedy Action Request System 7.6.04

108

BMC Remedy Approval Server Guide

Chapter

Defining approval rules

This section describes how to create and modify rules in BMC Remedy Approval
Server (approval server).
The following topics are provided:

Using the Rule tab on AP:Administration (page 110)


Creating a rule (page 110)
Defining approval rules (page 114)
Working with existing rules (page 141)

Chapter 7 Defining approval rules

109

BMC Remedy Action Request System 7.6.04

Using the Rule tab on AP:Administration


To create and manage rules, you use the Rule tab on the AP:Administration form.
See Using the approval server Administration form on page 24.
When you open the Rule tab, a table field appears listing all existing rules. You can
sort this list on any column, including rule name, process name, rule type, order,
status, and process instance ID. If you installed the sample applications, all the
sample application rules appear on this list.
Below the list of rules, a diagram illustrates the stages of an approval process and
contains links that filter the list for each rule type. For example, to see a list of all
existing Get Next Approver rules, click the Next Approver link on the diagram.
To see only the rules for a specific process, select the process from the menu in the
Show for Process field.
The buttons on the Rule tab take the following actions:

ViewOpens the AP:Rule Definition form for the selected rule in Modify
mode. You must select a rule from the list to use this button. Use this option to
view and modify existing rules.

SearchOpens a blank AP:Rule Definition form in Search mode. Use this


option if you want to search for a rule using a field that does not appear in the
rules list.

CreateOpens the AP:Rule Definition form in New mode. Use this option to
create a new rule.

DeleteDeletes the selected rule. You must select a rule from the list to use this
button.

RefreshRefreshes the current list of rules. Use this button to refresh the list,
for example, after adding a new rule.

Show allRefreshes the list of rules with all existing rules. Use this button to
refresh the list after narrowing it to show only one type of rule.

Creating a rule
To create a new rule, click Create on the Rule tab of the AP:Administration form.
This opens the AP:Rule Definition form in New mode.

NOTE
To create a rule, you must first create the process that the rule will support. See
Chapter 6, Defining an approval process.

110

BMC Remedy Approval Server Guide

Creating a rule

AP:Rule Definition consists of three tabbed views (depending on the type of rule):

BasicThe fields on this tab store identification and execution information


about the rule, as well as a Run If qualification statement, if any.

Set FieldsFor rules that include a Set Fields action, the fields on this tab
specify the action to be executed by the rule when a transaction passes the
qualification statement.

Administrative InformationThe fields on this tab contain change history and


help text (if any) for the rule. Use the help text field to describe the purpose of
the rule, or any other information helpful to process administrators.

Figure 7-1: Defining a new rule

Using the Basic tab on the Rule Definition form


Use the Basic tab on the Rule Definition form to enter descriptive information
about the rule, such as the rule name, the associated process name, and the rule
type. Depending on the rule type, you might use the Run If or Rule field in the
Qualification area to enter a condition statement. This section describes the steps
that are common to creating all rule types by using the Basic tab. For information
about the If Multiple Results, If Multiple Approvers, and Next Approver Rule Is
fields, see Defining Get Next Approver rules on page 121 and Defining
Parameterized Get Next Approver rules on page 126.

To complete the fields on the Basic tab that are common to all rules
1 Open the AP:Administration form, and click the Rule tab.
2 In the Rule Name field, enter a name for the rule.

Rule names must be unique and can be as long as 30 characters. For ease of
administration, use a rule name that reflects the application or process, the rule
type, the rule function, or some combination.
Chapter 7 Defining approval rules

111

BMC Remedy Action Request System 7.6.04

3 In the For Process field, select the process name that this rule will support from the

list.
The processes that appear on this menu are those you have defined in the Process
tab. When you select the process name, AR System automatically populates the
Process Instance ID field.
4 In the Rule Type field, select the appropriate rule type from the list. For example,

if you are creating a Get Next Approver rule, select Get Next Approver.
When you select a rule type, the Rule Definition form changes to display the fields
appropriate for the rule type. Fields that apply to the rule type have a white field
box. Fields that do not apply are gray.
5 In the Order field, enter an execution order number. The default value is 0.

This number determines the rule sequence when two or more of the same rule type
exist for a specific process.
6 In the Status field, select either Active or Inactive. The default value is Active.

Inactive rules do not run when the process runs. While you are developing a set of
rules for a process, it might be helpful to use the Inactive status. When you are
ready to test your rules, change the Status field to Active.

NOTE
If you save a rule with the Status field empty, the rule is saved as Active.
7 In the Assignee Group Permissions field, the Public group appears by default. If

you use this field for multi-tenancy support, create workflow to populate this field
with the correct assignee group name. You do not need to change this setting when
creating the rule.
The approval server supports multi-tenancy for use by application service
providers. The Assignee Group Permissions field is field 112, and appears on all
the approval server forms. The field 112 value from records created in the
AP:Details form is used automatically in all the other approval server forms, for
example, AP:Signature, AP:More Information, and so on.
8 If the rule requires a qualifying condition to control execution, enter the condition

in the Qualification area of the Basic tab. This field is labeled Rule or Run If,
depending on the rule type. Process Done rules use a radio button field to set the
execution condition.
You can type the condition statement or you can build it by using the qualification
bar and list. When the qualification is met, the rule actions execute. You can use
currency, date, and time fields in Run If and Rule qualification statements.
For more information, see the Workflow Objects Guide, Building qualifications and
expressions, page 49. For specific examples pertaining to various rule types, see
the discussion of each rule type in this section.
9 Click Save.

112

BMC Remedy Approval Server Guide

Creating a rule

Using the Set Fields tab on the Rule Definition form


The Set Fields tab applies to all rule types except Auto Approval, Self Approval,
and Completion rules. You use the Set Fields tab to define the actions for the rule.
For example, for a Get Authority rule, you can define a query to retrieve a
signature authority amount from the AP-Sample:Signature Authority form and set
that amount into a temporary field on the AP:Signature form.
When you construct assignments using the Set Fields tab, you can also use
currency, date, and time fields, currency functions such as CURRCONVERT,
CURRSETDATE, CURRSETTYPE, or CURRESETVAL, and date functions such as
DATEDIFF, DATENAME, DATENUM, or DATEADD.
Depending on the rule type, the Set Fields tab provides the following action
options in the Set Fields Type field:

ValueUse this action to assign a value to a particular field.

QueryUse this action to specify a form (from the current server or another
server) and a qualification for a query to that form. You can assign the value of
any field from the queried form. If no match is found for the qualification, a
NULL value is assigned. If multiple matches are found, the value assigned
depends on the If Multiple Rows setting on the Basic tab.

SQLUse this action to specify an SQL command to be run on either the


AR System server or another database. You can assign the value from any
returned column. If the command finds no entries, a NULL value is assigned. If
it finds multiple entries, the value assigned depends on the If Multiple Rows
setting on the Basic tab.

ProcessUse this action to specify a process to be run on the AR System server.


If the command returns an empty string or an error, a NULL value is assigned.

OtherThis setting enables you to specify an action by using an AR System


filter. See the Workflow Objects Guide, About filters, page 17.

When you select the type of action, the buttons and fields in the qualification area
change according to the action type.

Example of the Set Fields tab for a query


Figure 7-2 illustrates a Get Authority rule from the sample applications that makes
a query to the AP-Sample:Signature Authority form.
In this example, the rule uses a query to the AP-Sample:Signature Authority form
to retrieve the signature dollar limit for the current approver.

Chapter 7 Defining approval rules

113

BMC Remedy Action Request System 7.6.04

Figure 7-2: The Set Fields tab for Get Authority rule with a query

Defining approval rules


This section describes how to define the various types of approval rules and an
provides an example of each.

Defining Auto Approval rules


An Auto Approval rule determines if the request can be automatically approved
at the time it is submitted, without action from any approver, and regardless of the
submitters signature authority. Automatic approval occurs when an approval
request transaction passes any Auto Approval rule included in the process.
Creating Auto Approval rules is optional. If you do not define an Auto Approval
rule, no automatic approval occurs.

NOTE
Auto Approval rules cannot use values retrieved from forms other than the current
request. To retrieve values from another form, use a Self Approval rule. See
Defining Self Approval rules on page 118.

114

BMC Remedy Approval Server Guide

Defining approval rules

If an Auto Approval rules condition is met, the request is done and moves directly
to the Process Done stage. When an approval request meets the criteria in an Auto
Approval rule, the approval server sets the rule state to Approved in the Detail
record. This action activates an Approval Process Done rule.

To define an Auto Approval rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Auto Approval in the Rule Type field.

Write a rule condition to test for a specific field value from the approval request
form, for example, checking whether the value for an Estimated Total field is
less than $15.00.

2 Enter an Audit Text message (optional).

This message is written to the audit log when the condition for this rule passes. The
audit text can include embedded field references that are filled when the rule
condition passes. If you do not enter an audit message, a default message is written
to the audit log.
3 Click Save to save your changes.

Example of an Auto Approval rule


Figure 7-3 on page 115 illustrates an Auto Approval rule. In this example from the
Lunch Scheduler sample application, the value in the Estimated Total field of the
approval request form is tested to see if it is less than $15. If this rule passes, the
customized audit trail message in the Audit Text box is written to the audit log.
Figure 7-3: Example of an Auto Approval rule

Chapter 7 Defining approval rules

115

BMC Remedy Action Request System 7.6.04

Defining all Get Authority rules


The approval server provides three types of get authority rules:

Get AuthorityRuns in both the Self Check and Completion Check stages of
the approval process

Get Authority SelfRuns only in the Self Check stage of the approval process

Get Authority RegularRuns only in the Completion Check stage of the


approval process.

You use the same procedure to define all three types of get authority rules.
All get authority rules gather information about the current approver or
environment that is used by subsequent Self Approval or Completion rules.

To define any type of get authority rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

In the Rule Type field, select Get Authority, Get Authority Self, or Get Authority
Regular.

Create a condition statement in the Run If field if necessary. The condition


statement controls whether the rule actions execute. This field is optional for this
rule type; if no qualification exists, the rule always runs.

2 Click the Set Fields tab.


3 In the Set Field Type field, select an action from the menu.

The Set Field Type indicates the type of assignment to be used for the rule action.
See Using the Set Fields tab on the Rule Definition form on page 113.
4 In the From Form field, select a form name from the menu.

This value defines the form that the rule will search for the requested data; for
example, the AP-Sample:Signature Authority form.
5 In the On Server field, select the server where the form is located.

116

CurrentThe form exists on the current server.

AlternateThe form exists on another server. In this case, type the server name
where the form is located in the Server field.

BMC Remedy Approval Server Guide

Defining approval rules

6 In the Qualification area, enter a qualification statement to define the parameters

for retrieving the authority data.


For example, to retrieve the current approvers signature authority limit from the
AP-Sample:Signature Authority form, define a qualification statement that sets
$Approver$ (current approver) to equal the Login Name field in the Signature
Authority form.

Click Fields from Set Fields Form to select the Login Name field from the form
named in the From Form field.

Click Fields from Application Form to select the $Approver$ field from the
current record of the AP:Signature form.

7 In the Fields Data area, enter the names of the field or fields to receive the data in

the Field Name column, and a value statement or the name of each source form
field in the Value column.
Use the field list button to the right of each field to select the field names. The fields
in the Field Name column are located in the AP:Signature form. The fields in the
Value column are located in the form named in the From Form field (such as
AP-Sample:Signature Authority).
8 Click Save.

Example of a Get Authority rule


Figure 7-4 illustrates an example of a Get Authority rule from the Lunch Scheduler
sample application. This rule retrieves data about the person currently acting on
the request ('Login Name' = $Approver$) from the AP-Sample:Signature
Authority form.
Figure 7-4: Example of a Get Authority rule

Chapter 7 Defining approval rules

117

BMC Remedy Action Request System 7.6.04

The value in this approvers Signature Dollar Limit field on the


AP-Sample:Signature Authority form is written to a temporary field named Temp
Decimal 1 in the Details form. The value in the temporary field is then available for
use by any Self Approval or Completion rule.

Defining Self Approval rules


A Self Approval rule determines whether an approval request can be approved,
based on an attribute of the requester, such as signature authority. Self approval is
immediate and simply tests whether the approval request meets the defined
criteria.
A Self Approval rule differs from an Auto Approval rule in that Self Approval
rules can use values retrieved from another form. Self Approval rules usually
depend on a Get Authority Self or Get Authority rule to retrieve a value from
another form. For example, a Get Authority Self rule can retrieve the signature
authority value for the requester and write the value to a temporary field on the
AP:Signature form. This makes the signature authority value available for use by
a Self Approval rule.
When an approval request meets the criteria in a Self Approval rule, the request
moves directly to the Process Done stage. The approval server sets the rule state to
Approved in the Detail record, which activates an Approval Process Done rule.

To define a Self Approval rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

In the Rule Type field, select Self Approval from the list.

Build a condition statement that tests for a specific field value to determine if the
rule passes. The condition can reference any value of the current approval
request or any values retrieved by a Get Authority or Get Authority Self rule.
For example, test to see if a signature authority field value is $100.00 and the
total approval request amount is less than or equal to $100.00.

2 Enter an Audit Text message (optional).

This message is written to the audit log when the condition for this rule passes. The
audit text can include embedded field references that are filled when the rule
condition passes. If you leave the Audit Text field blank, a default message is
written to the audit log.
3 Click Save.

118

BMC Remedy Approval Server Guide

Defining approval rules

Example of a Self Approval rule


Figure 7-5 on page 119 shows an example of a Self Approval rule from the Lunch
Scheduler sample application. In this example, the rule condition is a statement
comparing the value in the Estimated Total field of the approval request with the
value in a temporary field (Temp Decimal 1) on the AP:Signature form, and the
value 200.
For this Self Approval rule to work, a Get Authority Self or a Get Authority rule
must also be included in the process to retrieve the value for the temporary field.
In this example, the temporary field value is a signature authority value pulled
from the AP-Sample:Signature Authority form by a Get Authority rule. The
Estimated Total field is located on the approval request form (AP-Sample:Lunch
Scheduler).
In addition to the rule condition, this sample rule includes a customized audit trail
message to be written to the audit log when the rule passes.
Figure 7-5: Example of a Self Approval rule

Chapter 7 Defining approval rules

119

BMC Remedy Action Request System 7.6.04

Defining Prep Get Next Approver rules


The Prep Get Next Approver rule type gathers information to be used by Get Next
Approver rules. (In the rule name, prep is an abbreviation for prepare.) These
rules use a Set Fields action to place values in certain fields.

To define a Prep Get Next Approver rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Prep Get Next Approver from the Rule Type list.

The rule condition in the Run If text box is optional. Use this field to define a
conditional statement that controls whether the rule executes. If you do not
define a condition, the rule always passes.

2 Open the Set Fields tab and perform the following steps:
a In the Set Fields Type field, select the action type from the menu. See Using the

Set Fields tab on the Rule Definition form on page 113.


b If the action type is Query, select a form name from the From Form list. This

value indicates which form to search for the data being retrieved by the query.
c In the On Server field, select Current if the form exists on the current server, or

select Alternate if the form exists on another server, and enter the server name
where the form is located in the Server field.
d Depending on the action type, enter the qualification statement or command

line in the Qualification area.


e In the Fields Data area, enter the name of the field or fields to receive the data in

the Field Name column, and a value statement or the name of each source form
field in the Value column.
f Click Save.

Example of a Prep Get Next Approver rule


The Overdue Prep Get Next rule in the Lunch Scheduler sample application,
illustrated in Figure 7-6 on page 121, is an example of a Prep Get Next Approver
rule. It gathers information that will be used by the Rule-Based process Special
Overdue Approval. The Basic tab in this example does not contain a Run If
statement. This means that the rule always runs. On the Set Fields tab, a Value
action increments the level field with the value $Level$+1.

120

BMC Remedy Approval Server Guide

Defining approval rules

Figure 7-6: Example of a Prep Get Next Approver rule

Defining Get Next Approver rules


Get Next Approver rules obtain a list of approvers for an approval request. The
number of signature-line records created for the approver list depends on the
definition of the Get Next Approver rule:

When If Multiple Approvers is set to One Must Sign, the approval server creates
a single signature record for the entire approver list. To complete the signature
record, only one of the approvers in the list must act on the approval request.

When If Multiple Approvers is set to All Must Sign, the approval server creates
a separate signature record for each approver in the approver list. If a role is in
the approver list, the approval server creates a separate signature record for
each member of the role. In this case, each approver must act on the approval
request to complete his or her signature line.

A signature record is considered complete when any approver on the signature


record approves, rejects, or cancels the approval request.

Chapter 7 Defining approval rules

121

BMC Remedy Action Request System 7.6.04

Process type and Get Next Approver rules


The Parent-Child, Level, and Rule-Based process types use Get Next Approver
rules, and each process has different requirements.

Get Next Approver rules in a Parent-Child process


In a Parent-Child process, you must create a form to define individuals or roles,
and the form must include a field that identifies the parent record. When an
approver marks a request Approved, the approval server automatically routes the
approval request to the parent of the approver (usually the approvers
manager). See Parent-Child process on page 75 for more information about this
process type.
For a Get Next Approver rule in a Parent-Child process, the following
considerations apply:

The approval server assumes that the current approver is the key component of
the qualification.

To build the first approver list when the request is submitted, the approval
server considers the originator of the approval request to be the previous
approver.

Get Next Approver rules in a Level process


In a Level process, you must define individuals and roles with a field that identifies
the organizational level of the individual or role. For example, level 1 might be
project leaders and level 2 might be section managers. Levels are always numeric
values, with 0 (zero) being the lowest level. See Level process on page 77 for
more information about this process type.
When the approval server creates the first approver list when the request is
submitted, it assumes that the previous level was -1. Therefore, the first level is the
level with the lowest number. The approval server keeps track of the current
approver level during the approval cycle.
For a Get Next Approver rule in a Level process, the following considerations
apply:

122

You must identify the field containing the level identifier.

If you define a qualification that includes a clause to retrieve only entries with a
level greater than the current level, you save processing time by allowing the
approval server to skip over individuals or roles in the previous levels. This type
of clause is not required, as previous level entries are simply ignored if they are
retrieved.

BMC Remedy Approval Server Guide

Defining approval rules

Get Next Approver rules in a Rule-Based process


In a Rule-Based process, rules define the relationships between individuals or roles
and the approval process. The approval server makes no assumptions regarding
these relationships. You must design the appropriate rules to determine how to
construct the first approver list and how to move from one phase of the approval
process to the next.
Use the Next Approver Rule Is field on the Rule Definition form to define a set of
rules that evaluate the conditions necessary to add an approver to the current
approver list. See Rule-Based process on page 79.

Ad Hoc processes
Ad Hoc processes do not use the Get Next Approver rule type, because an Ad Hoc
process expects that users will add the next approver. See Ad Hoc process on
page 78.

Creating a Get Next Approver rule


To create a Get Next Approver rule, use the following procedure.

To define a Get Next Approver rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Get Next Approver from the Rule Type list.

The rule condition in the Run If text box is optional. Use this field to define a
conditional statement that controls whether the rule executes.

2 In the If Multiple Results field, select a value from the menu.

This field determines what occurs when more than one row of data is returned by
the Get Next Approver rule. The following choices are available:

Value from FirstUses the value from the first record retrieved.

Values from AllUses all of the values retrieved.

Return ErrorReturns an error message if more than one record is retrieved.

ClearLeaves this field blank.

3 In the If Multiple Approvers field, select a value from the menu.

This field value determines the signature requirements when more than one
approver is returned by the Get Next Approver rule.

One Must SignA single signature record is created and only one of the
approvers listed in the record is required to act upon the approval request to
consider the record complete.

Chapter 7 Defining approval rules

123

BMC Remedy Action Request System 7.6.04

All Must SignA separate signature record is created for each individual in the
approver list, including individuals within a role. In this case, all of the
approvers retrieved by the Get Next Approver rule must act upon the approval
request.

ClearLeaves this field blank.

4 In the Next Approver Rule Is field, select a value from the menu.

This field value determines how the approver list is constructed when multiple Get
Next Approver rules exist in the process. It is often used in a Rule-Based process
that uses set of Get Next Approver rules to build an approver list.

AdditiveIndicates that any name or role this rule assigns to the approver list
is added to the existing approver list, and further rules are to be processed.

EndingIndicates that any name or role this rule assigns to the approver list is
added to the existing approver list, but no further rules are to be processed.

ExclusiveIndicates that this rule assigns the entire approver list, and no
further rules are processed. In addition, if a previous rule created an approver
list, that list is ignored.

ClearLeaves this field blank.

5 Enter the rule condition in the Run If text box (optional).

If used, this field defines a conditional statement that controls whether the rule
runs. You can type the conditional statement or you can build it by using the
qualification bar and list. See the Workflow Objects Guide, About Run If qualifications
and expressions, page 50.
6 Click the Set Fields tab.
7 In the Set Fields Type field, select the appropriate action type. See Using the Set

Fields tab on the Rule Definition form on page 113.


8 For a query, select a form name from the From Form menu.

This value indicates in which form to search for the query.


9 In the On Server field, select the server where the form is located.

CurrentThe form exists on the current server.

AlternateThe form exists on another server. In this case, type the server name
where the form is located in the Server field.

10 Depending on the action type, enter the qualification statement or command line

in the Qualification area.


11 In the Fields Data area, enter the name of the field or fields to receive the data in

the Field Name column, and a value statement or the name of each source form
field in the Value column.
12 Click Save.

124

BMC Remedy Approval Server Guide

Defining approval rules

Example of a Get Next Approver rule


Figure 7-7 illustrates an example of a Get Next Approver rule for the Parent-Child
process in the Lunch Scheduler sample application.
The Basic tab in this example does not contain a Run If statement, so the rule
always runs. The If Multiple Approvers setting causes the approval server to create
a single signature record for the approver list (One Must Sign). Therefore, only one
approver action is required for the approval request to be complete. The Next
Approver Rule Is field is set to Ending, so no other Get Next Approver rules will
be processed after this one.
On the Set Fields tab, the Qualification statement causes the approval server to
match the current approver ($Approver$) to the Login Name field in the
AP-Sample:Signature Authority form during the query. The current approver
could be the approval request submitter or an approver.
The rule retrieves the parent of the current approver by getting the value from
the $Manager Login Name$ field on the matching record in the
AP-Sample:Signature Authority form and setting the value in the Next Approver
field of the approval request.
Figure 7-7: Example of a Get Next Approver rule in a Parent-Child process

These fields determine the number of


signature records created.

Chapter 7 Defining approval rules

125

BMC Remedy Action Request System 7.6.04

Defining Parameterized Get Next Approver rules


The Parameterized Get Next Approver rule enables requesters and approvers
working with a Parent-Child, Level, or Rule-Based process to add an approver
anywhere in the approval hierarchy at run time. This rule type works with the
preview feature to make this functionality available. See Adding previews to
your approval application on page 168.
For example, an approver using the preview feature in a Parent-Child process
might see the following hierarchy of approvers:
1 Allan
2 Lin
3 Akon
4 Penni

A Parameterized Get Next Approver rule would allow approver Lin to enter an
additional approver, Michel, at the same level as Penni, for example.
You use the Parameterized Get Next Approver rule in combination with the
Add-PGNA-Values application command. The Add-PGNA-Values command
populates the detail record with the run-time variables to be used by the rule. See
Add-PGNA-Values on page 182.
A Parameterized Get Next Approver rule works exactly like a Get Next Approver
rule, with the following exceptions:

You can use run-time variables in the qualification and Set Fields operations.

Approvers can be added to any level, not only the next level.

After the Get Next Approver rules are executed, the server executes all
Parameterized Get Next Approver rules. If Parameterized Get Next Approver
rules exist, but the current record does not supply any parameters, the approval
server the approval server skips the parameterized rules.

To define a Parameterized Get Next Approver rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Parameterized Get Next Approver from the Rule Type list.

The Run If condition is optional. Use this field to define a conditional statement
to control whether the rule runs.

2 In the If Multiple Results field, select a value from the menu.

This field determines what occurs when more than one row of data is returned by
the Get Next Approver rule. The following choices are available:

126

Value from FirstUses the value from the first record retrieved.

Values from AllUses all of the values retrieved.

BMC Remedy Approval Server Guide

Defining approval rules

Return ErrorReturns an error message if more than one record is retrieved.

ClearLeaves this field blank.

3 In the If Multiple Approvers field, select a value from the menu.

This field value determines the signature requirements when more than one
approver is returned by the Get Next Approver rule.

One Must SignA single signature record is created and only one of the
approvers listed in the record is required to act upon the approval request to
consider the record complete.

All Must SignA separate signature record is created for each individual in the
approver list, including individuals within a role. In this case, all of the
approvers retrieved by the Get Next Approver rule must act upon the approval
request.

ClearLeaves this field blank.

4 In the Next Approver Rule Is field, select a value from the menu.

This field value determines how the approver list is constructed when multiple Get
Next Approver rules are included in the process.

AdditiveIndicates that any name or role this rule assigns to the approver list
is added to the existing approver list, and further rules are to be processed.

EndingIndicates that any name or role this rule assigns to the approver list is
added to the existing approver list, but no further rules are to be processed.

ExclusiveIndicates that this rule assigns the entire approver list, and no
further rules are processed. In addition, if a previous rule created an approver
list, that list is ignored.

ClearLeaves this field blank.

5 Select Yes or No from the Guaranteed Add list.

YesThe parameterized rule runs even when a Completion rule would


otherwise determine that the process is done, thus guaranteeing that the user
will be added as an approver.

NoIf a Completion rule determines that the conditions exist for the process to
be done, the process does not return to the Get Next Approver stage to run this
rule.

6 Click the Set Fields tab.


7 In the Set Fields Type field, select the appropriate action type. See Using the Set

Fields tab on the Rule Definition form on page 113.


8 For a query, select a form name from the From Form menu. This value indicates in

which form to search for the query.


9 In the On Server field, select the server where the form is located.

CurrentThe form exists on the current server.

AlternateThe form exists on another server. In this case, type the server name
where the form is located in the Server field.
Chapter 7 Defining approval rules

127

BMC Remedy Action Request System 7.6.04

10 Depending on the action type, enter the qualification statement or command line

in the Qualification area.


11 In the Fields Data area, enter the name of the field or fields to receive the data in

the Field Name column, and a value statement or the name of each source form
field in the Value column.
12 Click Save.

Example of Parameterized Get Next Approver rule


Figure 7-8 illustrates an how an example Parameterized Get Next Approver rule
operates. The example rule includes the following settings:

Run If qualification: $Level$ = %1

Guaranteed Add: Yes

Set Fields: $Next Approver$ = %2

Figure 7-8: Example of a Parameterized Get Next Approver rule

The following actions occur:


Step 1 A user enters an approval request in a process that includes an approval hierarchy,

such as a Parent-Child or Level process.


Step 2 When working with the approval request, the first approver uses the preview

feature to view the existing approvers for the request, for example, by clicking a
button on the approval form. The approver decides to add Michel LeTourneau as
an approver at a future level, for example, level 4.
Step 3 The approver uses functionality added to the approval request form, such as a

button that opens an Add Approvers form, to enter the level and the approver
name. When the approver saves his or her changes, a filter runs that captures these
values and sends an Add-PGNA-Values application command using the values to
the approval server.
128

BMC Remedy Approval Server Guide

Defining approval rules

For example:
Application-Command Approval Add-PGNA-Values -o My Param Rule
-l 4/Michel LeTourneau
Step 4 The approval server receives the command, and stores the data in the Param Data

field on the AP:Detail record.


Step 5 After the approval server executes the Get Next Approver rules, it executes

Parameterized Get Next Approver rules. While executing the parameterized rules,
it retrieves the values from the Param Data field in the detail record. In this case, it
retrieves
4/Michel LeTourneau and parses this into %1=4 and %2=Michel
LeTourneau
Step 6 The approval server replaces the variables in the Parameterized rule with these

values:

Run If qualification$Level$ = 4

Set Fields$Next Approver$ = Michel LeTourneau

Step 7 If the condition matches, the Set Fields action is executed. If the condition never

matches and the regular Get Next Approver rules do not return any approvers, the
approval server checks for the Guaranteed Add flag. If this is set to yes, the
parameterized rule executes, even though the Run If condition is not satisfied.
Parameterized Get Next Approver rules are executed when a preview is
generated, so the added approver is visible when future approvers preview the
request.

Defining Validate Approver rules


A Validate Approver rule enables you to verify approver names when they are
manually entered on an approval request. This applies to either an Ad Hoc process
type or an ad hoc override.
This rule validates the approver name at the time of entry by searching for a match
to the entered name on a specified form, for example, a signature authority form
such as AP-Sample:Signature Authority in the sample application.
You can define any number of Validate Approver rules. This allows you to search
more than one form to validate an approver name.

WARNING
Approver names in Validate Approver rules are case sensitive. Make sure
approver names are entered correctly by providing a menu of names for requesters
to select from. See the Form and Application Objects Guide, Creating menus,
page 299.

Chapter 7 Defining approval rules

129

BMC Remedy Action Request System 7.6.04

To define a Validate Approver rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Validate Approver from the Rule Type list.

The Run If condition is optional. Use this field to define a conditional statement
to control whether the rule runs.

2 Click the Set Fields tab.


3 In the Set Fields Type field, select the appropriate action type. See Using the Set

Fields tab on the Rule Definition form on page 113.


4 For a query, select a form name from the From Form menu.

This value indicates in which form to search for the query.


5 In the On Server field, select the server where the form is located.

CurrentThe form exists on the current server.

AlternateThe form exists on another server. Enter the server name where the
form is located in the Server field.

6 Depending on the action type, enter the qualification statement or command line

in the Qualification area.


7 In the Fields Data area, enter the name of the field or fields to receive the data in

the Field Name column, and a value statement or the name of each source form
field in the Value column.
8 Click Save.

Example of a Validate Approver rule


Figure 7-9 illustrates an example of a Validate Approver rule from the Get
Agreement sample application. On the Set Fields tab, the qualification condition
causes the rule to search the Login Name field of the User form to find a match for
a name entered in the approver field ($Approver$) of the approval request form
(AP-Sample2:Get Agreement).

130

BMC Remedy Approval Server Guide

Defining approval rules

Figure 7-9: Example of a Validate Approver rule

Defining Signature Accumulator rules


A Signature Accumulator rule gathers data across the set of current signature
records, for use by a Statistical Override rule. You use Signature Accumulator rules
when the standard signature statistics gathered by the approval server are not
sufficient.
The approval server automatically populates the hidden Total fields in the join
forms with the number of signature records in Pending, Approved, Rejected, Hold,
More Information, Cancelled, Error, and Closed states. These values are often
sufficient to construct a Statistical Override rule. If not, you can define Signature
Accumulator rules to gather other data.
If a Signature Accumulator rule exists, it runs when a signature record is approved,
rejected, or cancelled. The approval server collects a set of current signature
records and applies the Signature Accumulator rules for the approval process to
each record (provided the Run If qualification passes). After all rules have been
applied for the current signature, the approval server moves to the next signature
and applies the rules.
A Signature Accumulator rule uses the Set Fields operation to collect and store the
signature data. Typically, the Set Fields operation in a Signature Accumulator rule
performs an addition to accumulate information, as in the following example:
$Temp Decimal 1$ = $Temp Decimal 1$ + $Signature Dollar Limit$

The assignment of the Set Fields operation is always to the Detail record that the
approval server is processing. After all rules have been applied for one signature,
the approval server moves to the next signature and applies the rules.

Chapter 7 Defining approval rules

131

BMC Remedy Action Request System 7.6.04

To define Signature Accumulator rules


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Signature Accumulator from the Rule Type list.

Use the Run If qualification to include or exclude signatures. The Run If


condition is qualified on each signature, for example:
$Approval Status$ = Approved

If the Run If condition is met, the server will perform the Set Fields operation.
2 Click the Set Fields tab.
3 In the Set Fields Type field, select the appropriate action type. See Using the Set

Fields tab on the Rule Definition form on page 113.


4 For a query, select a form name from the From Form menu.

This value indicates in which form to search for the query.


5 In the On Server field, select the server where the form is located.

CurrentThe form exists on the current server.

AlternateThe form exists on another server. In this case, type the server name
where the form is located in the Server field.

6 Enter a qualification statement to define the parameters for retrieving the authority

data.
For example, to retrieve the current approvers signature authority limit, define a
qualification statement that sets $Approver$ (the current approver) to equal the
user name field on the signature authority form (such as Login Name on
AP-Sample:Signature Authority).
7 In the Fields Data area, enter the name of the field or fields to receive the data in

the Field Name column, and a value statement or the name of each source form
field in the Value column.
8 Click Save.

Example of a Signature Accumulator rule


The Get Agreement sample application includes an integrated set of Signature
Accumulator and Statistical Override rules in an Ad Hoc process. See Example of
decision-making rules in a sample application on page 133.

Defining Statistical Override rules


The Statistical Override rule evaluates data gathered by a Signature Accumulator
rule or by the approval server, and determines whether the process should
immediately conclude with an Approved or Rejected state, or should continue
using the default approval server behavior.

132

BMC Remedy Approval Server Guide

Defining approval rules

To define a Statistical Override rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Statistical Override from the Rule Type list.

In Statistical Override rules, the Run If condition specifies the condition to be


evaluated. For example, to check if 50 percent or more of the signatures have
been approved, you create a Run If condition as follows:
$Total Signatures$ / $Total Approved$ >= .5

To derive the statistical override value, you can use static values, arithmetic
operations, keywords, the results from functions, and values from the record that
the approval server is processing in the AP:Detail-Signature form.
2 Click the Set Fields tab.
3 In the Set Fields Type field, select the appropriate action type.

See Using the Set Fields tab on the Rule Definition form on page 113.
4 For a query, select a form name from the From Form menu.

This value indicates in which form to search for the query.


5 In the On Server field, select the server where the form is located.

CurrentThe form exists on the current server.

AlternateThe form exists on another server. In this case, type the server name
where the form is located in the Server field.

6 Enter a qualification statement, if any.


7 In the Fields Data area, type one of the following values (or its integer equivalent)

into the first entry in the Value list:

Approved

Rejected

In a Statistical Override rule, the Field column on the Set Fields tab is automatically
populated with the statistical override field name. The Set Fields function sets the
specified value in the statistical override field on the Detail form. The only valid
statistical override values are Approved or Rejected.
8 Click Save.

Example of decision-making rules in a sample application


The Get Agreement sample application uses an Ad Hoc process that contains four
interrelated statistical decision-making rules. These are Issue Retrieve Signature
Limit and Issue Increment Signature Limit (Signature Accumulator rules), and
Issue Statistical Approval and Issue Statistical Boundary Condition (Statistical
Override rules).
For more information about the Get Agreement sample application, see Chapter 4,
Using the Get Agreement sample application.
Chapter 7 Defining approval rules

133

BMC Remedy Action Request System 7.6.04

Activating the sample rules


When the sample application is installed, these rules are set to Inactive status. To
follow the procedures in this section, you must change the status to Active.

To change the rules to active status


1 Open the Rule tab on the AP:Administration form.
2 In the Show For Process field, select the process Issue Approved.
3 Check the Status column. If any rules are set to Inactive, use the View button to

open the rule.


4 In the Status field of the Basic tab, select Active.
5 Click Save, and Close.

Sample data for the statistical decision-making rules


The approvers in this example have the following signature authority:

Jack Millers signature limit is $100.00.

Larry Goldsteins signature limit is $500.00.

Violet Andersons signature limit is $2000.00.

The signature authority data that supports these sample rules is imported with the
sample applications and stored in the Signature Dollar Limit field of the
AP-Sample:Signature Authority form, as shown in Figure 7-10.
Figure 7-10: Dollar signature limits in the AP-Sample:Signature Authority form

134

BMC Remedy Approval Server Guide

Defining approval rules

Rule functionality
When one of the sample approvers responds to a request, the sample statistical
decision-making rules run. Signature Accumulator rules run before Statistical
Override rules. In this case, they both have a Run If condition that causes the Set
Fields action to occur only when the approvers signature is set to Approved. (If
the approvers signature is set to Rejected, these rules do not run and the default
approval server behavior causes the request to be rejected.)

The rule Issue Retrieve Signature Limit has execution order 0, so it runs first. It
retrieves the Signature Dollar Limit for the current approver, and sets the value
in a temporary field (Temp Decimal 1) on the Detail form.
For this rule, the Set Fields qualification used is:
'Login Name' = $Approvers$

This qualification retrieves the signature authority amount for the current
approver by matching the current approvers login name to the Login Name
field on the AP-Sample:Signature Authority form.

The rule Issue Increment Signature Limit has execution order 1, so it runs next.
It increments another temporary field in the Detail form with the current
cumulative signature dollar value for all approvers who have responded.

The example Statistical Override rules run after the Signature Accumulator rules
are complete.

The rule Issue Statistical Approval has execution order 0. The Run If condition
causes it to run only when the Approver response is set to Approved.

It checks the current cumulative signature authority. If the current cumulative


signature authority is greater than $500, the Set Fields action sets Statistical
Override to Approved.
This approves the request, regardless of whether all approvers have
responded. In this way, the rule preempts the default approval server
behavior and approves the request. In this case, the other Statistical Override
rule does not run because the request is done.

If the current cumulative signature value is less than $500, the Set Fields
action does not occur, and the request is not yet done.

The rule Issue Statistical Boundary Condition has execution order 1. It runs only
if the first Statistical Override rule did not result in approving the request.

If signatures are still pending, the Set Fields action does not occur, and the
approval process continues.

If a hold exists or a More Information request is pending, the Set Fields action
does not occur, and the approval process continues.

If approvers remain, and the current cumulative signature authority is not


greater than $500, the Set Field action sets Statistical Override to Rejected, and
the request is done.

These two Statistical Override rules work together to assure that the approval
process always ends with the request set to either Approved or Rejected.
Chapter 7 Defining approval rules

135

BMC Remedy Action Request System 7.6.04

NOTE
This example assumes that the request is for an amount greater than $500. The Get
Agreement sample application does not include a field for the amount of the
request. In an actual approval process, you would also need a field to gather the
amount of the request, and a Run If condition to test the amount.

Using the sample application with statistical decision-making rules


This section describes how to create a request that will activate the example
Signature Accumulator and Statistical Override rules, and how to observe the
action of the rules after each approval. Use BMC Remedy User or a browser to
perform these procedures.

To create a request that activates the example rules


1 Log in to the appropriate AR System server as the sample user Frank Williams.
2 Open the AP-Sample2:Get Agreement form in New mode.
3 In the Summary field, type:
I want to purchase a new laser printer.
4 In the Details field, type:
A really nice new laser printer costs $600.

This entry is only a comment, and does not affect the behavior of the rule.
5 In the Initial Approvers field, type:
Jack Miller; Larry Goldstein; Violet Anderson

Be sure to type a semicolon between each approvers name.


6 Click Save.

To illustrate how statistically driven approvals work, the following procedure uses
the AP:Detail-Signature form to view the approval status after a response by each
approver.

To observe the approval process in the AP:Detail-Signature form


1 Using BMC Remedy User or a browser, log in to AR System as an administrator,

and open the AP:Detail-Signature form in Search mode.


2 In the Approval Status field, select Pending, and click Search.

The approval request created by Frank Williams is pending for Jack Miller, Larry
Goldstein, and Violet Anderson.
3 Log in as Jack Miller, open Approval Central, and approve the request from Frank

Williams.

136

BMC Remedy Approval Server Guide

Defining approval rules

Figure 7-11: Observing rule activity in the AP:Detail-Signature form

4 Repeat steps 1 and 2.

The sample statistical decision-making rules require the cumulative signature


authority to be greater than $500. Because Jacks signature authority is weighted at
$100, the approval is still pending for either Larry or Violets signature.
5 Log in as Larry Goldstein, open Approval Central, and approve the request from

Frank Williams.
6 Repeat steps 1 and 2.

The request is no longer pending when you search the AP:Detail-Signature form.
Because the cumulative signature authority of Jack Miller and Larry Goldstein is
$600 ($100 + $500), the approval condition in the Issue Statistical Approval rule is
met, and the request is approved, even though Violet has not responded.
Violets signature authority is weighted at $2000. Therefore, Violet could have
approved Franks request without requiring either Larry or Jacks approval.

Example of a Statistical Override rule with default data


The approval server automatically populates the hidden Total fields in the join
forms with the number of signature records in Pending, Approved, Rejected, Hold,
More Information, Cancelled, Error, and Closed states. You can use these field
values in Statistical Override rules. In this case, no Signature Accumulator rule is
necessary.
For example, the following Run If condition would check if 50 percent or more of
the signatures have been approved:
$Total Approved$ / $Total Signatures$ >= .5
Chapter 7 Defining approval rules

137

BMC Remedy Action Request System 7.6.04

When the Run If condition has been met, the preempted decision is specified on
the Set Fields tab.

Defining Completion rules


A Completion rule determines when the approval routing process is complete. For
example, a Completion rule can compare the current approvers signature
authority against the estimated total on the approval request.
Completion rules are usually teamed with the Get Authority or Get Authority
Regular rules. The authority rules retrieve information about an individuals or
roles authority from other forms and make the information available to
Completion rules.

To define a Completion rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Completion from the Rule Type list.

Construct a rule condition. The Completion rule condition defines whether the
approval process is complete (no further routing of the request is necessary). If
the condition is met, the process is complete. If it is not met, the approval server
returns the request to the Get Next Approver stage of the approval process.

2 Click Save.

Example of a Completion rule


Figure 7-12 illustrates an example Completion rule from the Lunch Scheduler
sample application. In this example, the temporary field Temp Decimal 1 on the
AP:Detail form contains the current approvers signature limit, which was
retrieved by a Get Authority rule. The rule compares the Estimated Total field on
the approval request to this signature limit. If the condition passes, the approval
process is considered complete.
You must define a Get Authority or a Get Authority Regular rule for the
Completion rule to work correctly in this example.

138

BMC Remedy Approval Server Guide

Defining approval rules

Figure 7-12: Example of a Completion rule

Defining Approval Process Done rules


Approval Process Done rules define the actions taken when the approval process
is done. The approval process is considered done when an approval request is
approved and passes a Completion rule, or if it is rejected, cancelled, or ends with
an approval error.
Approval Process Done rules are often used to change the state of the approval
request. For example, you use one Approval Process Done rule to change the state
of the approval request to Approved and another Approval Process Done rule to
change the state of the approval request to Rejected.
When an approver marks an approval request as either Approved or Rejected, the
approval server sets this status in the AP:Signature record for that approver. When
the conditions are met to approve the request, as determined by the process
definition or a Completion rule, the approval server sets the status in the AP:Detail
record for the request. To change the status in the approval request form, you use
an Approval Process Done rule. This also applies to approval requests that are
cancelled or that end in an error.

To define an Approval Process Done rule


1 Follow the procedure in Using the Basic tab on the Rule Definition form on

page 111 to complete the basic information about the rule.

Select Approval Process Done from the Rule Type list.

Select one or more rule conditions from among the radio buttons: Approved,
Rejected, Cancelled, or Error.
The rule executes when the AP:Detail record is put into the selected state.

2 Click the Set Fields tab.


3 Select a value from the Set Field Type list. See Using the Set Fields tab on the Rule

Definition form on page 113.

Chapter 7 Defining approval rules

139

BMC Remedy Action Request System 7.6.04

4 In the Field Data area, enter the appropriate Field Name and Value to change the

status of the approval request.


5 Click Save to save the rule.

Example of an Approval Process Done rule


Figure 7-13 illustrates an example Approval Process Done rule from the Lunch
Scheduler sample application. This Approval Process Done rule is activated when
the AP:Detail record is marked Approved during the Completion check. In this
rule, the Set Fields action sets the hidden Approval Workspace field on the
AP-Sample:Lunch Scheduler request form to Cost approved. In this case, the
value set is used by the chained processes in the application. A later action results
in marking the request approved overall. See Chaining approval processes on
page 147.
Figure 7-13: Example of an Approval Process Done rule

Rule trigger

Rule assignment action

140

BMC Remedy Approval Server Guide

Working with existing rules

Working with existing rules


This section describes how to view, modify, and delete existing approval rules.

Viewing and modifying rules


You can use the table of rules on the Rule tab of AP:Administration to filter rules
by process, or by rule type.

To filter the list by process type


1 Open the AP:Administration form and click the Rule tab.
2 In the Show For Process field, select the name of the process whose rules you want

to view, for example, Issue Approval.


The list is refreshed with rules that belong to the selected process.

To filter the list by rule type


1 Open the AP:Administration form and click the Rule tab.
2 Clear any process name from the Show For Process field.
3 In the diagram below the table of rules, click the link for the rule type you want to

view, for example, Process Done.


The list is refreshed to show all existing rules of the selected type.

To modify a rule
1 Open the AP:Administration form and click the Rule tab.
2 Select the rule to be modified, and click View.

The AP:Rule Definition form opens in Modify mode, showing the current values
for the rule.
3 Modify the rule as needed. For specific information about fields in the rule, see the

Defining topic for the rule type.


4 Click Save.

Deleting rules
This section describes how to delete an existing rule.

NOTE
The delete operation is permanent and cannot be undone. Check for any rule
dependencies before deleting a rule. For example, Self Approval and Completion
rules might depend on a Get Authority, Get Authority Regular, or Get Authority
Self rule. If the Get Authority rule is deleted, the dependent rule will no longer
function as designed.

Chapter 7 Defining approval rules

141

BMC Remedy Action Request System 7.6.04

To delete a rule
1 Open the AP:Administration form and click the Rule tab.
2 Select the rule to be deleted from the list, and click Delete.
3 Click Yes when prompted to confirm the deletion.

The rule is deleted and no longer appears in the list of rules.

142

BMC Remedy Approval Server Guide

Chapter

Using the Lunch Scheduler


sample application
The Lunch Scheduler is a sample application deployed with BMC Remedy
Approval Server (approval server).
This section describes the purpose of the three processes in Lunch Scheduler, and
illustrates how to chain several processes together to form one approval process.
The following topics are provided:

Overview of the Lunch Scheduler application (page 144)


Important Lunch Scheduler forms (page 145)
Sample process descriptions (page 146)
Chaining approval processes (page 147)
Sample users (page 150)

Chapter 8

Using the Lunch Scheduler sample application

143

BMC Remedy Action Request System 7.6.04

Overview of the Lunch Scheduler application


The Lunch Scheduler sample application gathers approvals for employees of an
imaginary company to schedule lunches with customer accounts. It uses three
processes, each a different type, to implement the business rules of the company.
Each process uses various types of rules.
This section describes the applications processes and how they work together. For
information about the rules used in each process, see Chapter 7, Defining
approval rules.

NOTE
The Lunch Scheduler and Get Agreement sample applications are not actually
packaged as AR System applications. They consist of a related set of workflow
objects, including the approval request form, active links and filters, approval
processes, and approval rules.
Figure 8-1: Lunch Scheduler approval request form

144

BMC Remedy Approval Server Guide

Important Lunch Scheduler forms

When using Lunch Scheduler, the requester specifies information about the
customer, the restaurant, and the number of attendees. These choices populate
fields containing details about the total costs and information about the customers
relationship with the company.
Lunch Scheduler includes three different approval processes chained together and
uses three different filters with Run Process commands to start these processes. For
more information, see the Workflow Objects Guide, Using Run Process and
$PROCESS$ commands, page 257.
The chained processes are:

Management Cost AuthorizationThis is a managerial approval based on the


total cost of the lunch. It is a Parent-Child process, so the request is routed to a
hierarchical series of managers until a manager with sufficient cost authority
approves it. The filter AP-Sample:Start Cost Approval starts this process.

Major Account Level ApprovalThis process runs if the account is a major or


enterprise account. It is a Level process that causes the request to be routed to
the major account and enterprise account teams. The filter AP-Sample:Start
Level Approval starts this process.

Special Overdue ApprovalThis process implements a special review of the


request if the account is currently overdue. It is a Rule-Based process. The filter
AP-Sample:Start Overdue Approv starts this process.

When requests are submitted in this application, they follow the appropriate
approval processes. The processes enforce the business rules of the company, and
the approval data gathered provides an auditable record of the business lunch
activity at the company.

NOTE
The Questions, Comments with attachments, Notes, and Multi-process preview
features are available out-of-the-box with this sample application. For more
information, see AP:Show-Detail on page 271.

Important Lunch Scheduler forms


This section lists the major forms associated with the Lunch Scheduler application.

AP-Sample:Lunch SchedulerThis is the approval request form for the


application.

AP-Sample:Lunch-DetailThis is the inner join between the


AP-Sample:Lunch Scheduler and AP:Detail forms. It is used for internal
processing by the approval server and for Global Override operations. The join
criteria is Request ID to Request.

AP-Sample:Lunch-Detail-SignatuThis is the three-way inner join between


the AP-Sample:Lunch Scheduler and AP:Detail-Signature forms. This is the
detail form that is available to approvers when they choose to view a request in
Approval Central. The join criteria is Request ID to Request.

Chapter 8

Using the Lunch Scheduler sample application

145

BMC Remedy Action Request System 7.6.04

AP-Sample:CompanyThis is a supporting form that stores data about


customer accounts. This data supports menus, workflow, and queries about the
customer companies in the application.

AP-Sample:RestaurantThis is a supporting form that stores data about


restaurants. This data supports menus, workflow, and queries about the
restaurants in the application.

AP-Sample:Signature AuthorityThis is a supporting form that stores data


about approvers. The approval server uses this data from this form to identify
hierarchical relationships in the organization. This data supplies information
about the account teams and is used to identify next approvers in the ParentChild and Level processes. The applications rules and processes use
information from this form about approvers signature authority to determine
routing and whether the process is done.

Sample process descriptions


The Lunch Scheduler application uses three separate approval processes that run
serially. Approval processes that are designed to run serially are referred to as
chained approval process. Two of the processes run conditionally, using a
condition statement to determine if the process is required for each request.
This section describes the operation of each process. To see how each process is
initiated and how the processes are chained together, see Chaining approval
processes on page 147.

Management cost authorization


This is a Parent-Child process that runs first and acts on every request. It uses Auto
Approval and Self Approval rules to determine if the requester has authority to
approve his or her own request. If not, the approval process routes the request to
the manager by using the AP-Sample:Signature Authority form. The approval
server routes the request to subsequent managers until a manager with sufficient
authority signs the request. If no one with sufficient authority can be found for an
individual, or if an individual has no manager, the process terminates with an
error.
The filter AP-Sample:Start Cost Approval starts the Management Cost
Authorization process. This filter uses the following application command:
Application-Command Approval New-Details -t Management Cost
Authorization

In this command, the tag -t identifies the name of the process to run. See NewDetails on page 187.

146

BMC Remedy Approval Server Guide

Chaining approval processes

Major account level approval


This is a Level process that runs if the request is for lunch with a major or enterprise
account. The process uses a Completion rule to stop lunch requests for major
accounts from advancing beyond the major account level. Only enterprise
accounts need to go to both the major account and enterprise account levels. The
Account Type field on the request form identifies the account as a major or
enterprise account.
The filter AP-Sample:Start Level Approval starts the Major Account Level
Approval process. The Run If criteria in the filter must be met for this filter to
execute. The filter uses the application command:
Application-Command Approval New-Details -s $SCHEMA$ -e
$Request ID$ -t Major Account Level Approval

In this command, -s identifies the name of the approval request form, -e


identifies the request ID for the current request, and -t identifies the name of the
process to run. See New-Details on page 187.

Special overdue approval


This is a Rule-Based process that runs only if the company currently has an
overdue account. This process includes an example of Prep Get Next Approver
rules, which retrieve and set data for Get Next Approver processing. The Account
Overdue check box on the AP-Sample:Company form identifies whether the
account is overdue.
The filter AP-Sample:Start Overdue Approv starts the Special Overdue Approval
process. The Run If criteria of the filter must be met for this filter to execute. The
filter uses the application command:
Application-Command Approval New-Details -t Special Overdue
Approval

In this command, the tag -t identifies the name of the process to run. See NewDetails on page 187.

Chaining approval processes


The Lunch Scheduler application demonstrates the technique of chaining three
different approval processes together to approve Lunch Scheduler requests. The
Lunch Scheduler application uses workflow to start the initial process and to
automatically run the additional processes when necessary.

Chapter 8

Using the Lunch Scheduler sample application

147

BMC Remedy Action Request System 7.6.04

Using filters and a process status field


The keys to implementing this workflow are to link the filters to the approval form
with the appropriate Execute On conditions, and to use a field to store the
current process status on the request form. The workflow filters that start each
chained process test the process status field with a Run If condition to determine
whether the chained process should run.
In the Lunch Scheduler application, the filter that starts the initial process,
Management Cost Authorization, is configured to run when the
AP-Sample:Lunch Scheduler form is submitted or modified. Using the Submit
condition assures that this process will run first. The chained processes, Major
Account Level Approval and Special Overdue Approval, use filters that are
configured to run only when the AP-Sample:Lunch Scheduler form is modified.
In the Lunch Scheduler application, a character field named Approval Workspace,
ID 536870920, tracks the process status. The Approval Process Done rules for each
process enter a string in this field to represent the current process status. The Run
If conditions of the filters that start the Major Account Level Approval and Special
Overdue Approval processes test this value to determine if the chained process
should run.
The three processes in the sample Lunch Scheduler execute in this order:
Step 1 The Management Cost Authorization process runs first because the filter is

configured to execute upon submission of the request.

In the Process Done stage of this process, the Approval Process Done rules
populate the Approval Workspace field of the Lunch Scheduler request form.
For example, if the request is approved, the Approval Process Done rule enters
Cost-Approved in this field.

Step 2 Because the request form was modified, the filters for the two chained processes

are executed.

148

If the customer is a major or enterprise account, the filters Run If condition


causes the Major Account Level Approval process to run.

When Major Account Level Approval process is done, its Approval Process
Done rules modify the Approval Workspace field to indicate the process result.
For example, if the request is approved, the Approval Process Done rule enters
Level-Approved in this field.

If the customer is not a major or enterprise account, the Major Account Level
Approval process does not run.

If the account is not overdue, the Special Overdue Approval process does not
run. If the account is overdue, this process runs only after the Approval
Workspace field has been set to Level-Approved.

BMC Remedy Approval Server Guide

Chaining approval processes

Step 3 If the Major Account Level Approval process runs, its Approval Process Done

rules again modify the request form. This causes the filters for the two chained
processes to fire again. In this case:

If the Level process completed with an approval, and the request is marked to
indicate that the account is overdue, the filters Run If condition causes Special
Overdue Approval process to run.

If the Level process completed with any other result (such as rejection), or if the
request does not indicate that the account is overdue, the Special Overdue
Approval process does not run, and the overall approval process is complete.

These three steps explain how the three processes are chained together to create
the overall approval process in the Lunch Scheduler application.
In addition to the filters that start the three processes, a fourth filter, APSample:Test Level Approval, runs whenever the approval request is modified.
This filter runs only after the Approval Workspace field is marked CostApproved, and if the Account Type is not major or enterprise. The filter
performs a set fields action that sets Level-Approved in the Approval
Workspace field. This assures that the Approval Process Done rules function the
same, even though the Level process did not actually run.

Restarting an approval process


Occasionally, after an approval process has been started, it becomes inappropriate
to proceed. You can configure your approval process to restart in such a situation.
For example, in the Lunch Scheduler application, a request automatically restarts
if anyone changes the restaurant, the company, or the number of attendees. This
ensures that users cannot make a change after the request has been approved.
The sample application implements this functionality by using a set of filters that
watch for a change to the Company, Number of Attendees, and Average Cost/
Person fields when the form is modified. If this occurs, a filter sets the Approval
Workspace field to contain a cancellation string. Another filter resets the status of
the request to Pending Approval in this case. (If the requester cancels the request
by another means, such as by modifying the Approval Status field, the request
does not restart because in that case the Approval Workspace field has not been
set.)

Chapter 8

Using the Lunch Scheduler sample application

149

BMC Remedy Action Request System 7.6.04

Sample users
The approval server sample applications include records for a set of sample users
that are preconfigured for testing the Lunch Scheduler application.

Licensing sample users


To log in as the sample users, an AR System administrator must enter them in the
User form, with either a fixed or floating write license. Make sure you have
purchased sufficient write licenses to create the sample users as actual accounts in
your AR System database.
Alternatively, you can use existing licensed users with the sample applications. To
do so, you must modify the data in the AP-Sample:Signature Authority form by
replacing the sample login names with login names that already exist in your
AR System User form.

Sample user approval authority


The sample application users are set up in a Parent-Child hierarchy. Each has a
spending authority limit, as shown in Figure 8-2. To follow the sample application
procedures in this document, configure at least the users Frank Williams, Jack
Miller, Larry Goldstein, and Violet Anderson. If you use your own existing
AR System users, configure at least four users, one each with the signature
authority values matching these four sample users.
Figure 8-2: The hierarchy and spending authority of sample users

150

BMC Remedy Approval Server Guide

Chapter

Adding approvals to your


application
This section describes how AR System administrators connect an AR System
application to BMC Remedy Approval Server (approval server). This discussion
assumes you have an existing application with an approval request form, and have
installed the approval server.

NOTE
Although you do not need to be an AR System administrator to set up and manage
approval processes, only an AR System administrator must carry out most of the
tasks described in this section.
The following topics are provided:

Designing an approval application (page 152)


Connecting an application to the approval server (page 152)
Adding notifications to the approval process (page 158)
Creating notifications (page 159)
Enhancing your approval forms (page 166)
Adding previews to your approval application (page 168)
Multi-process preview (page 170)
Using a custom ad hoc dialog box with the approval server (page 171)

Chapter 9

Adding approvals to your application

151

BMC Remedy Action Request System 7.6.04

Designing an approval application


Before you begin to configure an approval application in AR System, you should
think through your approval needs and the business processes that you want to
implement with the approval server.
When you design an approval application, consider the process and rule types that
are included with the approval server. Identify which process types are most
appropriate for use in your application, and which rule types will best implement
the decisions and transitions in your approval process. Also, identify where you
will need to add AR System workflow to implement approval functionality, such
as adding an active link to a button on your approval request form, or adding
filters to start the approval process or to chain approval processes together. Also,
identify which stages and statuses in the approval process should trigger
notifications or escalations.

Connecting an application to the approval


server
To link your application to the approval server and configure the approval
process, you must perform each of the following actions:

Create an approval request form that requesters will use to enter approval
requests.

Create two join forms that join your approval request form with two different
approval server supporting forms.

Run arjoinfix (UNIX) or arjoinfix.exe (Windows) to configure the join


forms for the approval server.

Enter the approval request form in AP:Administration.

Define the processes and rules in AP:Administration.

Add workflow (at least one filter) to the approval request form that will start the
approval process.

Add notifications to your process.

This section describes procedures for the first three actions, as well as adding
notifications. To create processes and rules, see the following chapters in this
guide:

Chapter 5, Introduction to approval forms, processes, and rules

Chapter 6, Defining an approval process

Chapter 7, Defining approval rules

For information about defining filters, see the Form and Application Objects
Guide.

152

BMC Remedy Approval Server Guide

Connecting an application to the approval server

Creating an approval request form


In BMC Remedy Developer Studio, create a regular form and add any fields
necessary for requesters to create an approval request. Set the field permissions
and default values on the core fields of your approval request form as shown in
Table 9-1. Setting these permissions allows approvers to change the fields.
Otherwise, the fields listed in the table can be modified only by the AR System
administrator.
You must be an AR System administrator or subadministrator to create this form
and set permissions. See these sections in the Form and Application Objects Guide:

Creating AR System forms on page 147

Defining access control on page 21

Table 9-1: Approval request formfield permissions


DB ID

Default label

Permissions

Request ID

Assignee (view)

Allow any user to


submit

Public (view)
2

Submitter

Assignee (view)

Yes

Public (view)
3

Create Date

Assignee (view)
Public (view)

Assigned To

Assignee (change)

Yes

Public (view)
5

Last Modified By

Assignee (view)

Modified Date

Assignee (view)

Status

Assignee (change)

Yes

Public (view)
Submitter (change)
8

Short Description

Assignee (change)

Yes

Public (view)
Submitter (change)

Creating the join forms


To connect your application to the approval server, you create two inner join
forms. In both cases, your approval request form is the primary form for the join.
This section describes how to create both join forms.

A two-way join connects your approval request form to the approval server
form AP:Detail.

A three-way join connect your approval request form to the approval server join
form AP:Detail-Signature.

This section assumes that you have already created your approval request form.
Chapter 9

Adding approvals to your application

153

BMC Remedy Action Request System 7.6.04

NOTE
Be sure to create only one three-way join form for your application.

To create the two-way join


1 Log in to BMC Remedy Developer Studio as an AR System administrator.
2 In AR System Navigator, expand serverName > All Objects.
3 Right-click Forms, and choose New Join Form.
4 In the New Join Form wizard, follow the prompts to take the following actions:

Primary FormSelect your approval request form as the primary form, and
click Next.

Secondary FormSelect AP:Detail as the secondary form, and click Next.

Join PropertiesSelect the Inner join type, the appropriate field positioning
and inheritance options, and click Next.

Primary Form Field SelectionSelect Default Administrator View, move all


fields to Selected Fields, and click Next.

Secondary Form Field SelectionSelect Default Administrator View, move all


fields to Selected Fields, and click Finish.

The new join form appears. This join form is used only for internal processing, so
the appearance of the form is not critical.
5 On the new join form, you must manually specify a reserved ID for two fields. Use

the Outline tab in BMC Remedy Developer Studio to locate these fields.
a Select the Status-Dtl field, and set the following values in the Properties tab:
Table 9-2: Property settings for the Status-Dtl field of the two-way join form
Category

Property

Value

Display

Field Access

Read / Write

Database

ID

13191

b Select the Request field (not Request ID), and enter 10051 in the ID property.
6 Choose Form > Form Properties > Permissions.
7 Move the Public group to the Permissions field, change the group permission type

to Hidden, and click OK.


8 Save and name the join form.
9 Click Yes or OK in response to the AR System warning messages.

To create the three-way join form


1 Log in to BMC Remedy Developer Studio as an AR System administrator.
2 In AR System Navigator, expand serverName > All Objects.
3 Right-click Forms, and choose New Join Form.

154

BMC Remedy Approval Server Guide

Connecting an application to the approval server

4 In the New Join Form wizard, follow the prompts to take the following actions:

Primary FormSelect your approval request form as the primary form, and
click Next.

Secondary FormSelect AP:Detail-Signature as the secondary form, and click


Next.

Join PropertiesSelect the Inner join type, the appropriate field positioning
and inheritance options, and click Next.

Primary Form Field SelectionSelect Default Administrator View, move all


fields to Selected Fields, and click Next.

Secondary Form Field SelectionSelect Default Administrator View, move all


fields to Selected Fields, and click Finish.

The new join form appears. Your users use this form when working with the
details of an approval, so the layout and appearance of this form are important.
5 Hide or remove from view any fields that users do not need to see, such as most of

the fields from the AP:Detail-Signature form.

TIP
Use the Outline tab in BMC Remedy Developer Studio to locate and select a field.
Then choose Layout > Bring To Front to see the field if necessary. Use tabs in a
panel field to display only those fields that you want users to view or modify.
6 Rename the status fields to clarify their purpose (optional):

The Approval Status field (ID 13191) is from the AP:Detail-Signature form and
represents the status of the current approval signature. Approvers can use this
field to approve or reject a request from the detail view if they do not use the
buttons in Approval Central.

The Status field (ID 7) is from your application request form and represents the
status of the overall request.

7 Choose Form > Form Properties > Permissions.


8 Move the Public group to the Permissions field, change the group permission type

to Hidden, and click OK.


9 Save and name the join form.
10 Click Yes or OK in response to the AR System warning messages.

Chapter 9

Adding approvals to your application

155

BMC Remedy Action Request System 7.6.04

Running arjoinfix
After the join forms are created, run the arjoinfix (UNIX) or arjoinfix.exe
(Windows) utility once for each approval request form that you connect to the
approval server. This utility modifies the join qualifications to make sure that your
application communicates properly with the approval server. The arjoinfix
utility is installed in the same directory as the approval server.

To run arjoinfix (UNIX) or arjoinfix.exe (Windows)


1 Open a command window and enter the following command:
arjoinfix -i ARSystemServerInstallDir [-portnum portNumber]

In this command, ARSystemServerInstallDir is the directory where the


AR System server and the approval server are installed.

TIP
On Windows, the -i parameter is optional. When the approval server is installed
on a Windows server, you can use Start > Run to navigate to and run
arjoinfix.exe.
If the AR System server is configured to use a portmapper, do not use the
-portnum parameter. If the AR System server does not use a portmapper, use the
-portnum parameter and replace portNumber with the appropriate TCP port.

TIP
The arjoinfix utility might return authentication errors on an AR System server
that is configured to run with a specific TCP port. If such errors occur, set the
ARTCPPORT environment variable to the appropriate port number and try again.
The arjoinfix utility prompts:
Enter the name of the form:
2 Type the name of the applications approval request form, and press Enter. For

example, for the Lunch Scheduler sample application, enter


AP-Sample:Lunch Scheduler.
The arjoinfix utility prompts:
----------Menu---------1. Update Join Criteria
2. Add New Fields In 3-Way Join Form
Default: Quit
Make your choice & Press <enter>:
3 Type 1 to update the join criteria, and press Enter.

NOTE
You only need to use the option 2 of arjoinfix when you upgrade your
AR System server and approval server to release 7.x.xx from an earlier release. See
Performing required three-way join form updates on page 176.

156

BMC Remedy Approval Server Guide

Connecting an application to the approval server

Adding the approval request form to AP:Administration


This section describes how to link your approval request form to the approval
server.

To add the approval request form to AP:Administration


1 Log in to BMC Remedy User or a browser as a process administrator or an

AR System administrator.
2 Open the AP:Administration form in Search mode.
3 Click the Form tab, and click Create.
4 In the Form Name list, select the approval request form for your application.
5 In the Lookup Keyword field, enter a keyword that describes the form.

The approval server uses the keyword to look up the form name. The keyword acts
as a permanent search name for the form and enables workflow to find the form
even if the form name is changed.
6 If your approval application uses a form for reporting, select the reporting form in

the Approval Reporting list.


7 In the Assignee Group Permissions field, the Public group appears by default. If

you use this field for multi-tenancy support, create workflow to populate this field
with the correct assignee group name. You do not need to change this setting when
creating the form entry.
8 Save and close the request form.

Implementing the approval process


After you create the approval request form and the join forms, and enter the
approval request form in AP:Administration, the following tasks remain to
implement the approval process:

Create the approval process or processes.

Create the rules.

Create at least one filter to start the approval process.

Create the workflow for chained processes, if you are using them.

Create notifications.

Add security and usability features.

Creating the processes, rules, and filters


Create the processes and rules that you have designed to carry out your approval
process. You must include Process Done rules to make sure that the approval
process result is reported to the approval request form when the process is done.
See Chapter 5, Introduction to approval forms, processes, and rules, Chapter 6,
Defining an approval process, and Chapter 7, Defining approval rules.
Chapter 9

Adding approvals to your application

157

BMC Remedy Action Request System 7.6.04

You must also create at least one filter that will start the approval process when a
requester submits an entry in the approval request form. The filter conditions
should cause the filter to run on submit (and possibly on modify). In the If Action
tab, enter a Run Process action to run the New-Details application command. This
initiates the approval process.
For some examples of filters that start an approval process, see the filters included
in the sample applications, such as AP-Sample2:Start Approvals, AP-Sample:Start
Cost Approval, and so on. For information about defining filters, see the Form and
Application Objects Guide. For details about application commands, see Appendix
B, Application commands.
Test your processes, rules, and filters together to verify that the approval workflow
operates correctly and covers all possible outcomes of the approval process.

Creating chained processes


Some applications require a series of processes that are linked, or chained, together
by using workflow. To do so, you must:

Add a field to your approval request form to contain the process status.

Define Process Done rules to populate this field with the appropriate status
value.

Define workflow that tests the conditions for running each process and initiates
Run Process actions using application commands to start each process.

The Lunch Scheduler application includes an example of three chained processes.


For details about chaining approval processes with examples from the Lunch
Scheduler application, see Chaining approval processes on page 147.

Adding notifications to the approval process


You can use the approval server to send notifications and escalations that alert
requesters and approvers when action is required on an approval request. In
addition to using email and BMC Remedy Alert as notification methods,
notifications can be fired by workflow. This is referred to as workflow-based
notifications.
For example, you can add notifications to alert requesters and approvers in the
following situations:

158

When a request is waiting for an approver response, including escalations for


requests that have been pending for a specified time

When an approver responds with an approval or rejection

When a More Information request is pending

When an error occurs

When an approver puts a request on hold

BMC Remedy Approval Server Guide

Creating notifications

When the normal approval cycle has been overridden by an approver or the
Process Administrator

Creating notifications
You can configure approval server notifications to be delivered by email, by
BMC Remedy Alert, by the users default notification mechanism, or by workflow.
To create an approval notification, use the following procedures:

Verify that the events for which you want the approval server to send
notifications are enabled in the AP:Admin-ServerSettings form. If notifications
are not enabled on this form, they are not sent regardless of other approval
server settings. See Configuring server settings on page 27.

Configure the approval server to send approver notifications using the


procedure Defining an email or BMC Remedy Alert notification on page 159.

Configure the delay before escalations when no activity occurs using the
procedure Creating signature escalations on page 101.

Configure notifications for More Information requests using the procedure


Creating More Information escalations on page 103.

Defining an email or BMC Remedy Alert notification


To define notifications, you use the Notification tab on AP:Administration. This
tab opens AP:Notification form. You can define who receives a notification, the
notification message text, when the message is sent, and by what method. The
AP:Notification form has four tabs:

BasicSpecifies the notification name, associates the notification with a


process, and sets the conditions for the notification.

DetailsSpecifies the notification method, priority, recipients, and the


message.

EmailFor notifications that use email as the delivery mechanism, specifies


email-related information.

Administrative InformationContains change history and administrator help


text for the notification.

Fields with bold headings on the Notification form are the required fields; others
are optional.

To define an approval notification


1 Log in to BMC Remedy User or a browser as a process administrator or an

AR System administrator.
2 Open the AP:Administration form in Search mode.
3 Click the Notification tab, and click Create.

Chapter 9

Adding approvals to your application

159

BMC Remedy Action Request System 7.6.04

The AP:Notification form opens in New mode, with the Basic tab selected, as
shown in Figure 9-1.
Figure 9-1: The AP:Notification formBasic tab

4 In the Notification Name field, type a name for the notification.


5 In the Process Name list, select the appropriate process.

The process must already exist. See Creating a process on page 98.
6 In the Status field, set the notification to Active or Inactive.

This option enables or disables this notification. To enable or disable the events
that trigger all notifications, use the AP:Admin-ServerSettings form. See
Configuring settings on the Notifications tab on page 31.
7 In the Notify On field, select one of the following options from the list. This field

specifies the approval cycle event that triggers the notification.


Table 9-3: Notify On Options (Sheet 1 of 3)

160

Option

Triggering event

New Signature

A new signature line is added to the approval Approver list.


request.

Approve

The approval request is approved.

Approver list minus


current approver.

Reject

The approval request is rejected.

Approver list minus


current approver.

Alternate
Approve

An alternate approves the approval request.

Individual
Approved for.

BMC Remedy Approval Server Guide

Default notify list

Creating notifications

Table 9-3: Notify On Options (Sheet 2 of 3)


Option

Triggering event

Default notify list

Alternate Reject

An alternate rejects the approval request.

Individual
Approved for.

Override Approve A user with override capability approves the


approval request.

Approver list.

Override Reject

A user with override capability rejects the


approval request.

Approver list.

Global Approve

An administrator performs a global approve,


terminating a process for a request.

Approver list.

Global Reject

An administrator performs a global reject,


terminating a process for a request.

Approver list.

Reassign

An approval is reassigned to a different


approver.

Approver list.

Error

An error exists in the approval signature.

Individual who
approved or
rejected.

Cancel

An approval request is cancelled.

Approver list.

More Info Return

A request for more information is fulfilled.

Individual who
requested more
information.

Reject by Later
Level

The approval request is rejected after this


signature is approved.

Approver list.

Cancel at Later
Level

The approval request is cancelled after this


signature is approved.

Approver list.

Reject by Another The approval request is rejected by another


Approver
signature record.

Approver list.

Hold

An approval request is put on hold.

Approver list minus


current approver.

More Info

More information is requested by an approver. Approver list minus


current approver.
Does not include
requester.

Still Active

An approval request is in an approval pending Approver list.


state and no action has occurred.

Still Active
(repeat)

A Still Active notification has been sent and no Approver list.


action has occurred.

Still Pending

An approval request is on hold in the approval Approver list.


cycle and there has been no action.

Still Pending
(repeat)

A Still Pending notification has been sent and


no action has occurred.

Still Hold

A Hold notification has been sent and no action Approver list.


has occurred.

Still Hold (repeat) A Still Hold notification has been sent and no
action has occurred.

Chapter 9

Approver list.

Approver list.

Adding approvals to your application

161

BMC Remedy Action Request System 7.6.04

Table 9-3: Notify On Options (Sheet 3 of 3)


Option

Triggering event

Still More Info

More information has been requested for an


Approver list.
approval request and there has been no action.

Still More Info


(repeat)

A Still More Info notification has been sent and Approver list.
no action has occurred.

Still Error

An error in the approval cycle has occurred


and there has been no action to correct the
error.

Still Error (repeat) A Still Error notification has been sent and no
action has occurred to correct the error.

Default notify list

Approver list.

Approver list.

Change After
Approved

A change occurs that all past approvers should Approver list.


know about.

Before Reassign

A request is reassigned to a different approver. Approver list.

NOTE
If you choose the Before Reassign option, a notification is sent to the approvers
who are being replaced.
8 In the Qualification area, enter a condition statement to help control whether the

notification runs, if necessary.


The Additional Conditions field enables you to add conditions to the setting in the
Notify On field.
9 Click the Details tab.
Figure 9-2: The AP:Notification formDetails tab

10 In the Method list, select one of the following notification options:

162

No MessageSend no notification.

BMC Remedy Approval Server Guide

Creating notifications

AlertUsers are notified when they run BMC Remedy Alert. For more
information about BMC Remedy Alert, see BMC Remedy User Help.

EmailUsers are notified by email.


If the contents of the Send To field do not match an existing user or group
definition, the system interprets the field contents as a literal address and sends
the notification to that address by SMTP mail (UNIX) or MS-Exchange
(Windows). When you use this option, you can send notifications to users not
using the AR System, to an alias for a group, or to an email address representing
a program.

User DefaultUsers are notified by the default notification method defined in


the User record. If the User record does not contain a default notification
method, BMC Remedy Alert is used.

WorkflowTriggers a filter guide that fires on the required event and sends the
notification.
To use this option, you must add the appropriate workflow to your application.
See Creating workflow-based notifications on page 165.

11 Select a Priority for the notification from 0 to 10.

This enables users to sort notifications in order of importance.


12 Select an option for the Send To field, which indicates where to send the

notification.
Notifications are sent to users or roles, or the approval server can write to a form
field.

Notify ListSend to the default notify list for the selected Notify On option. See
Table 9-3 on page 160.

OtherSpecify an individual, a group, a list of individuals or groups, or a field


reference to a field containing individuals or groups.

13 Enter a Subject line for the notification message.


14 To include field values in the subject line, use the Subject drop-down list.

The Subject panel lists fields from the applications three-way join form. Select the
field whose value you want to include in the subject line, and click OK.
15 To attach more field information to the notification, use the Additional Fields field.

Enter field names in the text box or select field names from the drop-down list.
16 To include field values in the message text, use the Message drop-down list.
17 For email or User Default notifications, click the Email tab.

The fields in the Email tab are the same as those used when you create an Email or
User Default notify mechanism in a Notify filter action. For information about
using email notifications and configuring BMC Remedy Email Engine, see the
BMC Remedy Email Engine Guide.

Chapter 9

Adding approvals to your application

163

BMC Remedy Action Request System 7.6.04

Figure 9-3: The AP:Notification formEmail tab

The menus in the Fields columns on this tab contain fields from the three-way join
form. You can select from the Fields and Keywords menus to use variables in all
the fields on this tab.
18 In the Mailbox Name field, enter the name of an outgoing mailbox that is

configured in the AR System Email Mailbox Configuration form. This field is not
required if you use the default outgoing mailbox.
You can use a field or a keyword to get the mailbox name. The mailbox name must
correspond to an outgoing mailbox configured in the AR System Email Mailbox
Configuration form.
19 Enter the appropriate information in the From, Reply To, CC, and BCC fields.

You can use AR System user names, AR System groups, an email address, or a
field or keyword variable. To use an email address, include the email domain
name (for example, Joe.User@acme.com) or a keyword (for example,
$USER$@acme.com). If you make multiple entries in these fields, separate the
entries by hard returns.
The Email Engine uses these fields as follows:

FromIndicates the sender.

Reply ToSpecifies the reply-to address if the recipient replies to the


notification message.

CCSpecifies recipients of the notification.

BCCSpecifies hidden recipients of the notification. The names of recipients in


the BCC field do not appear to other recipients of the message.

20 In the Organization field, enter a company name, an organization, a keyword, or a

field reference to an organization name.


This name appears in the Organization tag of the email header.

164

BMC Remedy Approval Server Guide

Creating notifications

21 In the Header, Content, and Footer fields specify the names of the email templates

to use for the header, content, and footer of the email notification.
22 (Optional) Click the Administrative Information tab (optional) and enter Help Text

that describes this notification.


23 Click Save.

Creating workflow-based notifications


AR System application designers can use workflow-based notifications for
approval events. Workflow-based notification provides a way for approval events
to be propagated to a customized notification system.

To enable workflow-based notifications


1 Follow the procedures to add an application to the AR System. See Connecting an

application to the approval server on page 152.


2 Verify that the three-way join form for the application contains the following fields

from the AP:Detail-Signature form:

Notification Message (ID 12303)

Subject (ID 12305)

Additional Fields (ID 12340)

Process Instance ID (ID 13021)

If the three-way join form existed before you upgraded to version 7.x.xx of the
approval server, you must add these fields to it.
3 In the AP:Notification form, create a notification for your process. See Defining

an email or BMC Remedy Alert notification on page 159.


4 In the Details tab, select Workflow in the Method list.
5 In BMC Remedy Developer Studio, create a filter with the following workflow

actions:
a Create a Set Fields action that pushes message details from the AP:Notification

form to the display-only fields that you added to the AP:Detail form.
For example, push the value from the Subject field on AP:Notification to the
Subject display-only field on AP:Detail.
b Create a Call Guide action that selects the AP:Workflow Notifications Guide

filter guide.
The AR System installation program adds this filter guide to the server. The
filter guide was created in the 7.0.00 release for use with workflow-based
notifications.
6 Add your filter to the AP:Workflow Notifications Guide.

When the approval event triggers the notification, the AR System fires the filter
that sends the notification.

Chapter 9

Adding approvals to your application

165

BMC Remedy Action Request System 7.6.04

Enhancing your approval forms


This section introduces several techniques that you can use with your approval
forms to provide a richer integration for your users. These techniques include:

Adding workflow to your approval server forms, such as buttons, to automate


common tasks.

Adding a dynamic field to the three-way join form, such as the Password field.

Adding a field menu of valid approver names.

Add workflow to your approval server forms


The three-way join forms in the sample applications each have a button labeled
Manage More Information. This button opens a dialog box that allows the user to
review and respond to the More Information requests associated with the current
approval request. The AP-Sample:Lunch Scheduler form contains the buttons
Show Approval Summary and Show Signatures, which allow approvers to
see signature details about the current request.

NOTE
To use similar buttons in your application, you must add them to the appropriate
form, and create the workflow to implement them. One way to do this is to copy
the workflow objects from the sample applications.
This section describes how to create a Manage More Information button on the
three-way join form for your application. You can use a similar procedure to add
the Show Approval Summary and Show Signatures buttons.
The Manage More Information button in the sample applications links to the
AP:Dtl-Sig-MoreInfoDialog form, which enables you to create More Information
records and lists the existing ones. However, BMC recommends that you use the
appropriate fields on AP:Show-Detail to create such records. See AP:Dtl-SigMoreInfoDialog on page 268 and AP:Show-Detail on page 271.
To see how the Manage More Information button works in the sample
applications, use BMC Remedy Developer Studio to review the button on the
AP-Sample:Lunch-Detail-Signatu form. Also review the active links
AP-Sample-Dtl-Sig:MoreInfo01 through AP-Sample-Dtl-Sig:MoreInfo06.
For information about adding fields to forms, including buttons, Form and
Application Objects Guide, Creating and managing fields, page 183.
For information about creating active links, see the Workflow Objects Guide.

To add a Manage More Information button


1 Create a button on the three-way join form for your application. The name of the

button is not critical to its function.


2 Assign the field ID 13198 and grant the Public permission to the button.

166

BMC Remedy Approval Server Guide

Enhancing your approval forms

3 Make a copy of each active link named AP-Sample-Dtl-Sig:MoreInfo01 through

AP-Sample-Dtl-Sig:MoreInfo06:
a Open the active link to be copied.
b Choose File > Save Active Link As.
c Give the new copy a name that is appropriate for your application.
d In the Form Name field, select the three-way join form and deselect the sample

application forms.
e Save the changes.
Figure 9-4: Copying AP-Sample-Dtl-Sig: MoreInfo01 through MoreInfo06

Save active link with


a new name.
Select your three-way join
form.

Show the password field in the detail view


When you configure a process to require approver passwords, the Approve and
Reject buttons on Approval Central automatically open a password dialog box that
prompts the user to enter the correct password when acting on the request.
However, if the approver clicks View on Approval Central to view the request
details, by default the password field does not appear in the detail view.
The detail view displays the three-way join form for your application. To allow
approvers to enter a password in this view, you must make the Password field
(field ID 102) visible on the three-way join form. This field comes from the
AP:Signature form and is present in the join form, but it is hidden by default.
If your application has only one approval process, or if all the processes in the
application require a password, simply position the Password field on the threeway join form, and make the field visible by deselecting the Hidden characteristic.
If your application contains more than one process but not all processes require a
password, you can cause the Password field to appear on the three-way join form
only when necessary. The Lunch Scheduler sample application contains an
example of this functionality, which you can copy to your application.
In the Lunch Scheduler three-way join form (AP-Sample:Lunch-Detail-Signatu),
two active links run when the form is displayed. The first active link checks
whether the current process requires a password, and sets the result in a
temporary field. The second active link tests the value of the temporary field and
makes the password field visible on the three-way join form.

Chapter 9

Adding approvals to your application

167

BMC Remedy Action Request System 7.6.04

The following procedure shows how to make the password field visible on the
three-way join form for your application when the process requires it.

To display the Password field dynamically


1 Use BMC Remedy Developer Studio to position the Password field (ID 102) in an

obvious location on your three-way join form.


2 Copy and save the following two active links with new names appropriate to your

application (use File > Save Active Link As):

AP-Sample:ShowPwdIfRequired1

AP-Sample:ShowPwdIfRequired2

3 In the Form Name field for each active link, select the three-way join form and

deselect the sample application form.


4 Save the changes.

Add a field menu of valid names


To prevent typographical errors when users enter approver names in an Ad Hoc
process or an ad hoc override, you can provide a field menu that contains valid
approver names. Examples of fields for which a menu of valid names can help
prevent errors are as follows:

AP:Alternate form, Alternate field

AP:More Information form, To field

AP:Detail-Signature form, Reassign To field

See the Form and Application Objects Guide, Creating menus, page 299.

Adding previews to your approval application


The approval server preview feature allows approvers to view a list of all the
approvers for a request, on all levels of an approval hierarchy. To cause the
approval server to generate a list of approvers for a process, you configure a value
in the Generate Approvers field of the Process Definition form. The approval
server gathers this data at the appropriate stage of the approval process and stores
it in the AP:PreviewInfo form.
To allow users to view this list and to add approvers at run time, you create a form
that retrieves the list from the AP:PreviewInfo form, and gathers data interactively
from the user for the Add-PGNA-Values command. The preview feature is
designed to work with a Parameterized Get Next Approver Rule.

168

BMC Remedy Approval Server Guide

Adding previews to your approval application

To retrieve the list of approvers for a request the AP:PreviewInfo form requires the
process name, request ID, and the type of preview as input. You can provide these
values in the ShowForProcess, Request/Ticket Number, and Retrieval Type fields.
You can specify one of the following retrieval types:

FullShows completed, pending, and future approval signatures.

RemainingShows pending and future approval signatures.

CompletedShows completed and future approval signatures.

As shown in Figure 9-5, the preview list includes the status of the signatures.
Figure 9-5: The AP:PreviewInfo form

To allow users to preview and add approvers


1 Create a form that will display the preview list and gather the information from the

user to add another approver.


2 Create a table field on the form that queries the AP:PreviewInfo form.

For example, Figure 9-6 illustrates a form that retrieves the approver list for a
request in the Lunch Scheduler sample application, and prompts users to enter the
level and name of an added approver.
For information about creating forms and retrieving data from another form, see
the Form and Application Objects Guide.

Chapter 9

Adding approvals to your application

169

BMC Remedy Action Request System 7.6.04

Figure 9-6: Example form with preview table and input fields

3 Create filter workflow that executes the Add-PGNA-Values command, for

example:
Application-Command Approval Add-PGNA-Values -t $Signature ID
add$ -o $Rule Name$ -l $Short Description$

This command stores the added approver values, such as level and approver
name, for use by a Parameterized Get Next Approver rule.

Multi-process preview
The multi-process preview appears as a flowchart or a table that lists all the
approvers whose signatures are required for the approval processes to be
completed. Multiple processes appear in the sequence in which they are supplied
to the Generate-Multi-Process-Preview application command. For more
information, see Generate-Multi-Process-Preview on page 186.
Application developers can integrate this feature using this application command
to pass required input values to the approval server, which are then stored in the
AP:Preview Data form.
After the required data is available with the approval server, application
developers can generate the preview in two ways:

170

Navigate to Approval Central, search for and select a request, and click View
Details to see the flowchart or tabular view on the Approver tab of AP:ShowDetail.

For the flowchart view, invoke a predefined view from any form.
For the tabular view, create your own table, based on the AP:PreviewInfo form,
by passing the relevant qualification.

BMC Remedy Approval Server Guide

Using a custom ad hoc dialog box with the approval server

Using a custom ad hoc dialog box with the


approval server
By default, the approval server provides the AP:AdhocDialog form to work with
ad hoc approvers for a request. For more information, see AP:Show-Detail on
page 271.
To specify a different form from which to retrieve the details of an ad hoc approver,
use the Adhoc Form field on AP:Process Definition. You will also need to create an
alternative to the AP:AdhocDialog form.

NOTE
All information about ad hoc approvers is stored in the AP:AdhocDetails form,
irrespective of which Adhoc Form is specified on AP:Process Definition.
To add a new ad hoc approver, customized applications must push the values of
the following fields to AP:AdhocDetails from their customized ad hoc dialog box:
Table 9-4: Custom ad hoc dialog box fields mapped to the AP:AdhocDialog form
Field name

Field ID Description

Name

10009

Set to the ad hoc approvers name or a role name. If set to a role


name, the specified role is expanded to include all the approvers
associated with that role.

Sequence

10001

Set to a valid sequence ID. A valid value is the current or the


future sequence of the process. A sequence number that has been
passed is not allowed.

If Multiple

10010

If set to All, each approver has a separate signature line created


against their name. If set to One, only one signature line is created
for all the approvers.

Independent 10011

If set to Yes, the approval server does not wait for this signature
line to be signed before proceeding to the next level of the process
or to the next process in the chain. If set to No, the approval server
waits for the ad hoc signature to be marked as approved before
proceeding to the next level of the process or the next process in
the chain.

Signature Id 10006

Set to the signature ID for which the ad hoc approver is being


added.

Locked

Set to Yes to indicate that this record is ready to be used for the
corresponding request.

10012

To delete an ad hoc entry, customized applications must first retrieve the request
ID of the record from AP:AdhocDetails by passing the Name, Sequence, and Detail
ID fields. The request ID is used to fire the standard AR System server application
command Application-Delete-Entry to delete the ad hoc approver. For
example, the command to delete the entry on the current form with the entry ID
found in the core field 1 (Request ID) is:
Application-Delete-Entry $SCHEMA$ $1$
Chapter 9

Adding approvals to your application

171

BMC Remedy Action Request System 7.6.04

172

BMC Remedy Approval Server Guide

Appendix

Upgrading the approval


server
BMC Remedy Approval Server (approval server) 7.6.04 is available for the
Windows, Linux, and UNIX operating systems. For information about installing
and uninstalling the approval server for both platforms, see the Installation Guide.
The following topics are provided:

The arapupgd utility (page 174)


Running one-time escalations to configure new data (page 175)
Performing required three-way join form updates (page 176)
Using the approval server on the Web (page 178)
Mapping application request form fields to AP:Detail fields (page 178)

Appendix A

Upgrading the approval server

173

BMC Remedy Action Request System 7.6.04

The arapupgd utility


Beginning with release 7.1.00, BMC Remedy Approval Server provides an
approval upgrade utility (arapupgd.exe for Windows or arapupgd for UNIX)
that populates data for newer enhancements. This utility runs automatically as part
of the installation. However, if you apply an approval server patch by using the file
replacement method, you need to run this utility manually.
Table A-1 lists the fields whose values the arapupgd utility populates when
upgrading from an earlier release.
Table A-1: Fields populated by the arapupgd utility
Release

Field

7.1.00 or later

Process Instance ID
Requestor

Form

AP:Alternate
AP:Detail-Signature
AP:Notification
AP:Process Administrator
AP:Process Definition
AP:Rule Definition

7.5.00 or later

Full Name (ID 14201)

AP:Signature

7.6.xx or later

Recent History Time (ID 14105)

AP:Signature

The syntax of the approval upgrade utility is as follows:


arapupgd -s serverName -portnum portNumber -i ARSystemInstallDir
-u adminUserName -p adminUserPassword -l logFileDestinationPath
-o true -h true -f true
Table A-2: The approval server upgrade utility parameters (Sheet 1 of 2)
Parameter

Value

The name of the AR System server.

portnum

If the AR System server is configured to run on a port, the appropriate


port number.

The location of the AR System installer.


For example, C:\Program Files\BMC Software\ARSystem

The admin users login ID.

The admin users password.

By default, the AR System suite installer places the upgrade.log file in


ARSystemServerInstallDir/Logs.
If you run this utility manually, you can use this parameter to specify the
location for upgrade.log.
Note: You cannot change the name of this log file.

174

BMC Remedy Approval Server Guide

Running one-time escalations to configure new data

Table A-2: The approval server upgrade utility parameters (Sheet 2 of 2)


Parameter

Value

Indicates the offline mode; use as follows:

If you do not want the activities of this utility to be logged, set this value
to true.
If you want the activities of this utility to be logged, set this value to
false. This might hamper the performance of the AR System server.

Valid only when upgrading to version 7.5.00 or later; use as follows:

To populate full name values on AP:Signature, set this value to true.


Otherwise, set it to false, or do not provide this parameter at all.

Valid only when upgrading to version 7.5.00 or later; use as follows:

To populate recent history time values on AP:Signature, set this value


to true.
Otherwise, set it to false, or do not provide this parameter at all.

If the execution of arapupgd fails during installation or upgrade, you should run
the utility manually. Then, you should restart the approval server or wait for the
cache to be refreshed for the changes to be visible. Even if the utility fails, no data
is lost.

Running one-time escalations to configure


new data
When you upgrade from version 6.3.00 to 7.0.00 or later of the approval server, use
the following escalations:

AP:Common-Set-Process-GUIDSets the value of the Process Instance ID


field to the Process Name for the existing data.

AP:Common-Set-AssigneeGroupSets the value of the Assignee Group


Permission field to Public for the existing data.

NOTE
You must run these escalations only once after upgrading. After the Process
Instance ID and Assignee Group Permission fields are set with the appropriate
values, you should disable these escalations.

Appendix A

Upgrading the approval server

175

BMC Remedy Action Request System 7.6.04

Performing required three-way join form


updates
Two of the new features introduced with version 7.0.00 of the approval server
require new fields in the three-way join form. If you are using version 7.0.00 or
later with older approval server applications, you must add the following
character fields to the three-way join form for your application:

Additional Fields (field ID 12340), Notification Message (field ID 12303),


Subject (field ID 12305), and Process Instance Id (field ID 13021), for the
Workflow-based notifications feature.

Assignee Group Permissions (field ID 112), for the multi-tenancy feature.

The approval server uses Process Instance IDs instead of Process Names.
Therefore, notifications are based on the Process Instance IDs.

NOTE
When you configure a notification for a process, a notification filter is created,
based on the Process Instance ID. If the Process Instance ID is changed by any
means, it is not automatically reflected in the notification filter. You must update
the notification filter manually with the new Process Instance ID.
The three-way join form is the join between the application request form and the
AP:Detail-Signature form. For example, in the Get Agreement sample application,
the application request form is AP-Sample2:Get Agreement, and the three-way
join form is AP-Sample2:Issue Detail Signat.
You can add the new fields to your application in one of the following ways:

By editing the form in BMC Remedy Developer Studio

Beginning with release 7.1.00, by using the arjoinfix utility

This section describes these options.

To add the fields using BMC Remedy Developer Studio


1 Open the three-way join form in BMC Remedy Developer Studio.
2 Right-click on the form, and choose Add Fields from AP:Detail-Signature from the

menu that appears.


3 Select the new required fields, and click OK.
4 Position the fields on the form, and hide them.
5 Save the three-way join form.

176

BMC Remedy Approval Server Guide

Performing required three-way join form updates

To add the fields using the arjoinfix utility


1 UNIX onlyNavigate to ARSystemServerInstallDir and export the directory as

a shared library path, using one of the following commands.

On the Oracle Solaris and Linux operating systems, use:


#export LD_LIBRARY_PATH=/usr/ar/ARSystemServerInstallDir/bin

On the HP-UX operating system, use:


#export SHLIB_PATH=/usr/ar/ARSystemServerInstallDir/bin

On the IBM AIX operating system, use:


#export LIBPATH=/usr/ar/ARSystemServerInstallDir/bin

NOTE
You need to set the library paths on UNIX for all approval server utilities.
2 Run the arjoinfix utility available for your platform.

On Windows, navigate to ARSystemServerInstallDir/approval/bin, and


run arjoinfix.exe.

On UNIX navigate to ARSystemServerInstallDir/approval/bin, and run


the command:
./arjoinfix -i ARSystemServerInstallDir

After starting, the utility prompts:


Enter the name of the form:
3 Enter the appropriate approval request form name, and press Enter.

The following table provides examples of applications and their application


request forms.
Table A-3: Example applications and their application request forms
Application

Application request form

Get Agreement sample application

AP-Sample2:Get Agreement

Lunch Scheduler sample application

AP-Sample:Lunch Scheduler

BMC Remedy Change Management

CHG:Change

BMC Remedy Asset Management

AST:PurchaseRequisition

The utility prompts:


----------Menu---------1. Update Join Criteria
2. Add New Fields In 3-Way Join Form
Default: Quit
Make your choice and Press <enter>:
4 Enter 2 to add the new fields, and press Enter.

The utility adds the five new fields to the three-way join form that is associated
with the application request form you entered.
Appendix A

Upgrading the approval server

177

BMC Remedy Action Request System 7.6.04

NOTE
If you created the three-way join form after installing version 7.0.00 or later of the
approval server, you do not have to run arjoinfix to add these fields. These fields
exist in the AP:Signature form, and automatically become part of the three-way
join form when you create the join. See Creating the join forms on page 153.
For more information about the arjoinfix utility, see Running arjoinfix on
page 156.

Using the approval server on the Web


Beginning with release 7.0.00, you no longer need to use the special Approval Web
application components (APW:Approval Central and related objects) that are
automatically installed with the approval server. Instead, for using the approval
server on the Web, you must:

Install BMC Remedy Mid Tier

Configure the AR System Object List for use with your browser.

For more information about configuring the object list for a browser, see the
BMC Remedy Mid Tier Guide, Enabling the AR System Object List, page 87.
For information about accessing Approval Central in a browser, see Opening
Approval Central on page 37.

Mapping application request form fields to


AP:Detail fields
The upgrade program sets the values of two fields (field IDs 14506 and 14507) on
AP:Detail for active detail records, and maps them to the appropriate fields from
the application request form through the Advanced tab on AP:Form. The Process
Administrator is responsible for mapping the fields 14508, 14509, 14510, 14511,
14512, 14513, and 14514 to the appropriate fields on the application request forms.
For more information about these fields, see AP:Form on page 220.

178

BMC Remedy Approval Server Guide

Appendix

Application commands

To support interaction between the AR System server and BMC Remedy Approval
Server (approval server), you use a special AR System process, ApplicationCommand. You can run this process from filters, escalations, and active links using
the Run Process action.
The following topics are provided:

Using Application-Command processes (page 180)


Approval server commands (page 182)

Appendix B Application commands

179

BMC Remedy Action Request System 7.6.04

Using Application-Command processes


The Application-Command process allows the specification of commands to be
executed by an application. Whenever an Application-Command process is run,
a request is created in the Application Pending form that contains details about the
command. The Application Dispatcher retrieves commands from this form and
passes them to the approval server for processing. If the Application Dispatcher is
not in use, the approval server retrieves commands directly from the Application
Pending form.
Application-Command commands use the Run Process action. As with all Run
Process actions, you should use quotes around a parameter when its value
contains a space, to make sure that it is evaluated correctly.
Application-Command processes exist on the AR System server. If you are
performing an operation from an active link, you must use the syntax that
indicates that the process should be run as a remote process on the server.

For more information about how to use Run Process actions, keywords, and
syntax, see the Workflow Objects Guide and the Integration Guide.

Application command syntax and conventions


The basic command format is:
Application-Command category command [-s formName]
[-e requestID] [-t tag] [-1 field1] [-2 field2] [-3 field3]
[-o otherString<255chars] [-l otherStringUnlimited]

This document uses the following conventions to describe application commands:

Parameters enclosed in square brackets are optional.

Parameters not enclosed in brackets are required.

Braces indicate that you must specify only one of the enclosed values.

Application command parameters


Table B-1 describes the parameters and their expected values in detail. The
category and command parameters are positional. The other parameters are
optional, and can appear in any order after the two positional parameters. If you
supply any parameter that is not defined for the command, it is ignored.
Table B-1: Application command parameters (Sheet 1 of 2)

180

Parameter

Description

category

A character string that identifies which application the command is for;


maximum length: 30 characters. For the approval server, this value is
always Approval.

command

A character string that indicates a specific operation to be performed within


the category; maximum length: 30 characters. Commands for the approval
server are defined in this section.

BMC Remedy Approval Server Guide

Using Application-Command processes

Table B-1: Application command parameters (Sheet 2 of 2)


Parameter

Description

-s

formName is the name of a form to which the command is related.

-e

requestID is the ID of the request to which the command is related. If the


request is in a join form, the request ID string consists of the ID of each
request separated by a vertical bar, such as:
000000000012344|000000000084934
If no request ID is specified, this value defaults to the current entry ID.

-t

tag is a description that is specific to the category and command. It might


be a further identifier for the operation. For example, for many approval
commands, the tag is the name of the approval process.

-1

field1, field2, or field3 is the ID of a field or an integer code


associated with the category or command.

-o

otherString<255chars is a string that provides any further


information; maximum length: 255 characters. For example, you can
provide a list of approvers who are expected to act on this request.

-l

otherStringUnlimited is a string that provides any further


information. For example, you can provide a list of approvers who are
expected to act on this request.
Note: The approval server does not impose a restriction on this string, but its

maximum length might be limited by the AR System database.

NOTE
If the operation is performed from a filter or escalation, the -s and -e parameters
default to the current form name (as the application form name) and the current
request ID (as the application request ID) . Therefore, if the default values are
sufficient, you can omit these parameters.
If the operation is performed from an active link, the AR System server cannot
determine what the current environment is, and these values must be supplied.

Example of an application command


The following command would start the approval process named MyProcess
against the current request:
Application-Command Approval New-Details -s $SCHEMA$ -e
$Request-ID -t MyProcess

TIP
The descriptions of the -s and -e parameters (Table B-1 and the adjacent note) are
applicable to all approval server commands in which they are mentioned, and
therefore, not repeated in the Approval server commands section on page 182.

Appendix B Application commands

181

BMC Remedy Action Request System 7.6.04

Approval server commands


This section lists all commands defined for the approval server. Most of the
commands are used automatically by the approval server and its workflow.
Use these commands as the command parameter for Application-Command
processes. You must precede each command with Application-Command
Approval.

Add-PGNA-Values
Add-PGNA-Values [-t detailID] [-o ruleName] [-l valueList]

This command provides the variable values for the Parameterized Get Next
Approver rule type.
Table B-2: Add-PGNA-Values command parameters
Parameter Description
-t

detailID is the request ID of the AP:Detail record.

-o

ruleName is the name of the Get Next Approver rule that needs these values.

-l

valueList is list of values separated by forward slashes (/).

In the following example, the variables enclosed in quotes are provided to the
approval server for use when the next Parameterized Get Next Approver rule
runs:
Add-PGNA-Values -t 00000000000012 -o Sample Param GNA Rule
-l 4/Frank Williams

WARNING
Do not use a slash (/) character within a valueList parameter, because it is a
separator. For example, if you use the following command, then Williams is
ignored, and the result might not be as expected.
Add-PGNA-Values -t 00000000000012 -o Sample Param GNA Rule
-l "4/Frank /Williams"

182

BMC Remedy Approval Server Guide

Approval server commands

Add-Sig
Add-Sig [-s formName] [-e requestID] [-t processName]
-o {approverList} [-1 {0|1}] [-2 {0|1|2|999}] [-l assigneeGroupID]

This command links to an existing approval details record, and creates one if none
exists. It then adds one or more signature lines for each value of the -o parameter.
Table B-3: Add-Sig command parameters
Parameter Description
-t

processName is the name of an existing approval process.

If supplied, the specified approval process is activated.


If not supplied, the system searches for a process against the specified form.
If only one process is specified, that process is used.
If several processes are specified, an error is reported, and no approval
process starts.
If the same process is attached to more than one approval request form, the
approval server cannot determine which form to use, and an error is
returned.

-o

approverList is the list approvers for whom to add signatures. If omitted,


this command performs no action. Multiple approvers are separated by
semicolons.

-1

Indicates whether the new signature line is identified as independent or


not independent.

-2

1Signature line is not independent


0 or any other valueSignature line is independent

The 2 option indicates the action to take on multiple approvers. 0 (the


default) means one of, 1 means all of, 2 means only one, and 999 means
to pull the value from the process definition.
Indicates the action to take on multiple approvers.

-l

0Default; creates a signature line for all approvers, and the first approver
to act on the request determines the response. The request is withdrawn
from the other approvers.
1Creates a signature line for all approvers, and all approvers must act on
the request.
2Creates a signature line for all approvers, and only one of those must act
on the request. Multiple responses generate an error, and the approval
process stops.
999Uses the value specified for If multiple approvers in the
process definition.

This parameter was added to allow you to pass a value for Assignee Group
Permissions (field ID 112), for use with the multi-tenancy feature.
For more information about multi-tenancy, see the BMC Remedy IT Service
Management Suite 7.6.00 Guide to Multi-Tenancy.

NOTE
If this command is executed for a request that is in the Process Done phase, it
restarts the approval process for that request.

Appendix B Application commands

183

BMC Remedy Action Request System 7.6.04

Det-Approved
Det-Approved [-s formName] [-e requestID] [-t processName]

This command marks the AP:Detail record Approved. Any outstanding


signature lines or More Information records are marked Closed. The Process
Done phase notifies the associated request of the approval. This command
corresponds to an approval by global override.
Table B-4: Det-Approved command parameters
Parameter Description
-t

processName is the name of a process associated with the request.

If supplied, only the associated detail record is updated.


If not supplied, all detail records from all processes associated with the
request are updated.
If the same process is attached to more than one form, all the detail records
associated with this process, regardless of the application, are marked
Approved.

Det-Cancelled
Det-Cancelled [-s formName] [-e requestID] [-t processName]

This command stops an approval process that is in progress, and marks the
AP:Detail record Cancelled. Any outstanding signature lines or More
Information records are marked Cancelled. The Process Done phase notifies the
associated request of the cancellation.
Table B-5: Det-Cancelled command parameters
Parameter Description
-t

processName is the name of a process associated with the request.

184

If supplied, only the associated detail record is updated.


If not supplied, all detail records from all processes associated with the
request are updated.
If the same process is attached to more than one form, all the detail records
associated with this process, regardless of the application, are marked
Cancelled.

BMC Remedy Approval Server Guide

Approval server commands

Det-Error
Det-Error [-s formName] [-e requestID] [-t processName]

This command marks the approval detail item Error. Any outstanding signature
lines or More Information records are marked Closed. The Process Done phase
notifies the associated request of the error. This command is intended only to be
used internally by the approval server.
Table B-6: Det-Error command parameters
Parameter Description
-t

processName is the name of a process associated with the request.

If supplied, only the associated detail record is updated.


If not supplied, all detail records from all processes associated with the
request are updated.
If the same process is attached to more than one form, all the detail records
associated with this process, regardless of the application, are marked
Error.

Det-Rejected
Det-Rejected [-s formName] [-e requestID] [-t processName]

This command marks the approval detail item Rejected. Any outstanding
signature lines or More Information records are marked Closed. The Process
Done phase notifies the associated request of the rejection. This command
corresponds to a rejection by global override.
Table B-7: Det-Rejected command parameters
Parameter Description
-t

processName is the name of a process associated with the request.

If supplied, only the associated detail record is updated.


If not supplied, all detail records from all processes associated with the
request are updated.
If the same process is attached to more than one form, all the detail records
associated with this process, regardless of the application, are marked
Rejected.

Appendix B Application commands

185

BMC Remedy Action Request System 7.6.04

Generate-Multi-Process-Preview
Generate-Multi-Process-Preview [-s formName] [-e requestID]
-l phase:processList; [-o {0|1}]

Creates a multi-process preview request for the associated application request.


Optionally, you might choose to create a single process preview request using the
appropriate parameter. For more information, see Multi-process preview on
page 170.
Table B-8: Generate-Multi-Process-Preview command parameters
Parameter Description
-l

The names of processes to include. If omitted, this command performs no


action. Multiple process names are separated by semicolons.
Optionally, you can include extra information as a prefix to a process name
separated by a colon (:). It could be anything related to the process that you
want to highlight. For example, in the case of BMC Remedy Change
Management applications, you can include phase information.

-o

Indicates whether a single process (0) or multi-process (1) preview should be


generated. If omitted, its value defaults to 1.

Generate-Preview
Generate-Preview [-o Generate-Preview] -e requestID
-s formName [-t processName]

Creates a preview request for a single process based on the future signature lines
found in the AP:PreviewInfo form for the associated application request.
Table B-9: Generate-Preview command parameters
Parameter Description
-o

If specified, the value of this parameter must be Generate-Preview.

-e

requestID identifies the request being processed.

-s

formName must be the application form name.

-t

processName is the name of a process associated with the request.

For example:
Generate-Preview -o Generate-Preview -e $RequestID$
-s AS ADDSIG:Lunch Scheduler
-t AS ADDSIG:Management Cost Authorization

186

BMC Remedy Approval Server Guide

Approval server commands

MoreInfo-Return
MoreInfo-Return [-s formName] [-e requestID]

This command takes data from the specified More Information request and copies
the response back to the associated signature request. The More Information
request must be marked Completed.
Table B-10: MoreInfo-Return command parameters
Parameter Description
-s

If supplied, formName it must be the More Information form.

-e

If supplied, requestID must be the ID of the More Information record.

New-Details
New-Details [-s formName] [-e requestID] [-t processName]
[-1 priority] [-2 processDueDate] [-l assigneeGroupID]

This command starts an approval server process for the specified request.
Table B-11: New-Details command parameters
Parameter Description
-t

processName is the name of a process associated with the request.

If supplied, the specified approval process is activated.


If not supplied, the system searches for a process against the specified form.
If several processes are specified, an error is reported, and no approval
process starts.
If the same process is attached to more than one application form, the
approval server cannot determine which form to use, and returns an error.

-1

If supplied, it sets the priority to Urgent (1), Normal (2), or Low (3). Any other
priority is ignored, and the defaultNormal (2)is applied.

-2

If supplied, this integer value is translated into the Process Due Date and
further used to calculate the action date for the signature; the Process Due
interval defined on AP:Process Definition is ignored in this case.

-l

If supplied, this value is passed to field 112 (Assignee Group Permissions),


which is used to support the multi-tenancy feature.

This command creates an approval details record. It then searches for Auto
Approval and Self Approval rules; if either exists and passes, the command marks
the record Approved and continues with the Process Done phase to update the
associated request. If no Auto Approval or Self Approval rules pass, the first set of
approvers is found and signature lines are created for them as defined by the rules
of the process.
If this command is fired after Add-Sig, and a detail record already exists for the
application request, an error occurs and the process terminates. To fix this issue,
pull the NotAddSig field (field ID 14523) from AP:Detail onto the two-way join
between your application form and AP:Detail, and save the join form.

Appendix B Application commands

187

BMC Remedy Action Request System 7.6.04

Rename-Form
Rename-Form -t oldFormName -o newFormName [-1 activeOnly]
[-2 doRename]

This command changes the name of a form. All references in the definition forms
are updated.
Table B-12: Rename-Form command parameters
Parameter Description
-t

oldFormName is the name of the form that you want to rename.

-o

newFormName is the new name that you want to assign to the form.

-1

This parameter controls which AP:Detail records are updated. If set to 1, only
active entries are updated. Providing any other activeOnly value causes all
entries to be updated.
Note: Requests in the Error state also qualify as active.

-2

This parameter controls the renaming of the form. If set to 1, the form itself is
renamed. If you provide any other doRename value, the approval server
assumes that the form has already been renamed using BMC Remedy
Developer Studio, and you are simply updating the cross-references.

Rename-Process
Rename-Process -t oldProcessName -o newProcessName [-1 activeOnly]
[-2 doRename]

This command changes the name of a process. All references in the related
definition forms are updated. The name of a process can be as long as 80 bytes. This
equates to 80 characters in English and most European languages, but only 40
characters in double-byte languages.
Table B-13: Rename-Process command parameters
Parameter Description
-t

oldProcessName is the name of the process that you want to rename.

-o

newProcessName is the new name that you want to assign to the process.

-1

This parameter controls which AP:Detail records are updated. If set to 1, only
active entries are updated. Providing any other activeOnly value causes all
entries to be updated.
Note: Requests in the Error state also qualify as active.

-2

188

This parameter controls the renaming of the process. If set to 1, the process
itself is renamed. If you provide any other doRename value, the approval
server assumes that the form has already been renamed using the AP:Process
Definition form, and you are simply updating the cross-references.

BMC Remedy Approval Server Guide

Approval server commands

Sig-Approved
Sig-Approved [-s formName] -e requestID [-t processName]

This command performs approval processing on a signature line that has been
marked Approved. The rule process continues to the next approvers.
Table B-14: Sig-Approved command parameters
Parameter Description
-s

If supplied, formName must match the value in the AP:Signature form.

-e

requestID is the ID of the signature entry.

-t

If supplied, processName must match the process name specified in the


AP:Signature form.

Sig-Cancelled
Sig-Cancelled [-s formName] -e requestID [-t processName]
[-1 {0|1}]

This command performs cancellation processing on a signature line that has been
marked Cancelled. The request can be in any active state (Pending, Hold, More
Information, Error) for this operation to be performed. The signature line is
cancelled and the process performs the appropriate actions, depending on whether
other signature lines are active.
Table B-15: Sig-Cancelled command parameters
Parameter Description
-s

If supplied, formName must match the value in the AP:Signature form.

-e

requestID is the ID of the signature entry.

-t

If supplied, processName must match the process name specified in the


AP:Signature form.

-1

Indicates whether the related signature lines should be cancelled.

The default value is 0, in which case the related signature lines are not
cancelled.
If you supply 1, the related signature lines are also cancelled.

For example, signatures are created for two people, Allen and Bob, in an ad
hoc manner, with the All Must Sign option. When Sig-Cancelled is used
to cancel Allens signature with the -1 parameter values:

0only Allens signature is marked Cancelled, and not the related


signature lines.
1both Allens and Bobs signatures are marked as Cancelled.

Appendix B Application commands

189

BMC Remedy Action Request System 7.6.04

Sig-Notify
Sig-Notify [-s formName] -e requestID [-1 numNotifications]

This command causes a notification message to be sent, indicating that the


specified AP:Signature record has exceeded its defined time limit without being
resolved. The notification message is sent to the corresponding form-AP:DetailSignature join.
Table B-16: Sig-Notify command parameters
Parameter Description
-s

If supplied, formName must match the value in the AP:Signature form.

-e

requestID is the ID of an AP:Signature form request.

-1

If supplied, numNotifications indicates the notification value.

0Default value; indicates that this is the initial notification.


Any other valueindicates that this is a repeat notification.

This parameter triggers the delivery of the notification or repeat notification


message.

Sig-Notify-Change
Sig-Notify-Change -s formName -e requestID [-t processName]

This command causes a notification message to be sent, indicating that the


specified entry has been changed. The approval server sends a notification about
the change in the signature status to all users who have previously acted upon a
signature line for a specific entry.
The notification message is sent to the corresponding AP:Detail-Signature join
form after the detail record is rejected or approved by using the Det-Rejected or
Det-Approved command.
The -s and -e parameters are required to identify the entry that has been changed.
Table B-17: Sig-Notify-Change command parameters
Parameter Description
-t

processName is the name of a process associated with the request.

190

If specified, the notification is sent to the appropriate process.


If not specified, the notification is sent to all the processes associated with
the entry.

BMC Remedy Approval Server Guide

Approval server commands

Sig-Notify-State
Sig-Notify-State -s formName -e requestID [-t processName]
[-1 numNotifications] -2 {0|3|4|6|otherState} [-3 {0|1}]

This command causes a notification message to be sent, indicating that the


specified AP:Signature record has exceeded its defined time limit for a given state
without being resolved. The notification message is sent to the corresponding
AP:Detail-Signature join form.
This command gets fired when a user acts on a request through Approval Central.
An administrator can fire this command manually, and the notification is sent if
the signature state has been changed to Hold, More Information, or Error.
A notification can only be sent if the administrator has created AP:Notification
records for the following states: Hold, More Information, Error, Still Pending, Still
Pending (Repeat), Still Hold, Still Hold (Repeat), Still More Information, Still More
Information (Repeat), Still Error, and Still Error (Repeat).
Table B-18: Sig-Notify-State command parameters
Parameter Description
-s

formName must be the AP:Signature form.

-e

requestID identifies the request being processed.

-t

If supplied, processName must match the process name specified in the


AP:Signature form.

-1

If supplied, the approval server uses it to execute this application


command.
If not supplied, the approval server determines the process name using the
formName and requestID.

If supplied, numNotifications indicates the notification value.

0Default value; indicates that this is the initial notification.


Any other valueindicates that this is a repeat notification.

This parameter triggers the delivery of the notification or repeat notification


message.
-2

This parameter specifies the numeric value of the state the notification is for.

-3

It can be set to 0 (Pending), 3 (Hold), 4 (More Information), or 6 (Error).


otherState will default to 0 (Pending).

Provides more information about the notification.

0 (Default)indicates that the notification is for an escalation.


1indicates that the notification is simply a direct notification.
Any other value assumes the default.

Appendix B Application commands

191

BMC Remedy Action Request System 7.6.04

Sig-Reassign
Sig-Reassign [-s formName] -e requestID [-t processName]
{-o shortApproverList | -l longApproverList}

This command reassigns the signature line to another approver list by using either
the -o (for an approver list less than 255 characters) or -l option. The signature line
must be in an active state (Pending, Hold, More Information, Error) for this
operation to be performed.
Table B-19: Sig-Reassign command parameters
Parameter Description
-s

If supplied, formName must be the AP:Signature form.

-e

requestID is the ID of the signature entry.

-t

If supplied, processName must match the process specified by the detail


record that is associated with the signature line.

-o

shortApproverList contains the names of the approvers to whom the


request is to be reassigned, when the length of the approver names does not
exceed 255 characters.

-l

longApproverList contains the names of the approvers to whom the


request is to be reassigned, when the length of the approver names is longer
than 255 characters.
The approval server does not impose an upper limit on the length of this
string. However, it is limited by the BLOB column of the database in use.

Sig-Rejected
Sig-Rejected [-s formName] -e requestID [-t processName]

This command is issued when a signature line is changed to Rejected. It marks the
associated detail line as Rejected.
Table B-20: Sig-Rejected command parameters
Parameter Description

192

-s

If supplied, formName must be the AP:Signature form.

-e

requestID is the ID of the signature entry.

-t

If supplied, processName must match the process specified by the detail


record that is associated with the specified signature line.

BMC Remedy Approval Server Guide

Approval server commands

Update-Config
Update-Config -t settingLabel [-o settingValue]

This command updates administrative configuration settings for the application.


Table B-21: Update-Config command parameters
Parameter Description
-t

settingLabel identifies the specific setting being updated. This label is


defined in arstruct.h and is placed in the ar.cfg (or ar.conf) file.

-o

You can use this parameter as follows:

Omit it to reset settingLabel to its default value.


Mention a settingValue in the format appropriate for the ar.cfg (or
ar.conf) file to change the value of the settingLabel.

Examples of configuration settings:

For the approval notification setting, not specifying this parameter resets all
options to their default values. Otherwise, only the option that is defined in
the settingValue parameter is reset.
For the debug mode setting, other debug options can be defined, and if they
are, this setting takes effect. However, if only 0 or 65536 (the setting for
approval debugging) is set, then only that flag is changed, and other
settings remain as they are in the file.

Note: The approval server immediately applies the changes in settings that are

not start-up-only.

Appendix B Application commands

193

BMC Remedy Action Request System 7.6.04

194

BMC Remedy Approval Server Guide

Appendix

Worksheets

The worksheets in this section are intended to assist you in designing the various
components of BMC Remedy Approval Server (approval server). Reproduce the
worksheets as needed.
The following topics are provided:

Process worksheets (page 196)


Rule worksheets (page 200)

Appendix C

Worksheets

195

BMC Remedy Action Request System 7.6.04

Process worksheets
The following process worksheets help you set up your process and escalations:

Defining a process

More Information escalations

Signature escalations on page 197

You can print one or more of these worksheets at a time on separate pages, and use
them as checklists when setting up your processes and escalations.

Defining a process
Use this worksheet to help you design a process.
Process Name
Form
Type
Request Owner Field
First Approver Field
Approval Success

No more approvals

Completion rule

If Multiple
Approvers

One Must Sign

All Must Sign

Allow Ad Hoc Next


Approver?

Anyone

Approver

For Self Assignment

Use Get Next


Approver Rules

Assign to
Owner If
Approver

Validate Approvers?

Yes

No

Require Password?

Yes

No

Allow Only One


Approver
No one
Always Assign to
Owner

More Information escalations


Use this worksheet to help you set the More Information escalations parameters on
the Process form.
Business Calendar
Holiday Calendar
Notification: Still Outstanding

196

First Interval

Unit

Repeat Interval

Unit

BMC Remedy Approval Server Guide

Process worksheets

Signature escalations
Use the following worksheets to help you set the Notification parameters on the
Process form.

Normal priority notifications


Use Schedules
Business Calendar
Holiday Calendar
Automatic Action
After Interval
Change State

Unit
o Pending

o Approved

o Rejected

Notification: Still Outstanding


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StatePending


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateError


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateHold


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateMore Information


First Interval

Unit

Repeat Interval

Unit

Appendix C

Worksheets

197

BMC Remedy Action Request System 7.6.04

Urgent priority notifications


Use Schedules
Business Calendar
Holiday Calendar
Automatic Action
After Interval
Change State

Unit
o Pending

o Approved

Notification: Still Outstanding


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StatePending


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateError


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateHold


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateMore Information

198

First Interval

Unit

Repeat Interval

Unit

BMC Remedy Approval Server Guide

o Rejected

Process worksheets

Low priority notifications


Use Schedules
Business Calendar
Holiday Calendar
Automatic Action
After Interval
Change State

Unit
o Pending

o Approved

o Rejected

Notification: Still Outstanding


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StatePending


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateError


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateHold


First Interval

Unit

Repeat Interval

Unit

Notification: Still in StateMore Information


First Interval

Unit

Repeat Interval

Unit

Appendix C

Worksheets

199

BMC Remedy Action Request System 7.6.04

Rule worksheets
Use the following worksheets to help set up your rules:

Auto Approval rules

Get Authority rules on page 200

Get Authority Self rules on page 201

Self Approval rules on page 201

Validate Approver rules on page 201

Prep Get Next Approver rules on page 202

Get Next Approver rules on page 202

Get Authority Regular rules on page 203

Parameterized Get Next Approver rules on page 203

Signature Accumulator rules on page 204

Statistical Override rules on page 204

Completion rules on page 204

Approval Process Done rules on page 205

Auto Approval rules


Rule Name
Purpose
For Process
Rule
Audit Text

Get Authority rules


Rule Name
Purpose
For Process
Run If
Qualification
Set Fields Type

o Value

o Query

o SQL

From Form
On Server

Server

Qualification
Set Field

200

BMC Remedy Approval Server Guide

Value

o Process

o Other

Rule worksheets

Get Authority Self rules


Rule Name
Purpose
For Process
Run If
Qualification
Set Fields Type

o Value

o Query

o SQL

o Process

o Other

o Process

o Other

From Form
On Server

Server

Qualification
Set Field

Value

Self Approval rules


Rule Name
Purpose
For Process
Rule
Audit Text

Validate Approver rules


Rule Name
Purpose
For Process
Run If
Qualification
Set Fields Type

o Value

o Query

o SQL

From Form
On Server

Server

Qualification

Appendix C

Worksheets

201

BMC Remedy Action Request System 7.6.04

Prep Get Next Approver rules


Rule Name
Purpose
Rule Type
Run If Statement
Set Fields Type

o Value

o Query

o SQL

o Process

o Other

From Form
On Server

Server

Qualification
Set Field

Value

Get Next Approver rules


Rule Name
Purpose
Rule Type
If Multiple
Results

o Value from First

o Values from All

o Return Error

o clear

If Multiple
Approvers

o One Must Sign

o All Must Sign

Next Approver
Rule Is

o Additive

o Ending

o Exclusive

o clear
o clear

Run If Statement
Set Fields Type

o Value

o Query

o SQL

From Form
On Server

Server

Qualification
Set Field

202

BMC Remedy Approval Server Guide

Value

o Process

o Other

Rule worksheets

Get Authority Regular rules


Rule Name
Purpose
For Process
Run If
Qualification
Set Fields Type

o Value

o Query

o SQL

o Process

o Other

From Form
On Server

Server

Qualification
Set Field

Value

Parameterized Get Next Approver rules


Rule Name
Purpose
Rule Type
If Multiple
Results

o Value from First

o Values from All

o Return Error

o clear

If Multiple
Approvers

o One Must Sign

o All Must Sign

Next Approver
Rule Is

o Additive

o Ending

Guaranteed Add o No

o clear

o Exclusive

o clear

o Yes

Run If Statement
Set Fields Type

o Value

o Query

o SQL

o Process

o Other

From Form
On Server

Server

Qualification
Set Field

Value

Appendix C

Worksheets

203

BMC Remedy Action Request System 7.6.04

Signature Accumulator rules


Rule Name
Purpose
For Process
Run If
Qualification
Set Fields Type

o Value

o Query

o SQL

o Process

o Other

o Process

o Other

From Form
On Server

Server

Set Field

Value

Statistical Override rules


Rule Name
Purpose
For Process
Run If
Qualification
Set Fields Type

o Value

o Query

o SQL

From Form
On Server

Server

Set Field

Value

Completion rules
Rule Name
Purpose
For Process
Rule

204

BMC Remedy Approval Server Guide

Rule worksheets

Approval Process Done rules


Rule Name
Purpose
For Process
Rule State

o Approved

Set Fields Type

o Value

o Rejected

o Query

o Cancelled

o SQL

o Process

o Error
o Other

From Form
On Server

Server

Set Field

Value

Appendix C

Worksheets

205

BMC Remedy Action Request System 7.6.04

206

BMC Remedy Approval Server Guide

Appendix

Approval forms

This section describes all the BMC Remedy Approval Server (approval server)
forms and their fields.
AR System administrators, process administrators, and approvers can access the
most important approval server functionality in the Approval Central and
AP:Administration forms. For example, the best practice is to use
AP:Administration to access the AP:Server Settings and AP:Admin-Rename
forms, rather than opening the helper forms independently.
The following topics are provided:

Administration forms (page 208)


User forms (page 255)

Appendix D

Approval forms

207

BMC Remedy Action Request System 7.6.04

Administration forms
Administration forms are used either by approval administrators to manage
process settings, or by the approval server to manage data.

AP:AdhocDetails
This form stores the information entered through AP:AdhocDialog. See
AP:AdhocDialog on page 263.
Figure D-1: AP:AdhocDetails form

Table D-1: Fields on AP:AdhocDetails (Sheet 1 of 2)


Field

Description

Name

The name of the ad hoc approver.

Sequence

The sequence at which the ad hoc approver is added.

If Multiple

Independent

208

OneIndicates that at least one ad hoc approver must approve the


corresponding request.
AllIndicates that at all the ad hoc approver must approve the
corresponding request.
YesIndicates to the approval server that the request can proceed to
the next level of its process without waiting for the signature of the
current ad hoc approver.
NoIndicates to the approval server that the current ad hoc
approvers signature is required before the request can proceed to the
next level of its process.

Signature ID

The signature ID for which the ad hoc approver is added.

Detail ID

The detail ID corresponding to the signature for which the ad hoc


approver is added.

Process Name

The name of the process to which the corresponding request belongs.

BMC Remedy Approval Server Guide

Administration forms

Table D-1: Fields on AP:AdhocDetails (Sheet 2 of 2)


Field

Description

Form Name

The application request form through which the request was created.

Current
Sequence

The current sequence of the corresponding process.

Application
Request ID

The request ID of the application through which the corresponding


request was created.

Locked

YesIndicates to the approval server that the ad hoc approver entry


is ready to be associated with the corresponding approval request.
NoIndicates to the approval server that the ad hoc approver entry
is not to be associated with the corresponding approval request.

Note: When AP:AdhocDialog is used to add ad hoc approvers, this field

is set to Yes by default.


SigToBeDeleted

When an ad hoc approver entry is deleted, this field is used to indicate


the corresponding signature entry that should be deleted.

For more information, see Using a custom ad hoc dialog box with the approval
server on page 171.

AP:Administration
Process administrators use this form to create and modify the records that make
up approval processes. See Using the approval server Administration form on
page 24.
Figure D-2: AP:Administration formProcess tab

Appendix D

Approval forms

209

BMC Remedy Action Request System 7.6.04

Table D-2: Fields on AP:Administration


Field

Description

Show for process

Use the menu to limit the display list to items associated with the
selected process. This field is not active for the Role and Form
categories.

Process, rule,
notification, role,
form, administrator,
alternate

Click a tab to display a list of items of that type. This also selects
which category of items is used when you click the buttons on this
form.

View

Click this button to open the item selected.

Search

Click this button to open a search form for items of the category
determined by the current tab.

Create

Click this button to create a new item of the category determined


by the current tab.

Delete

Click this button to delete the currently selected item.

Refresh

Click this button to reload the displayed list.

Server settings

Click this link in the navigation pane to open the Server Settings
form. See AP:Admin-ServerSettings on page 212.

Rename

Click this link in the navigation pane to open the AP:AdminRename form. See AP:Admin-Rename on page 210.

AP:Admin-DeleteVerify
This dialog box appears when a process administrator tries to delete an entry in
AP:Administration. The entry could be a process, rule, notification, role, form,
another process administrator, or an alternate approver.
You can delete only one entry at a time. When you select a process and click Delete,
the dialog indicates that if you proceed, the associated rules, notifications, and
administrators are also deleted.

Click Yes to delete the entry. The corresponding record in AP:QuestionComment-Info is deleted.

Click No to close the dialog box without deleting the entry.

AP:Admin-Rename
This dialog box appears when a process administrator selects Rename in the
navigation pane of the Administration form.

210

BMC Remedy Approval Server Guide

Administration forms

Figure D-3: AP:Admin-Rename dialog box

Table D-3: Fields on AP:Admin-Rename


Field

Description

Select the type of object Select Process to rename a process, or Form to rename a form.
to be renamed
Select the form to be
renamed /

Select the process name from the menu. When AR System


supplies the GUID, select the supplied GUID.

Select GUID of the


process to be renamed
Enter new process
name /
Enter new form name
Scope of update

Type the replacement name for the process or form.


The name of a process can be as long as 80 bytes. This equates to
80 characters in English and most European languages, but only
40 characters in double-byte languages.
Select an option from the menu to determine which of the
associated detail records are renamed.

Including object itself

All Requests renames all detail records for current and past
approval requests associated with the form or process.
Only Active Requests renames detail records only for
currently open approval requests associated with the form or
process.
Select this check box to include the form or process you are
renaming.
Deselect this check box if you have already renamed the form
or process manually, and are now renaming the associated
requests.

Rename

Complete the rename operation.

Cancel

Close the form with no action performed.

Appendix D

Approval forms

211

BMC Remedy Action Request System 7.6.04

NOTE
If you renamed a process manually instead of using the Rename dialog box, the
Rename command will not change names of attached rules. You must restore the
process name manually and rename the entire process. Or you can rename all the
attached rules using the Rename dialog box.

AP:Admin-ServerSettings
Process administrators use this form to change server settings for the approval
server. To open this form, select Server Settings in the navigation pane of the
AP:Administrator form.

Basic tab
Figure D-4: AP:Admin-ServerSettings formBasic tab

Table D-4: Fields on AP:Admin-ServerSettingsBasic tab (Sheet 1 of 2)


Field

Description

Logging Settings
Approval Debug Mode Select this check box to enable approval server logging.
Log File Name

212

BMC Remedy Approval Server Guide

Type the directory path and file name for the log file.

Administration forms

Table D-4: Fields on AP:Admin-ServerSettingsBasic tab (Sheet 2 of 2)


Field

Description

Other Settings
Definition Check
Interval

Type a number of seconds to define how often the approval


server checks the definitions for changes.
A larger number increases AR System performance by checking
less often. A smaller number of seconds is useful while creating
and testing a process. A zero (0) in this field causes the system to
check for definition changes with each operation.
Note: When testing custom applications, after creating a process,

you should wait until the Definition Check Interval period


before creating requests. Otherwise, the processing of requests
fails, and the following error is written to the logs:
No join between applicationFormName and the
approval detail form.
Private AR Server RPC Type the RPC socket number of a private queue to use when
Socket
accessing the AR System server.
Leave this field empty if you do not use a private queue.
Plugin Loopback RPC
Socket

Type the RPC socket number of a private queue used for


loopback calls.
Leave this field empty if your server does not use a dedicated
queue for loopback calls.

Due-Soon Interval

Type the duration after which approval requests that are due for
action should be highlighted on Approval Central. Use the
adjacent drop-down list to specify whether this duration should
be measured in hours or days.
This interval is subtracted from the value of the Automatic
Action interval defined at the process level. Accordingly,
requests are displayed as due-soon approvals on Approval
Central. For more information, see Approval Central on
page 255.
For example, if the process states that the automatic action
interval for a request is five days, and the Due-Soon Interval is
four days, the request appears as a due-soon approval for the
relevant approver one day before the automatic action is due.

Recent History Interval Type the duration within which a user can see in the recent
history an approval request that was submitted or acted upon.
Select the unit of measurement (Hours or Days) using the
adjacent drop-down list.
This affects My Recent Approvals on Approval Central. See
Approval Central on page 255.

Click Save to apply your changes, Reset to reload the form with the previously
stored values, and Close to close the dialog box without saving any changes.

Appendix D

Approval forms

213

BMC Remedy Action Request System 7.6.04

Notifications tab
The Notifications tab allows you to enable or disable notifications for various
approval server events.
Figure D-5: AP:Admin-ServerSettings formNotifications tab

You can specify whether or not to send notifications on the following events:

New Signature
Approve
Reject
Alternate Approve
Alternate Reject
Override Approve
Override Reject
Global Approve
Global Reject
Reassign

Error
Cancel
More Info Return
Reject by /at Later Level
Cancel at Later Level
Reject by Another Approver
Hold
More Info
Change After Approval / Approved
Before Reassign

When any of these event types occur during an approval process, the approval
server acts according to the following choices:

DisabledNo notifications are sent.

EnabledNotifications are sent to all the approvers.

Enabled Including Alternate (default setting)Notifications are sent to all the


approvers and active alternates.

To use notifications, you must define the specific notifications for each process in
the AP:Administration form.
214

BMC Remedy Approval Server Guide

Administration forms

Escalations tab
Figure D-6: AP:Admin-ServerSettings formEscalations tab

Table D-5: Fields on AP:Admin-ServerSettingsEscalations tab


Field

Description

Still Active

Still Active (repeat)


Still Pending

Still Pending (repeat)


Still Hold
Still Hold (repeat)
Still More Info
Still More Info (repeat)
Still Error
Still Error (repeat)

Disabled means the approval server disables escalations for


this event type during an approval process.
Enabled means the approval server enables escalations for
the approver list when this event type occurs during an
approval process.
Enabled Including Alternate (default setting) means the
approval server enables escalations to the approver list as
well all active alternates when this event type occurs during
an approval process.

These settings enable escalations for each event type. To use


escalations, you must define the specific escalations for each
process in the AP:Process Definition form.

AP:Customize-SourceID
The AP:Customize-SourceID dialog box appears when you click the Customize
link on the Basic tab on AP:Form. This dialog enables you to specify the application
form that opens when users click the Request ID link on Approval Central.

Appendix D

Approval forms

215

BMC Remedy Action Request System 7.6.04

AP:Detail
The AP:Detail form holds all data about an approval request. You can use this form
to determine the status of a request, and to see a history of activity on the request
for any approval process. In addition to the fields described in this section, the
AP:Detail form also includes hidden Currency, Date, and Time fields to store
temporary results during workflow. For example, Currency Field 1 and Currency
Field 2 are temporary fields of the currency type.
Figure D-7: AP:Detail form

Table D-6: Fields on AP:Detail (Sheet 1 of 2)

216

Field

Description

Application

The AR System populates this field the with name of the


approval request form for the request.

Request

The AR System populates this field with the AR System ID for


the request.

Process

The AR System populates this field with the name of the


approval process for the current Detail entry.

Comments

The AR System stores comments entered by approvers in this


field.

Priority

Displays the priority of this request, as set by the process.

Submitter

The AR System populates this field with the AR System user


name of the person who submitted the request.

Status

The AR System populates this field with the status of the


request.

Approval Audit Trail

This field contains an audit trail of date, time, and approver for
actions taken on this request. This information is part of the
permanent record for this request.

Global Approve

Approves the request, overriding the regular approval process.


You must have process administrator override authority to
perform this action. However, the best practice is to use
Approval Central for overrides.

BMC Remedy Approval Server Guide

Administration forms

Table D-6: Fields on AP:Detail (Sheet 2 of 2)


Field

Description

Global Reject

Rejects the request, overriding the regular approval process. You


must have process administrator override authority to perform
this action. However, the best practice is to use Approval Central
for overrides.

Assignee Group
Permissions

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.

Process Instance ID

The AR System populates this field with the GUID for the
process associated with the request.

AP:Detail-Signature
AP:Detail-Signature is a join form that combines data from the AP:Detail and
AP:Signature forms. You link this form to your applications approval request
form to create a three-way join when you add approvals to your application. The
approval server uses this form for internal processing. The visible fields of this
form appear by default in the three-way join form, which displays request details.
To open the three-way join form, click Source ID on Approval Central, and click
the Show Signatures button (if implemented) on the application form that appears.
In addition to the fields described in this section, the AP:Detail-Signature form also
includes many hidden fields used to store temporary results during workflow.
Figure D-8: AP:Detail-Signature form

Appendix D

Approval forms

217

BMC Remedy Action Request System 7.6.04

Table D-7: Fields on AP:Detail-Signature (Sheet 1 of 2)


Field

Description

Approval Status

The AR System populates this field with the current status for
the signature record.

Password

PendingThe approval server is waiting for a response to a


request for this signature line.
ApprovedThe request is approved for this signature line.
RejectedThe request is rejected for this signature line.
HoldThe request is on hold for this signature line, so no
approval server actions occur.
More InformationThe approver associated with this
signature line is waiting for a response to a More Information
Request.
CancelledThis request was withdrawn from the approval
process.
ErrorThe approval server detected an error state while
processing this request.
ClosedThis request is ended and operations can no longer
be performed on it.

This field is optional. The administrator should configure it to


appear on the three-way join form when the process has Require
Passwords set to Yes.
Type your password for verification. The approval server
verifies the contents of this field before a Save operation occurs.

Approval Priority

Displays the priority of this request as defined in the approval


process.

Comments

Enter any comments you want to store with the approval


request.

Next Approvers

When the process allows ad hoc approvers to be added, type the


AR System user names of the next approvers.

If Multiple Approvers

If you enter ad hoc approvers, select how the approval process


operates when more than one approver appears in the Next
Approver field.

218

One Must SignA single signature entry is created for all


approvers in the Next Approver field. Only one of those
approvers needs to take action on the request.
All Must SignSeparate signature entries are created for all
approvers in the Next Approver field. All approvers must act
on the request for it to move to the next stage.

Reassign To

Type the AR System user name of an approver to whom you


want to reassign this request.

Approvers

The AR System populates this field with the AR System user


name of the approver for this signature line.

Approval Audit Trail

This field contains an audit trail of date, time, and approver for
actions taken on this request. This information is part of the
permanent record for this request.

BMC Remedy Approval Server Guide

Administration forms

Table D-7: Fields on AP:Detail-Signature (Sheet 2 of 2)


Field

Description

Assignee Group
Permission

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.

For Application

The AR System populates this field with the name of the


approval request form for the request.

For Request

The AR System populates this field with the AR System ID for


the request.

For Process

The AR System populates this field with the name of the


approval process of this request.

Submitter

The AR System populates this field with the name of the person
who submitted the request.

Approver Signature

This field records the AR System user name of the approver who
has responded for this signature line. The name appears only
after an authorized person modifies the Approval Status field.

Alternate Signature

This field records the AR System user name of the alternate


approver who modifies the Approval Status field, if any.

More Information

This field contains More Information requests sent by the


approver for this request and signature line, and the responses
to those requests. The field is not populated until the requestee
responds to the More Information request.

Show Details

Opens the approval request form for this request.

More information

Opens AP:Dtl-Sig-MoreInfoDialog and searches for More


Information requests associated with this approval request.

AP:DynamicLabels
This form enables you to set locale-specific labels for four fields on the AP:ShowDetail form. The default labels for these fields are GL Account, Cost Center, Total
Cost, and Phase, respectively.
Figure D-9: AP:DynamicLabels form

Appendix D

Approval forms

219

BMC Remedy Action Request System 7.6.04

Table D-8: Fields on AP:DynamicLabels


Field

Description

Application

Select an application name.

Process

Select the process for which you want to customize the field labels.

Locale

Select a locale from the menu.

Provide labels for the fields 14508, 14509, 14510, and 14511, and click Save.
For information about where these labels appear, see AP:Form.

AP:Form
This form is linked to the Form tab of AP:Administration. Process administrators
use this form to attach approval request forms to the approval server.

Basic tab
Figure D-10: AP:FormBasic tab

Table D-9: Fields on AP:FormBasic tab (Sheet 1 of 2)

220

Field

Description

Form Name

Select a form on the current server, or type a form name.

Lookup Keyword

Type a keyword to be used by the approval server when


searching for this form. The keyword acts as a permanent search
term, even if the name of the form changes.

BMC Remedy Approval Server Guide

Administration forms

Table D-9: Fields on AP:FormBasic tab (Sheet 2 of 2)


Field

Description

Used By

This field contains the name of the AR System application that


uses this form. AR System populates this field with Approval.

Approval Reporting

Enter the name of a form used for reporting, if any.

Assignee Group
Permission

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.

Search

In Search mode, click this button to perform your search.

Save

In Submit mode, click this button to save your changes.

Close

Click this button to close the window.

Advanced tab
The Advanced tab enables Process administrators to define field mappings for a
request form at the application level. These mappings are not mandatory.
Figure D-11: AP:FormAdvanced tab

Appendix D

Approval forms

221

BMC Remedy Action Request System 7.6.04

The fields on this form are reserved field IDs in the approval server. You can map
them to other fields on the application forms by using the corresponding menus.
The values from the mapped fields are displayed on Approval Central and
AP:Show-Detail. Table D-10 describes where these values appear.
Table D-10: Fields on AP:FormAdvanced tab
Field

Description

Application Request
ID

Map to an application IDit could be the request ID or any other


ID field in the application.
For example, BMC Remedy Change Management uses its own
IDs to represent a particular record, apart from the one
generated by AR System. You can map this field to that field
from the BMC Remedy Change Management application.
The value from the mapped field is displayed on Approval
Central as the Source ID link. If the value is NULL, the request
ID is displayed by default. See Approval Request Summary on
page 263.

Requestor

Map to a user field on the application form.


The value from the mapped field is displayed in the Requester
column on Approval Central.

Field 1 {14506}

The value from the mapped field is displayed in the Summary


column on Approval Central.

Field 2 {14507}

Currently, the approval server does not use Field 2. This field
was used in releases earlier than 7.5.00 to display certain fields
on the approval console.

Field 3 {14508}
Field 4 {14509}
Field 5 {14510}
Field 6 {14511}

The values from the mapped fields are displayed in the top panel
on AP:Show-Detail.
For example, for a request of the Lunch Scheduler sample
application, these values appear against the following labels:

P-C GL Account
P-C Cost Center
P-C Total Cost
P-C Phase

In your application, you can specify the labels that should


appear for these fields on AP:Show-Detail.

Field 7 {14512}

The value from the mapped field is displayed in a tool tip that
appears when you hover on a request on Approval Central.

Field 8 {14513}

The value from the mapped field is displayed in the Notes field
for a request on Approval Central.

Field 9 {14514}

The value from the mapped field is displayed in the Attachment


table on AP:Show-Detail.
Note: You can map this field only to other Attachment fields.

Define Labels

Click to define labels for the fields 14508, 14509, 14510, and
14511, for various applications, processes, and locales.
The AP:DynamicLabels form appears. See AP:DynamicLabels
on page 219.

222

BMC Remedy Approval Server Guide

Administration forms

NOTE
Changing the field mappings on this form only affects new requests. The older
requests retain their original field values.
For information about the Administrative Information tab, see Administrative
Information tab on page 267.

AP:Notification
Process administrators use this form to create and modify notifications sent by
approval processes. This form opens from when you click View or Create from the
Notification tab of AP:Administration.

Basic tab
Figure D-12: AP:Notification formBasic tab

Table D-11: Fields on AP:NotificationBasic tab (Sheet 1 of 2)


Field

Description

Notification name

Type a name for the notification.

Process name

Select the process name from the list. The process must already
exist.

Appendix D

Approval forms

223

BMC Remedy Action Request System 7.6.04

Table D-11: Fields on AP:NotificationBasic tab (Sheet 2 of 2)


Field

Description

Status

Use the drop-down list to select the status of the notification.

ActiveNotification will be sent when the process triggers it.


InactiveThe notification will not be sent.

Process Instance ID

The AR System populates this field with the GUID of the


selected process.

Notify On

Use the drop-down list to select the type of event that will trigger
this notification.
Note: If you choose Error, the notification is sent only if the status

of the request is set to Error in AP:Signature and AP:Detail.


Assignee Group
Permission

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.

Qualification

If necessary, enter additional conditions to control when the


notification is sent. The approval server uses condition in this
field in addition to the Notify On event.

Search

In Search mode, searches the AP:Notification form.

Save

In New mode, saves the notification.

Close

Close the window without saving changes.

Details tab
Figure D-13: AP:Notification formDetails tab

224

BMC Remedy Approval Server Guide

Administration forms

Table D-12: Fields on AP:NotificationDetails tab


Field

Description

Method

Use the drop-down list to define the method of notification.

NoneNo notification is sent.


AlertNotification is sent using BMC Remedy Alert.
EmailNotification is sent by electronic mail.
User DefaultNotification is sent using the default notification
method defined in the User form for each of the recipients. If the
User record does not contain a default notification method,
BMC Remedy Alert is used.

If you select Email or User Default, the Email tab is activated.


Send to

Notify ListThe approval server sends notifications to the default


recipients for the event type. See Table 9-3 on page 160.
OtherIf you select Other, enter the notification recipients in the
field to the right. To use a field reference (for example,
$fieldName$ click the field menu icon.

Subject

Type a subject line for the notification message. You can select
AR System variables from the list.

Additional Fields

To attach additional field information to the notification, use the


drop-down list to select the field names.

Message

Type the message text for the notification. Use the drop-down list to
include AR System variables in the message text.

Priority

Select a priority from 0 to 10 to allow users to sort their notifications


by order of importance. Entries created with an earlier version of the
approval server will default to a Priority of 1.

Email tab
Figure D-14: AP:Notification formEmail tab

Appendix D

Approval forms

225

BMC Remedy Action Request System 7.6.04

Table D-13: Fields on AP:NotificationEmail tab


Field

Description

Fields

Each field on this form includes the Fields button. Use this menu
to select fields from the approval server forms when completing
each field, if appropriate.

Keywords

Each field on this form includes the Keywords button. Use this
menu to select AR System key words when completing each
field, if appropriate.

Mailbox name

Enter the name of the AR System outgoing mailbox that you


want to handle the notifications.

From

Enter a name for the sender of the notification, or select variables


from the Fields and Keywords menus.

Reply To

Enter a name for the Reply-To field of the notification email, or


select variables from the Fields and Keywords menus.

CC

Enter the recipients of the notification email, or select variables


from the Fields and Keywords menus.

BCC

Enter the recipients of the notification email who should receive


blind copies, or select variables from the Fields and Keywords
menus. Recipients entered in this field do not appear in the
recipient list for other users.

Organization

Enter a company name, an organization, a keyword, or a field


reference to a name for the notification email.

Header

Enter the names of templates to use for the header of the email
notification. You can enter the name of the template directly, or
enter a field reference or keyword to retrieve a template name.

Content

Enter the names of templates to use for the content of the email
notification. You can enter the name of the template directly, or
enter a field reference or keyword to retrieve a template name.

Footer

Enter the names of templates to use for the footer of the email
notification. You can enter the name of the template directly, or
enter a field reference or keyword to retrieve a template name.

For information about the Administrative Information tab, see Administrative


Information tab on page 267.

AP:Preview Data
This form stores intermediate data that is used to generate the multi-process
preview for an approval request. See Multi-process preview on page 170.
The field values correspond to the input parameter values of the GenerateMulti-Process-Preview command. See Generate-Multi-Process-Preview on
page 186.

226

BMC Remedy Approval Server Guide

Administration forms

Figure D-15: AP:Preview Data form

Table D-14: Fields on AP:Preview Data


Field

Description

Application Request ID The application request ID.


Application Form Name The application form name.
Preview Type

Indicates whether a single process or multi-process preview is


generated.

Process List

The list of processes separated by semicolons (;).

Phase-Process List

The semicolon-separated list of processes, each prefixed with


some related information and separated by a colon (:).
Some processes might not have any related information
prefixed.

AP:PreviewInfo
The approval server uses this form to store preview data when the process is
configured to generate previews. Process administrators can use this form to
preview all the approvers assigned to work on an approval request.
You must enter data into all the visible fields to search the AP:PreviewInfo form.
See Configuring previews on page 33.
Figure D-16: AP:PreviewInfo form

Appendix D

Approval forms

227

BMC Remedy Action Request System 7.6.04

Table D-15: Fields on AP:PreviewInfo


Field

Description

Request/Ticket
Number

The request ID that you want previewed.

Single/Multi Process

Select the appropriate value to indicate whether you want to


generate a single process or multi-process preview.

Retrieval Type

Users have an option of specifying a value as a qualification for


the query being made.

FullReturns list of all completed signatures (from the


AP:Signature form), and all previews from the preview form.
RemainingReturns list of only the preview signatures
(those that are not yet opened and entered in the AP:Signature
form).
CompleteReturns list of only the signatures that have
already been completed, that is, those that already exist on the
AP:Signatures form, and are still open (Pending/More Info).
You can query the AP:Signature form for this information as
well, but form displays such data in a better format.

Show for Process

Select the process related to the request.

Application Form
Name

Select the application form name related to the request.

AP:PreviewSignatures
The AP:PreviewSignatures form keeps track of signature entries generated as part
of the approval preview feature (except for real-time preview).

NOTE
The approval server uses this form internally, and users must not use this form to
create records manually.
When a signature or detail record-related application command is submitted, the
approval server creates signatures of future approvers in the chain if the Generate
Preview field for the process definition is set to one of the following:

On Request Only

On Start of Process

On Generation or Change to a Signature

These signature records are stored in the AP:PreviewSignatures database schema.


Real-time preview does not use the AP:PreviewSignatures form, because it stores
signature records in-memory.

228

BMC Remedy Approval Server Guide

Administration forms

Figure D-17: AP:PreviewSignatures form

Table D-16: Fields on AP:PreviewSignatures


Field

Description

Approval ID

The application request ID.

Approval Status

The current status of the request.

Approvers

List of approver names separated by semicolons.

AP:Process Administrator
The AP:Process Administrator form opens when you click View or Create on the
Administrator tab in AP:Administration. AR System administrators and process
administrators use this form to create, delete, and modify the abilities of other
process administrators. See Configuring process administrator capabilities on
page 26.
Figure D-18: AP:Process Administrator formProcess Administrator tab

Appendix D

Approval forms

229

BMC Remedy Action Request System 7.6.04

Table D-17: Fields on AP:Process AdministratorProcess Administrator tab


Field

Description

Individual

Enter the AR System user name of the individual who is to be a


process administrator.

Authority

Use the drop-down list to select the privileges allocated to the


individual in the field preceding.

Notify Method

Full AdminGrants the ability to modify processes as well as


the ability to approve or reject a request regardless of the
normal process.
Override Only AdminGrants the ability to approve or reject
a request regardless of the normal process, but not the ability
to create or modify processes.

Use the drop-down list to determine the method for notifications


to this user.

NoneThe approval server does not send a notification.


AlertThe approval server sends the notification using
BMC Remedy Alert.
See the Configuration Guide, Using alerts, page 253.

Covering

This option determines the processes for which this person


receives process administrator privileges.

AllGrants process administrator authority for all Approval


processes defined in the Process Definition form.
Specific ProcessGrants process administrator authority for
the process you select in the Process Name field.

Process Name

Use the drop-down list to select a process name if you selected


Specific Process in the Covering field.

Status

Use the drop-down list to determine the status of this persons


process administration privileges.

230

EmailThe approval server sends the notification through


electronic mail. Notifications can be sent to non-AR System
users, to an alias for a group, or to an email address
representing a program.
User DefaultThe approval server sends the notification
using the default notification method defined in the User form
for each of the recipients. If the User record does not contain a
default notification method, BMC Remedy Alert is used.

ActiveThe process administrator authority is enabled and


the user can immediately work on processes or requests.
InactiveThe process administrator authority is disabled.
This allows you to temporarily suspend authority of the user
when it is not needed, and enable it at a later time.

Search

In Search mode, searches the AP:Process Administrator form.

Save

In New mode, saves the entry to the form.

Close

Close the window without saving.

BMC Remedy Approval Server Guide

Administration forms

For information about the Administrative Information tab, see Administrative


Information tab on page 267.

NOTE
The first process administrator must be created by your AR System administrator.

AP:Process Definition
This form opens when you click View or Create on the Process tab of
AP:Administration. Process administrators use this form to create and modify
approval processes. See Using the Process tab on AP:Administration on page 98.

Basic tab
Figure D-19: AP:Process Definition formBasic tab

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 1 of 7)


Field

Description

Process

Enter a name for this process. Process names must be unique and
must have no more than 254 characters (including spaces). It is
helpful to make the name descriptive of the processs function.

Form

Select the AR System form that you are connecting to the


approval server. This becomes the approval request form.
Note: You must add the form to the Form tab of the

AP:Administration form to make it appear on this menu.

Appendix D

Approval forms

231

BMC Remedy Action Request System 7.6.04

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 2 of 7)


Field

Description

Type

Select the process type from the available options:

Parent-Child
Level
Ad Hoc
Rule-Based

See Approval process types on page 75.


Status

Select the process status from the available options:

Active(Default) The process generates approvals for the


approval request form.
InactiveThe process is disabled and generates no approvals.

You might want to set the status to Inactive during the


development of the process and the associated rules. When all
the appropriate rules are in place, you can modify the process
and set the status to Active.
Requests related to processes in the Inactive state are displayed
on Approval Central, but approvers cannot act upon such
requests. The following message is displayed in such an event:
This action is not allowed on the selected
requests, because the related process is
inactive. (ARERR 46411)
However, approvers can take action on requests related to
processes in the Inactive state from the applications three-way
join. To disallow approvers to act upon such requests from the
three-way join, developers need to write the appropriate
workflow.
Request Owner Field

Enter a valid AR System user name or select the field that


identifies the owner of the approval request from the menu.
The fields in this menu are populated from the approval request
form. See Request Owner Field on page 239.

First Approver Field

Enter a valid AR System user name or select the field that


identifies the first approver for this process from the menu.
The fields in this menu are populated from the approval request
form.
This field is required for Ad Hoc process type, optional if you
allow ad hoc overrides, and otherwise unused.

232

BMC Remedy Approval Server Guide

Administration forms

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 2 of 7)


Field

Description

Type

Select the process type from the available options:

Parent-Child
Level
Ad Hoc
Rule-Based

See Approval process types on page 75.


Status

Select the process status from the available options:

Active(Default) The process generates approvals for the


approval request form.
InactiveThe process is disabled and generates no approvals.

You might want to set the status to Inactive during the


development of the process and the associated rules. When all
the appropriate rules are in place, you can modify the process
and set the status to Active.
Requests related to processes in the Inactive state are displayed
on Approval Central, but approvers cannot act upon such
requests. The following message is displayed in such an event:
This action is not allowed on the selected
requests, because the related process is
inactive. (ARERR 46411)
However, approvers can take action on requests related to
processes in the Inactive state from the applications three-way
join. To disallow approvers to act upon such requests from the
three-way join, developers need to write the appropriate
workflow.
Request Owner Field

Enter a valid AR System user name or select the field that


identifies the owner of the approval request from the menu.
The fields in this menu are populated from the approval request
form. See Request Owner Field on page 239.

First Approver Field

Enter a valid AR System user name or select the field that


identifies the first approver for this process from the menu.
The fields in this menu are populated from the approval request
form.
This field is required for Ad Hoc process type, optional if you
allow ad hoc overrides, and otherwise unused.

Appendix D

Approval forms

233

BMC Remedy Action Request System 7.6.04

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 3 of 7)


Field

Description

Generate Preview

Select generate preview setting from the available options:

NoneThe approval server does not generate preview


information in the Preview Signatures form for the process.
On Request OnlyThe approval server generates preview
information only when it receives a Generate-Preview
signal. With this option, the application controls the load on
the approval server.
On Start of ProcessThe approval server generates preview
information when any of the following events occurs:
A Generate-Preview signal is received.
A new approval process starts (for example, when a details
request is created, or when an existing request that was
closed is reopened).
A new signature is created.
The status of an existing signature changes.
On Generation or Change to a SignatureThe approval
server generates preview information when any of the
following events occurs:
A Generate-Preview signal is received.
A new approval process starts (for example, when a details
request is created, or when an existing request that was
closed is reopened).
A new signature is created or the status of an existing
signature is changed.
Real-time OnlyThe approval server generates preview
information (but does not cache it) only when a preview is
requested. This option displays the most current information,
but it puts the highest load on the approval server.

Note: If you select the On Request Only, On Start of Process, or

On Generation or Change to a Signature option, the preview


displayed might not be the most current information.
Can Reassign?

Specify whether approvers should or should not be able to


reassign a request of this process type to another approver.

Full Name Form

Select a form that provides the full name of the approver to be


added to the signature line. You could also enter a custom form
name by using the adjacent text field. This information is pushed
to the Full Name field on AP:Signature.
For more information, see Full Name on page 254 and Full
Name Form on page 239.

234

BMC Remedy Approval Server Guide

Administration forms

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 4 of 7)


Field

Description

Exclude User Field

This menu lists all the fields on the application form. Select a
field that contains user names.
The users from the selected field are excluded from the list of
approverstheir signatures are not createdfor a request of
this process type.
If the selected field contains a role:

Users belonging to that role are excluded.


If the role is part of an approval chain and contains only one
user, the other approvers can act on the request and the
process can complete successfully regardless of the One Must
Sign or All Must Sign setting.

If an excluded user is an approver in the middle of an approval


chain, the approver before the excluded user can act on the
request, and the request remains open. However, when the
excluded user is encountered, the request state is changed to
Error on the application and detail form, and no further action
can be taken.
The exclusion takes place only after the Get Next Approver rule
is executed.
Because these users are excluded from the list of approvers, they
do not appear on the Approver tab of AP:Show-Detail.
For a Level process, if one of the approvers is excluded on a level,
other approvers can take action, and the request can proceed.
When processing Auto Approval and Self Approval rules, the
approval server ignores this field.
If a user specified in this field is the only approver for the
request, the approval process fails and an error is reported.
The user exclusion operations and the related errors, if any, are
listed in the approval log files.
The values in this field are ignored in the following conditions:

When defining a process:


If you select the Ad Hoc type.
If one of the users specified for exclusion is also specified as
the first approver.
When acting on a request (regardless of process type):
If an approver reassigns a request to one of the users
specified for exclusion.
If an approver specifies one of the users specified for
exclusion as the next approver.

Note: The check for excluding users from the list of approvers is

done before signature creation, therefore it does not impact the


requests for which signatures have already been created.

Appendix D

Approval forms

235

BMC Remedy Action Request System 7.6.04

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 5 of 7)


Field

Description

Approval Success

Select the manner with which the approval server determines


whether the approval process for a request is complete:

If Multiple Approvers

No More Approvers(Default) The process is complete when


all signature lines are complete. If you select this option and if
the signature line for a request is cancelled and no other
signature exists, the request is marked Approved, not
Cancelled.
Completion RuleUse a Completion rule to determine the
successful completion of the approval process. If you select
this option, you must create a Completion rule and associate it
with this process or the process is never considered complete.

This field applies only if you are defining an Ad Hoc process or


are going to allow ad hoc overrides. The value you select
determines how many signature line records the approval server
creates when building an approver list.
Specify using the available options how to manage signature
entries when a request is assigned to multiple approvers:

One Must SignCreate only one signature line for a list of


potential approvers. The signature line is complete when one
of the approvers acts on the request. The first approver to act
on the request determines the response; the request is
withdrawn from the other approvers.
The field for approver names on a signature-line record is
limited to 255 characters on certain databases. Using roles
might help you to work around this limitation, because roles
are internally expanded to individual approver names during
further processing.
This option overrides the If Multiple Approver setting on any
roles selected as an approver.

All Must SignCreate separate signature lines for each


approver. All approvers must act on their own signature line
for the request to proceed.
If an approver list includes roles, the If Multiple Approver
setting for the specific role determines whether the role is
expanded into individual signature lines for each member of
the role or a single signature line is created for the entire role.
See Defining roles on page 106.

236

BMC Remedy Approval Server Guide

Allow Only One Approver(Default) Create a single


signature line for one individual. If you use this option and a
requester specifies multiple approvers, the approval server
stops the process and marks it as an error.

Administration forms

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 6 of 7)


Field

Description

Allow Ad Hoc Next


Approver?

This field applies to Parent-Child, Level, and Rule-Based process


types.
Specify using the available option whether users can add
approvers to the approver list for a request:

For Self Assignment

AnyoneThe requester and any approver can select an ad hoc


next approver.
ApproverOnly approvers can specify an ad hoc next
approver.
No one(Default) The process should not allow users to
specify an ad hoc next approver.

This field specifies how the approval server determines the next
approver, when the requester is not the person who submitted
the approval request (for example, when an assistant enters an
approval request on behalf of someone else).
Select from the available options:

Use Get Next Approver Rules(Default) Use a Get Next


Approver rule to determine the first approver.
Assign to Owner if ApproverUse the requester as the first
approver if the requester is defined as a valid approver for the
approval server.
If you select this option, you must define a Validate Approver
rule to verify whether the owner is a valid approver.

Validate Approvers

Always Assign to OwnerUse the requestor as the first


approver in all cases.

This field tells the approval server whether to verify the value in
your next approver field with a Validate Approver rule when
creating a request.
Select from the available options:

Require password

YesValidate the approvers when saving a request.


No(Default) Skip validating approvers.

This field determines whether the approver must enter a


password to save changes to an approval request.
Select from the Available options:

YesMandate the use of a password when saving changes to


an approval request.
No(Default) Allow saving changes to request without
validating the password.

Appendix D

Approval forms

237

BMC Remedy Action Request System 7.6.04

Table D-18: Fields on AP:Process DefinitionBasic tab (Sheet 7 of 7)


Field

Description

Assignee Group
Permissions

The AR System populates this field with the Assignee Group for
the request; the Public group is selected by default. The approval
server uses this field to support multi-tenancy for use by
application service providers.
If you use this field for multi-tenancy support, create workflow
to populate this field with the correct assignee group name. You
do not need to change this setting when creating the rule.
The ID of this field is 112, and it appears on all approval server
forms. The field 112 value from records created in the AP:Detail
form is used automatically in all the other approval server forms
(for example, AP:Signature, AP:More Information, and so on).
See Error 333 and Assignee Group Permission on page 284.

Ad Hoc Settings

This field is enabled only if you select:

An Ad Hoc process type


A process type other than Ad Hoc and Anyone or
Approver in the Allow Ad Hoc Next Approver field

The options are:

Ad Hoc Form

Default(Default) Disables the adjacent Ad Hoc Form field.


When an approver clicks the Adhoc button on AP:ShowDetail, the AP:AdhocDialog dialog box appears. Data about
the ad hoc approver entered through AP:AdhocDialog is
stored in the AP:AdhocDetails form.
User DefinedEnables the adjacent Ad Hoc Form field.
When an approver clicks the Adhoc button on AP:ShowDetail, the form specified in the Ad Hoc Form field appears.
Data about the ad hoc approver entered through this form is
stored in AP:AdhocDetails.

This drop-down list displays all the forms in the AR System


server. Select the form that you want to be displayed when an
approver clicks the Adhoc button on AP:Show-Detail.
Approvers should be able to provide data about ad hoc
approvers in this form, and the form should have the necessary
workflow to store this data in AP:AdhocDetails.
If you select a custom form, make sure that application
developers have added the necessary fields and workflow to it.

Retrieving first
This field determines the course of action in case the approval
approver failed, error? server fails to retrieve the first approver for a request.

238

Yes(Default) Set the state of the request to Error and add the
error details to the audit trail.
NoSet the state of the request to Pending. Later, if Add-Sig
is fired for that request, the same AP:Detail record is used.

Search

Appears in the Search mode; click to search the AP:Process


Definition form.

Save

Appears in the New mode; click to save the entry to the


AP:Process Definition form.

Close

Close the window without saving.

BMC Remedy Approval Server Guide

Administration forms

Request Owner Field


The setting of this field is crucial for:

The execution of Self Approval rulesThe value of this field is compared with
the current users name, and if they match, the rule is executed, otherwise it is
skipped.

Finding the first approval in the approval chainIn the Parent-Child, Level,
and Rule-Based process types, the first approver in the chain is completely
dependent on the name of the person stored in the field mapped to AP:Process
Definition > Request Owner Field. The Request Owner Field must contain a
valid entry in the approval lookup form (for example, AP-Sample:Signature
Authority is the lookup form for the Lunch Scheduler sample application).
To set an appropriate value for Request Owner Field, a process administrator
should consider the following:

Does this field store the name of the person defined in the approval lookup
form?

Is the organizational structure for this user defined in the approval lookup
form?

The value of Request Owner Field is not considered when finding the first
approver in an ad hoc process, because the requester is responsible for
specifying all the required approvers.

Full Name Form


If your application does not contain any User form that contains the full name of a
person, you should create a custom form that provides this information. The
custom form should contain two character fields, as follows, with their input
lengths set to 0:

The field with the ID 10001 should be used to hold the login name.

The field with the ID 10002 should be used to capture the full name, which could
be generated by any means.

Create a filter on this form, which executes on a service action. This filter should
use the data in the first field (10001) as input to generate the corresponding full
name and set that in the second field (10002).
See Full Name on page 254.

Appendix D

Approval forms

239

BMC Remedy Action Request System 7.6.04

Configuration tab
Figure D-20: AP:Process Definition formConfiguration tab

Table D-19: Fields on AP:Process DefinitionConfiguration tab (Sheet 1 of 2)


Field

Description

Process Intervals
These fields are used to determine the action date for signatures on a request pertaining
to this process. See Action date for a process or signature on page 80.
Process Due

Enter a number in the Interval field and the select the Unit of
measurement. This specifies the total duration in which the
process is due.

Signature Due

Enter a number in the Interval field and the select the Unit of
measurement. This specifies the total duration in which each
signature for the process is due.
Note: If you enter a value more than what is specified in Process

Due, this value is ignored. The value in Process Due is then


used to compute the action date, instead of the one you specify
in this field.
Buffer Period

240

BMC Remedy Approval Server Guide

Enter a number in the Interval field and the select the Unit of
measurement. This buffer period is considered as a delta to be
deducted from all process intervals, except Signature Due, when
computing the action date.

Administration forms

Table D-19: Fields on AP:Process DefinitionConfiguration tab (Sheet 2 of 2)


Field

Description

Enable Preview

Select Yes to use the Preview feature in calculating the Signature


Due Date. The Preview feature is used to fetch information about
the future approvers, to calculate the total number of signatures
required to complete the process. The Signature Due interval is
then computed as the Process Due interval divided by the total
number of signatures required.
Select No to avoid the use of the Preview feature. In this case,
only the value specified in Signature Due is considered.
Note: This field is used only in the case of Parent-Child and Level

processes. The value of this field is not considered when


calculating the Signature Due interval for ad hoc requests.
Specify menu name to list users for the following operations
More Information
Reassign
Ad-hoc

Select the menu from which to derive user names for the
corresponding operations.
The selected menu determines the list of users that appears when
a user creates a More Information request (by adding a question
or comment), or chooses to reassign a request, or to assign a
request to an ad hoc approver.
If you do not specify a menu for any of these operations, users do
not have the option of choosing names from a user list; they can
continue with the operation by entering login names manually.

Rejection Justification
Require Justification
on Rejection

Select Yes to make it mandatory for an approver to provide a


justification when rejecting a request. In addition to storing the
justification in various approval server fields, it is pushed to the
application forms field specified in the Justification Field menu.
Select No to indicate that rejection justification is optional; an
approver is not prompted to justify rejecting a request. However,
if provided, the justification is processed further.

Justification Field

Select the field in which to store the rejection justification. This


menu lists Character fields from the application form.
Note: Currently, this menu also displays Attachment fields along

with Character fields, because of an AR System server issue.


From the list of available fields, select a Character field whose
length is unrestricted (0). Otherwise, if the approver enters a
justification of more than 255 characters:

A warning is added to the approval log.


The justification is not made available on the application form.

If you do not select a field from this menu, the approvers input
is stored in the Justification field (ID 14518) on AP:Signature and
as a comment of the Justification type on AP:QuestionComment-Info. See AP:Rejection Justification on page 271.

Appendix D

Approval forms

241

BMC Remedy Action Request System 7.6.04

Signature Escalations tabs


Figure D-21: AP:Process Definition formSignature Escalations (Normal) tab

The three tabs (Normal, Urgent, and Low) on the Signature Escalation tab contain
identical fields.
Table D-20: Fields on AP:Process DefinitionSignature Escalations tabs (Sheet 1 of 2)
Field

Description

Use schedules
Business calendar

Use the drop-down list to select a workday schedule created on


one of the business time workday forms.

Holiday calendar

Use the drop-down list to select a holiday schedule created on


one of the business time holiday forms.

Automatic action
After Interval

Type a numeric value for the amount of time to pass before this
action is taken. For example, type a 2 for two hours or two days.
The unit is determined in the next field.
Note: This is called the Automatic Action interval, which is used

to compute the action date for the corresponding process.


Unit

242

BMC Remedy Approval Server Guide

Select the unit of Hours or Days as the unit for the interval in the
previous field.

Administration forms

Table D-20: Fields on AP:Process DefinitionSignature Escalations tabs (Sheet 2 of 2)


Field

Description

Change State

Use the drop-down list to select the status you want to force on
this request if no activity occurs in the interval defined in the two
preceding fields.
Leave this field and the preceding two empty if you do not want
the status of a request changed automatically.
Note: This reflects on AP:Show-Detail > Action Date field and

Approval Central > Action Date column. See AP:ShowDetail on page 271 and Approval Central on page 255.
Notification: Still Outstanding
First Interval

Type a numeric value for the amount of time to pass before this
notification first occurs.
Note: This is one of the Escalation intervals, which is used to

compute the action date for the corresponding process.


Unit

Select the unit of Hours or Days for the interval in the previous
field.
Note: This reflects on Approval Central > Past Due requests >

Action Date column. See Approval Central on page 255.


Repeat Interval

Type a numeric value for the amount of time to pass before this
notification recurs. For example, type a 2 for two hours or two
days. The unit is determined in the next field.

Unit

Select the unit of Hours or Days for the interval in the previous
field.

Notification: Still in State


On State

Set the separate escalation and repeat intervals to occur when a


form is saved with the status of Pending, Error, Hold, or More
Information.

First Interval

Type a numeric value for the amount of time to pass before this
notification first occurs. For example, type a 2 for two hours or
two days. The unit is determined in the next field.
Note: This is one of the Escalation intervals, which is used to

compute the action date for the corresponding process.


Unit

Select the unit of Hours or Days for the interval in the previous
field.

Repeat Interval

Type a numeric value for the amount of time to pass before this
notification recurs. For example, type a 2 for two hours or two
days. The unit is determined in the next field.

Unit

Select the unit of Hours or Days for the interval in the previous
field.

Appendix D

Approval forms

243

BMC Remedy Action Request System 7.6.04

More Information Escalations tab


Figure D-22: AP:Process Definition formMore Information Escalations tab

Table D-21: Fields on AP:Process DefinitionMore Information Escalations tab


Field

Description

Use schedules
Business calendar

Use the drop-down list to select a workday schedule created on


one of the business time workday forms.

Holiday calendar

Use the drop-down list to select a holiday schedule created on


one of the business time holiday forms.

Notification: still outstanding


First interval

Type a numeric value for the amount of time to pass before this
action first occurs. For example, type a 2 for two hours or two
days. The unit is determined in the next field.

Unit

Select the unit of Hours or Days for the interval in the previous
field.

Repeat interval

Type a numeric value for the amount of time to pass before this
action recurs. For example, type a 2 for two hours or two days.
The unit is determined in the next field.

Unit

Select the unit of Hours or Days for the interval in the previous
field.

For more information about the Administrative Information tab, see


Administrative Information tab on page 267.

244

BMC Remedy Approval Server Guide

Administration forms

AP:Question-Comment-Info
The approval server uses this form internally to store additional information that
requestors and approvers provide about requests.
Table D-22 describes the data stored in this form and the source of that data.
Table D-22: Records in AP:Question-Comment-Info
Record type

Source field

Question

Stores text from the Question field on AP:Show-Detail or AP:More


Information.

Comment

Stores text from the Summary field on AP:Show-Detail or the Comment


field (if added) on the application form.
If you add an activity log entry of the Justification type on AP:ShowDetail, text from the Summary field is also stored here.
Attachments associated with comments are stored in the attachments
table adjacent to this field.

Justification

Stores text from the Justification For Action field on AP:Show-Detail or


Approval Central.
If the Justification For Action field and its appropriate workflow is added
to the application form or the three-way join form, the corresponding text
is stored here.

This form also stores the text from the following sources:
Form

Field

AP:More Information

Response

AP:Show-Detail

Application form

Response
Notes

Notes (if added with the appropriate workflow)

AP:Reserved Word
Process administrators use this form to create keywords and functions for
approval processes.
Figure D-23: AP:Reserved Word form

Appendix D

Approval forms

245

BMC Remedy Action Request System 7.6.04

Table D-23: Fields on AP:Reserved Word


Field

Description

Name

Type the word you want to reserve.

Name Type

Click the option button to select whether the word is a keyword


or function.

Assignee Group
Permissions

Select the name of the special control group for you want to have
row-level permissions.

AP:Role
The AP:Role form opens when you click View or Create on the Role tab of
AP:Administration. Process administrators use this form to create role definitions
for approval processes. See Defining roles on page 106.
Figure D-24: AP:Role formRole Information tab

For more information about the Administrative Information tab, see


Administrative Information tab on page 267.
Table D-24: Fields on AP:RoleRole Information tab (Sheet 1 of 2)
Field

Description

Role Name

Type the name for this role.

If Multiple Approvers

Select one of the options:

One must signA single signature entry is created for all


individuals in the Member List field. Only one individual
needs to take action.
All must signSeparate signature entries are created for all
individuals in the Member List field. All individuals must take
action for the request to move forward.

This field is valid only if more than one entry exists in the
Member List field.

246

BMC Remedy Approval Server Guide

Administration forms

Table D-24: Fields on AP:RoleRole Information tab (Sheet 2 of 2)


Field

Description

Status

Use the drop-down list to select the status of this role.

Member List

ActiveThis role can be used by any approval process.


InactiveThis role is disabled for all approval processes.

Type the AR System user name for each person who is a member
of this role. Use a semicolon (;) as a separator between names.

AP:Rule Definition
The AP:Rule Definition form opens when you click View or Create on the Rule tab
of AP:Administration.

Basic tab
Figure D-25: AP:Rule Definition formBasic tab

Process administrators use this form to create and modify rules for approval
processes. See Using the Rule tab on AP:Administration on page 110.
Table D-25: Fields on AP:Rule DefinitionBasic tab (Sheet 1 of 4)
Field

Description

Definition
Rule Name

Type a name for this rule.


The name of a rule can be as long as 254 characters in English and
most European languages, but only 127 characters in doublebyte languages.

For Process

Use the drop-down list to select a process for this rule.

Appendix D

Approval forms

247

BMC Remedy Action Request System 7.6.04

Table D-25: Fields on AP:Rule DefinitionBasic tab (Sheet 2 of 4)


Field

Description

Process Instance ID

The AR System automatically populates this field with the GUID


of the process.

Rule Type

Use the drop-down list to select the rule type. See Chapter 7,
Defining approval rules.

Order

Type a number to determine execution order for this rule. Larger


numbers execute after smaller numbers. Rules with the same
number in this field execute in an unpredictable order.

Status

Use the drop-down list to select the status of this rule.

If Multiple Results

Use the drop-down list to select the behavior when multiple


results are found.

If Multiple Approvers

Value from FirstThe approval server uses the value from


the first record retrieved.
Values from AllThe approval server uses all of the values
retrieved.
Return ErrorThe approval server produces an error
message if more than one record is retrieved.

Select one of the options:

One Must SignA single signature entry is created for all


approvers. Only one of those approvers needs to take action
on the request.
All Must SignSeparate signature entries are created for all
approvers. All approvers must act on the request for it to move
to the next stage.

Next Approver Rule Is Use the drop-down list to select the behavior when multiple Get
Next Approver rules exist.

AdditiveThis rule appends approvers to the existing


approver list, and further rules are processed.
EndingThis rule appends additional approvers to the
existing approver list, but no further rules are processed.
ExclusiveThis rule assigns the approver list, and no further
rules are processed. If a previous rule created an approver list,
the process ignores it.

This field is usually used for a Rule-Based process that has a set
of Get Next Approver rules to build an approver list.
Assignee Group
Permissions

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.
See Error 333 and Assignee Group Permission on page 284.

248

BMC Remedy Approval Server Guide

Administration forms

Table D-25: Fields on AP:Rule DefinitionBasic tab (Sheet 3 of 4)


Field

Description

Qualification
Run if

This field label appears for the following rule types:

Get Authority
Get Authority Regular
Get Authority Self
Get Next Approver
Parameterized Get Next Approval Rule
Prep Get Next Approver
Signature Accumulator
Statistical Override
Validate Approver

Enter the qualification in the Run If field. Use the buttons and
drop-down list to help. See Using the Rule tab on
AP:Administration on page 110.
In addition, you can dynamically define the search criteria by
using the EXTERNAL keyword. When using the EXTERNAL
keyword, make sure you see fields using single quotes instead of
dollar signs, for example:
Submitter = John
Otherwise, if you enter:
$Submitter$ = John
the value from the current transaction will be returned:
John = John
Rule

This field label appears for the following rule types:

Auto Approval
Self Approval
Completion Rule

Enter the qualification in the Rule field. Use the buttons and
drop-down list to help. See Using the Rule tab on
AP:Administration on page 110.
In addition, you can dynamically define the search criteria by
using the EXTERNAL keyword. When using the EXTERNAL
keyword, make sure you see fields using single quotes instead of
dollar signs, for example:
Submitter = John
Otherwise, if you enter:
$Submitter$ = John
the value from the current transaction will be returned:
John = John
Audit text

This field appears for Auto Approval and Self Approval rules.
Type the text you want to appear in the permanent record for the
request whenever this rule executes. Use the drop-down list to
select keywords to include in your audit trail message.

Appendix D

Approval forms

249

BMC Remedy Action Request System 7.6.04

Table D-25: Fields on AP:Rule DefinitionBasic tab (Sheet 4 of 4)


Field

Description

Rule State

This field label appears for Approval Process Done rules. Select
one or more rule conditions from among the radio buttons.
The options are:

Approved
Rejected
Cancelled
Error

The rule executes when the approval detail record moves to the
selected state.
Guaranteed Add

YesThe parameterized rule runs even when a Completion


rule would otherwise determine that the process is done, thus
guaranteeing that the user will be added as an approver.
No(Default) If a Completion rule determines that the
conditions exist for the process to be done, the process does not
return to the Get Next Approver stage to run this rule.

Search

In Search mode, click this button to perform your search.

Save

In Submit mode, click this button to save your changes.

Close

Click this button to close the window.

Set Fields tab


The Set Fields tab appears only when you select a rule type for which you can
specify a Run If qualification and the subsequent Set Fields actions.
Figure D-26: AP:Rule Definition formSet Fields tab

250

BMC Remedy Approval Server Guide

Administration forms

Table D-26: Fields on AP:Rule DefinitionSet Fields tab (Sheet 1 of 2)


Field

Description

Set Fields Type

Select an item from the drop-down list to specify how the rule
should populate this field type. The options are: Value, Query,
SQL, Process, and Other.

From Form

For a query, select the name of the form that contains the data to
retrieve.

On Server

Use the drop-down list to select the server that contains the form.

Server

CurrentSelect this option if the form resides on the same


server as the approval server.
AlternateSelect this option if the form resides on another
server.

Type the name of the server that holds the form.


This field is available only when the On Server field contains the
value Alternate.

Separator string

Type the letters, numbers, or symbols to use when separating


multiple entries set in the same field.
This field is disabled with some options available in the Set Field
Type field.

Qualification
Query builder buttons The Fields from Set Fields Form, Fields from Application Form,
and other SQL keywords and operator buttons are available for
use only when you select a Set Fields type other than Value.
For example, choosing SQL causes Select, From, Where, and the
comma separator (,) buttons to appear so that you can construct
SQL statements easily.
SQL Command /
Qualification

Type a qualification or use the other fields to select functions or


keywords.
You can dynamically define the search criteria by using the
EXTERNAL keyword. When using the EXTERNAL keyword,
make sure you see fields using single quotes instead of dollar
signs, for example:
Submitter = John
Otherwise, if you enter:
$Submitter$ = John
then the value from the current transaction is returned:
John = John

Appendix D

Approval forms

251

BMC Remedy Action Request System 7.6.04

Table D-26: Fields on AP:Rule DefinitionSet Fields tab (Sheet 2 of 2)


Field

Description

Fields data
Field name

Type a field name or use the drop-down list to select a field


name. The Field Name field is disabled with some options
available in the Set Field Type field.
One rule can populate more than one field by using separate
lines for Field Name and Value.

Value

Type the value or use the drop-down list to select a value to


populate the field. The Value field is disabled for some Set Field
types.
One rule can populate more than one field by using separate
lines for Field Name and Value.

For more information about the Administrative Information tab, see


Administrative Information tab on page 267.

AP:Signature
The AP:Signature form stores the signature lines for approval requests.
Administrators can use this form to review the responses to a request. However,
you should modify this information only through Approval Central.
Figure D-27: AP:Signature form

252

BMC Remedy Approval Server Guide

Administration forms

Table D-27: Fields on AP:Signature


Field

Description

Approval ID

The AR System populates this field with the AR System ID for


this request.

Approvers

The AR System populates this field with the name of the


approver for this signature line.

More Information

The AR System populates this field with the questions and


answers to More Information Requests.

Approval Status

The AR System populates this field with the status of the


request.

Next Approver

The AR System populates this field in an ad hoc situation with


the name of the next approver.

If Multiple Approvers

This field is valid only if multiple entries exist in the Next


Approver field. Select one of the options:

One Must SignA single signature entry is created for all


approvers in the Next Approver field. Only one of those
approvers needs to take action on the request.
All Must SignSeparate signature entries are created for all
approvers in the Next Approver field. All approvers must act
on the request for it to move to the next stage.

Alternate Signature

The AR System populates this field with the user name of an


alternate approver, if the alternate acts on the request.

Approver Signature

The AR System populates this field with the user name of the
approver when the approver acts on the request.

Signature Method

The AR System populates this field with the method by which


this request was approved.

AlternateAn alternate signed this request instead of a


normally scheduled approver.
RegularA normally scheduled approver signed this request.
OverrideSomeone with process administration authority
performed an override to respond to this request instead of a
normally scheduled approver.

Assignee Group
Permissions

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.

Full Name

Used to store the full names of approvers to whom the


corresponding request is assigned.
See Full Name on page 254.

Role ID

Used to make a signature role aware.


For more information, see Role ID on page 254 and Creating
signature escalations on page 101.

The approval server automatically drops duplicate signature lines if an approver


appears in multiple groups to which a request is assigned or if there are duplicate
individual mappings.

Appendix D

Approval forms

253

BMC Remedy Action Request System 7.6.04

In such a event, entries such as the following are recorded in the approval log:
<APPR> * Process option set to not validate user so no work needed
<APPR> Expanding roles for approver(s): SGP000000000082|CAB-Member
<APPR> Expanding roles for approver(s): SGP000000000084|CAB-Member
APPR> Dropping duplicate approver line for USER1;USER2;USER3;
<APPR> Dropping duplicate approver line for USER1;USER2;USER3;

You can safely ignore such log entries; the signature lines are dropped because the
approval server maintains only one signature line for an approver per request until
the associated process is active.

Full Name
The approval server uses the login name to search for the corresponding full name
when creating a signature entry. It first searches the User forms, and if they do not
have the full name information, it searches the custom form specified on
AP:Process Definition. This information is stored in the Full Name character field
(14201). See Full Name Form on page 239.
If there is no custom Full Name Form, or if the full name information is not found
through this form, the login name is used as default.
Setting the full name on a signature line is a one-time activity; this value is not set
at run time. The full name provided at the time of signature line creation stays
constant. When upgrading to release 7.5.00 or later, if the Full Name value is not
available, it is set according to the current Full Name value from the related form.
If the Full Name value is required to be set dynamically, application developers
must write the appropriate escalations, because applications can fetch user
information from different forms, like the User form, CTM:People form, and so on.

Role ID
If a signature is created by expanding a role, the Role ID character field (14200)
stores the role ID of the source role, which was expanded to create the individual
signature line. The following situations could occur:

If a role has One Must Sign set to true, only one signature entry is created for all
the members belonging to the role. The related role ID is copied to the Role ID
character field.

If a role has All Must Sign set to true, the role ID is copied to each signature entry
that is created by expanding the role.

Depending on the process definition, the signature entries are created as follows:

254

When One Must Sign is defined at the process level, only one signature entry is
created, irrespective of the If Multiple Approvers setting at the role level. In this
case, the individuals defined as approvers and the individuals expanded from
the roles provided as approvers appear in a single signature entry. Role IDs for
all the roles in the approvers list are put in the newly added field on the
AP:Signature form for the corresponding signature.

BMC Remedy Approval Server Guide

User forms

When All Must Sign is defined at the process level, multiple signatures are
created according to the If Multiple Approvers setting at the role level. In this
case, each signature entry contains the role ID that was responsible for creating
the entry by expanding the individuals in the role.

The values in the Role ID field could differ as follows:

The Role ID field remains blank for individuals in the approvers list.

The Role ID field can have a single role ID or multiple roles IDs based on the
definitions. All role IDs are enclosed between semicolons.

Consider a case where a role is defined as an approver, which in turn is


composed of roles. When this is expanded recursively to write individuals in the
signature entry, the Role ID field has the role ID of the base role that was
provided as the approver.
For example: The Finance role contains the users Jim and Frank. The Purchase
role contains the users Paul and Bob. The Administrator role is a superset of
Finance, Purchase, and a few more roles. When the Administrator role is defined
as an approver for a request, even though it expands the Finance, Purchase, and
other roles recursively to get individual approvers, the Role ID fields of the
signatures created for these approvers contains the role ID of the Administrator
role.

AR System Business Time forms


Process Administrators use the following AR System forms to determine the
business hours and holidays to be used by approval processes and other
AR System workflow:

Business Time Holidays

Business Time Workdays

See the Configuration Guide, Using the old Business Time forms, page 240.

User forms
User forms are used by submitters, approvers, process administrators, and so on.

Approval Central
The Approval Central form, which acts as the approval server console, appears
when you log in to AR System and click the Approval Central link on the home
page. This link is localized.

TIP
The localized link is visible only if the Localize Server option is enabled on the
Advanced tab of the AR System Administration: Server Information form. See the
Configuration Guide, Server InformationAdvanced tab, page 123.

Appendix D

Approval forms

255

BMC Remedy Action Request System 7.6.04

NOTE
The Approval Central view is not supported on 7.0.01 or earlier versions of
AR System clients. When Approval Central is opened in version 7.0.01 of
BMC Remedy Mid Tier or BMC Remedy User, a warning message is displayed
and the counts against the links in the left pane are not displayed.
Approvers use Approval Central to respond to approval requests, and to access
request details. Requesters use it to access More Information requests sent to them.
See Chapter 3, Processing approval requests.
Figure D-28: Approval Central form

Approval Central enables you to quickly review the approval requests awaiting
your attention. These could be direct requests or requests for which you act as an
alternate approver. You can approve, reject, hold, or view the details of a pending
request using the appropriate buttons provided at the bottom of the form. You can
reassign a pending request only if the Can Reassign option for the corresponding
approval process is set to Yes in AP:Process Definition.
When you open Approval Central, the Pending Approvals table appears by
default, and it displays requests that have the Pending, Hold, or More Information
status.

256

BMC Remedy Approval Server Guide

User forms

The left pane contains two sections: Approval Tasks and Action Menu. Clicking a
link in these sections displays a corresponding panel in the right pane.

Approval Tasks
The links in this section correspond to pre-defined searches. A table in the
corresponding panel on the right displays the search results. See Approval Search
Result table on page 259.
Table D-28: Fields on Approval CentralApproval Tasks section
Field

Description

Needs Attention

Click to view the requests for which a question or answer is


directed at you. Such requests are in the More Information state.
The Need Attention Approvals panel displays a table with the
columns: From, To, Action Date, Description, Application,
Request, and Status.

Pending Approvals

Click to view the requests that await your approval. Such


requests are in the Pending state.

Past Due

Click to view the requests whose Action Date has passed. The
Past Due Approvals table displays requests having the Pending,
Hold, or More Information status.
For more information about the Action Date, see step 5 and
step 6 of theTo enter signature escalations section.

Due Soon

Click to view the requests whose Action Date is approaching.


The Due Soon Approvals table displays requests having the
Pending, Hold, or More Information status.
A Process Administrator configures, through
AP:Administration, the time factor that decides whether an
approval request falls under the Due Soon category. For more
information, see step 5 of the To enter signature escalations
section.

Rejected by Others

Click to view the requests that you approved earlier, but are
rejected by an approver further in the approval sequence.
This is a pre-defined search, the results of which appear on the
right pane in the Approvals Rejected by Others panel.

Approval requests that need attention


When you click the Needs Attention link in the Approval Tasks section of the left
pane, a table of questions and answers posted to you appears in the right pane.
The table contains the columns: From, To, Action Date, Application, Request, and
Status, which display the corresponding information for each request.
You can perform one of the following actions on any selected request in this table:

Click Respond to answer the corresponding question. The AP:More Information


form opens in the Modify mode.

Click View to open the corresponding question-answer thread. The AP:More


Information form opens in the display mode.
Appendix D

Approval forms

257

BMC Remedy Action Request System 7.6.04

After you respond to a question or view the answer to a question you raised, the
state of the request changes from More Information to Pending.

Action Menu
Table D-29: Fields on Approval CentralAction Menu section
Field

Description

My Recent History

Click to view the requests that you approved or rejected, and


requests that have the Error status. This is a pre-defined search,
the results of which appear on the right pane in the My Recent
Approvals History table. Requests displayed in this table have
the Approved, Rejected, or Error status.
A Process Administrator configures the number of history items
to display. See AP:Admin-ServerSettings on page 212.
This is a pre-defined search, the results of which appear on the
right pane in the My Recent Approvals History table.

Search My Approvals

Click to display the Approval Search panel where you can


specify various search criteria and view the results in the Search
Results table.

My Alternate
Approvers

Click this link to open the AP:Alternate form in New mode.


For more information, see AP:Alternate on page 266.

The right pane displays the appropriate panels when you click the links in the
Approval Tasks or the Action Menu sections in the left pane. You can expand or
collapse these panels using the arrow icon next to the panel title.

Approval Search
Enables you to specify criteria for searching through approval requests. Select or
enter field values in this section of the form to search for requests and display the
results in the Search Results table.
Figure D-29: Approval Central formApproval Search section

258

BMC Remedy Approval Server Guide

User forms

Table D-30: Fields on Approval CentralApproval Search section


Field

Description

Application

Select an application from the list of available applications.


Select the name of the approval request form from the list to
search for approval requests related to that form.

Process

Select a process. If you select an application, only the processes


belonging to that application appear in this menu.

Acting As

Select a value from the list to search for requests with the
selected type of approver authority. The default is Myself.
If you choose All and perform a search, the resulting list
contains the same requests that appear when you click the
Pending Approvals link.

User

Contains the name of the current user or the user on whose


behalf you are acting as alternate, or performing an override.

If Acting As is set to Myself or Global Override,


AR System populates this field with the name of the current
user.
If Acting As is set to Alternate or Override, you must enter
the AR System name of the user for whom you are acting as an
alternate, or performing an override.

Approval Status

Select an approval status from the list to search for requests with
the selected status. The default is Pending.

Requester

Type all or part of a requesters AR System full name to search


for approval requests from that requester. The search results
display the requests created by this requester only if you have
the correct privileges on the corresponding requests.

Summary

Enter one or more words in the summary that you want to search
for.

Action Date

Select the Action Date.


See Signature Escalations tabs on page 242 and step 5 of the
To enter signature escalations section.

Priority

Select the priority. This is the priority of the approval request


and not that of the application request.

Modified Date

Select the date on which the requests you want to search for were
last modified.

Search

Click to perform the search after you specify all the required
criteria.

Clear All

Click to clear all the search fields.

Approval Search Result table


The Approval Search Result table is displayed in the right pane, and its contents
change according to the links you click in the left pane.
Some rows might have a bell icon displayed in the first untitled column, indicating
that the corresponding request is Urgent.

Appendix D

Approval forms

259

BMC Remedy Action Request System 7.6.04

The second untitled column contains check boxes that you can use to select the
corresponding requests. Use the check boxes to select multiple requests on which
you want to perform similar actions.
Clicking on a row, without using the corresponding check box, will select that row
and deselect everything else. Click the Select All or Deselect All buttons to select or
deselect all the requests in this table. See Working with multiple pending
requests on page 261.
Table D-31: Fields on Approval CentralApproval Search Result table (Sheet 1 of 2)
Field

Description

Action Date

The date on or before which, if you do not act upon the request,
either you receive a notification that it is still outstanding, or the
state of the request is changed automatically.
This is applicable only to those requests where Notification:Still
Outstanding, or Automatic Action, or both are configured in the
corresponding AP:Process Definition form. The Action Date is
calculated as the least of these two values, if both are specified.
See Signature Escalations tabs on page 242 and step 5 of the
To enter signature escalations section.

Summary

The description associated with the Source ID (Application ID).


This value is populated from field 14506 on AP:Detail that
contains the Description value for the associated application
request.
When you hover over this field, a tool tip displays the comment
provided by the requestor when creating the application
request. This additional information helps you take a quick
decision about the request.
Note: This field appears only if the appropriate setting is done on

the Advanced tab of AP:Form. See AP:Form on page 220.

260

Requester

The name of the requestor. This information is obtained from the


three-way join form for the related application.

Acting As

The name of the approver to whom the request is originally


assigned. This field contains a value only if you are the alternate
approver for the original request assignee.

Priority

The priority of the approval request that is stored in the


corresponding AP:Detail record. The possible values are:
Urgent, Normal, and Low.

Application

The application name associated with the request. For example:


SRM, Change Management. This name is provided by the
application itself.

Status

The current state of the request. The possible values are:


Pending, Approved, Rejected, Cancelled, Hold, More
Information, Error, and Closed.

BMC Remedy Approval Server Guide

User forms

Table D-31: Fields on Approval CentralApproval Search Result table (Sheet 2 of 2)


Field

Description

Preferences

Click to set the preferences to display items in this table. You can
choose to display or hide a column, set the refresh interval, and
reset or save the display settings.

Justification For Action Enter some meaningful text in this field to be recorded as a
justification for your action, and click Reject. An entry is added
to the Activity Log table.
If you click any other action button, this field is ignored.
For information about how your input is processed, see
Rejection justification for approval requests on page 40.

Working with multiple pending requests


To select a single row in the Approval Requests table, click anywhere on the row;
its check box gets selected and those of other rows are unselected. To select
multiple requests, use the corresponding check boxes. However, at a time only one
row appears highlighted (irrespective of the status of its check box).

NOTE
Multiple row selection does not work for requests of the Needs Attention category.
You can select multiple requests and approve, reject, hold, or reassign them
together. Upon clicking the appropriate action button, a guide runs through the
individual requests and performs the actions. If one or more of the associated
processes mandate passwords, you are prompted to provide it, only once, before
the action is performed.

Setting display preferences on Approval Central


Use the Preferences menu to set display preferences for the tables on this screen as
follows:

Add ColumnUse to select a column to be displayed.

Remove ColumnUse to select a column to be hidden.

Set Refresh IntervalClick to open a dialog box that allows you to specify the
duration (in minutes) after which the table is automatically refreshed.

ResetClick to revert any changes you made to the appearance of the table, or
the refresh interval.

SaveClick to save any changes you made to the appearance of the table or the
refresh interval. These changes are saved only for the current session and are not
persistent, which means they are not retained when you log out and log in again.

Appendix D

Approval forms

261

BMC Remedy Action Request System 7.6.04

Action buttons
You can select one or more requests on Approval Central and click the appropriate
buttons to perform the desired actions. The buttons are disabled only if there are
no requests to be selected.
Selecting one or more requests enables all the action buttons irrespective of the
status of the request. If a certain action can not be performed on a selected request,
one of the following occurs:

Clicking the action button has no effect. For example, if you select a request that
is on hold, clicking the Hold button will have no effect.

Clicking the action button displays an error message and the request remains
unchanged. For example, if you select an request with the Approved, Rejected,
or Error status and click either Approve, Reject, Hold, or Reassign, the following
error message is displayed:
Select atleast one row with appropriate status to perform the
buttonLabel action. (ARERR errorNumber)

Table D-32: Action buttons to operate on selected requests


Field

Description

Approve

Click to approve the selected requests.

Reject

Click to reject the selected requests.


If rejection justification is mandatory, but the Justification For
Action field is empty, a dialog box prompts you to enter a reason
for rejecting the request. The same comment is applied to all the
selected requests.
See Rejection justification for approval requests on page 40.

Hold

Click to put the selected requests on hold.

Reassign

Click to reassign the selected requests to another person.


If Can Reassign is set to Yes for the corresponding process, the
AP:Reassign dialog box prompts you to enter the name of an
approver; otherwise an error is displayed.
Note: The AP:Reassign dialog box appears only once, which

means that all the selected requests are assigned to the same
person. Validation for the user name entered in the dialog box
is not provided out-of-the-box.
View Details

Click to open the AP:Show-Detail form, which displays the


details of the highlighted approval request and enables you to
take further action.
This command works on only one request at a time. If you select
multiple requests and click View Details, the Activity Log is
displayed only for the request whose row appears highlighted.

262

BMC Remedy Approval Server Guide

User forms

Approval Request Summary


Table D-33: Fields on Approval CentralApproval Request Summary section
Field

Description

Source ID

Displays the application ID (the request ID or any other ID in the


application) as a link. Click the link to display the relevant
application form.
Note: If you upgrade from an earlier version of the approval

server to 7.5.00 or later, this link displays the correct


application ID for newly created requests. The application ID
might not be accurate for requests that were created before
upgrading. To specify the value for this link, the process
administrator must map the Application Request ID field on
the Advanced tab of AP:Form to the appropriate field on the
application form. See AP:Form on page 220.
Notes

Displays the notes associated with the Source ID, if any.


The value of this field is retrieved from the application form field
that the process administrator mapped to Field8 {14513} on the
Advanced tab of AP:Form. See AP:Form on page 220.

Activity Log

Displays the activity log (Questions, Comments, and other


information) associated with the Source ID.
Click View Activity Summary to view all the activities related to
the current request in a report format.

When you click any of the Approve, Reject, Hold, or Reassign buttons, a dialog box
prompts you to enter your password. The statuses of the selected requests are
changed only if you provide a valid password, otherwise an error is displayed.

AP:AdhocDialog
This dialog box appears when you click the Adhoc button on the AP:Show-Detail
form for a request. The appearance of this dialog box is dependent on the value of
the Ad Hoc Settings field on AP:Process Definition; it appears only if the Default
option is selected. However, if the approval administrator selects the User Defined
option, the custom dialog box for the corresponding form is displayed.
AP:AdhocDialog shows the list of existing ad hoc approvers, if any, and enables
you to add to or remove from this list. If the table contains multiple rows, the first
row is selected by default.

Appendix D

Approval forms

263

BMC Remedy Action Request System 7.6.04

Figure D-30: AP:AdhocDialog form

Table D-34: Fields on AP:AdhocDialog (Sheet 1 of 2)


Field

Description

Name

Select a name from the user list or enter the name of a new ad hoc
approver. You can also specify multiple ad hoc approvers by
typing their names separated by semicolons.
If you select a row in the following table, the corresponding
approver name appears in this field, but you can modify and
save it.

Sequence

Enter or modify the sequence at which to add the ad hoc


approver. The default is 1.

If Multiple Approvers

Select one of the options:

Independent

Select one of the options.

Preferences

One Must SignOnly one signature entry is created. If you


specified multiple approvers, only one of them needs to take
action on this request.
All Must SignA separate signature entry is created for each
approver in the Name field. All of them must take action on
the request for it to move to the next stage.
YesIndicates to the approval server that the request can
proceed to the next level of its process without waiting for the
signature of the current ad hoc approver.
NoIndicates to the approval server that the current ad hoc
approvers signature is required before the request can
proceed to the next level of its process.

Click to set the preferences to display items in this table. You can
choose to display or hide a column, set the refresh interval, and
reset or save the display settings.
Note: This menu is available on the mid tier only.

264

BMC Remedy Approval Server Guide

User forms

Table D-34: Fields on AP:AdhocDialog (Sheet 2 of 2)


Field

Description

Refresh

Click to refresh the contents of this table.


Note: This field is available on the mid tier only.

Add

Click to add a new ad hoc approver, after you enter appropriate


values in the fields.

Modify

Select a row that you have not yet saved, and click to modify the
details of the corresponding ad hoc approver.
Note: This button remains disabled when you select rows that

have already been saved.


Delete

Select one or more rows using the corresponding check box and
click to delete the association of the corresponding ad hoc
approvers with the current request.

Save

Select one or more rows using the corresponding check box and
click to save the new ad hoc approvers to the AP:AdhocDetails
form.
Note: Even though a row is added to the table, it is not saved until

you explicitly select it and click Save.


Close

Click to close the dialog box; if there are any unsaved records in
the table, you can confirm whether to return to the dialog box
and save them or ignore them and close the dialog box.
If you make any changes to the list of ad hoc approvers, the
contents of the Approver tab reflect the same.

NOTE
After you add an ad hoc approver at the current level and save the record (the data
is saved in AP:AdhocDetails), you cannot modify it. If you need to make changes,
delete the existing ad hoc approver record and create a new one.
You can modify the record of an ad hoc approver who is assigned for a future level.

Appendix D

Approval forms

265

BMC Remedy Action Request System 7.6.04

AP:Alternate
Approvers use this form to create, delete, and maintain alternate approvers.

Alternate Information tab


Figure D-31: AP:Alternate formAlternate Information tab

Table D-35: Fields on AP:AlternateAlternate Information tab (Sheet 1 of 2)


Field

Description

Alternate

Type the AR System user name of the person who is to act as


alternate.

For

Type the AR System user name of the person for whom the
Alternate will substitute. The default is the current user.

Start Date

Open the calendar control and select the date and time when the
alternates authority begins.

End Date

Open the calendar control and select the date and time when the
alternates authority ends.

Notify Alternate

Select whether the alternate is notified when a request comes to


the original approver.

Yes notifies the alternate when a request is pending.


No does not notify the alternate.

To notify alternates, the process administrator must perform the


following tasks:
1 Create notifications on the New Signature notify on event.
2 Select Enabled Including Alternate on the AP:Admin-Server

Settings form.

266

BMC Remedy Approval Server Guide

User forms

Table D-35: Fields on AP:AlternateAlternate Information tab (Sheet 2 of 2)


Field

Description

Covering

Select a value to identify which processes are included in this


alternates authority.

AllThis alternate has authority to approve all processes for


which the original approver has authority.
Specific ProcessThis alternate has authority for only the
process specified in the Process field.

Process

If you selected Specific Process, select the process for which the
alternate has authority.

Process Instance ID

AR System automatically enters the GUID of the process


selected in the Process field.

Status

AR System automatically completes this field based on the


servers current date and time.

FutureThis alternate is not yet active.


CurrentThe alternate is presently active.
PastThe alternate is no longer active.
CancelledThe alternate record has been cancelled and the
alternate is not active.

Search

In Search mode, searches the AP:Alternate form.

Save

Save changes and entries to the form.

Close

Close the window without making any changes.

Administrative Information tab


Figure D-32: AP:Alternate formAdministrative Information tab

Appendix D

Approval forms

267

BMC Remedy Action Request System 7.6.04

Table D-36: Fields on AP:AlternateAdministrative Information tab


Field

Description

Alternate ID

AR System populates this field with an AR System ID for this


record.

Create Date

AR System populates this field with the date this alternate was
created.

Assigned To

Type the name of the original approver assigning authority to


this alternate. The default is the current user.

Help Text

Type information to aid users who are setting up alternates.

Change history

Type any additional information to be recorded with the


alternate assignment. This information becomes part of the
permanent record for this alternate.

Last Modified By

AR System populates this field with the name of the person who
last modified this alternate.

Last Modified Date

AR System populates this field with the date of the last


modification to this alternate.

AP:Dtl-Sig-MoreInfoDialog
This form appears when you click More Information on the AP:Detail-Signature
form, or Manage More Information on the three-way join forms in the sample
applications. When opened, it is populated with a list of More Information requests
related to the current approval request.
Figure D-33: AP:Dtl-Sig-MoreInfoDialog form

Table D-37: Fields on AP:Dtl-Sig-MoreInfoDialog (Sheet 1 of 2)

268

Field

Description

Existing More
Information records

This field displays any More Information records attached to the


current approval process.

Preferences

Click to set the preferences to display items in this table. You can
choose to display or hide a column, set the refresh interval, and
reset or save the display settings.

Refresh

Refreshes the list.

BMC Remedy Approval Server Guide

User forms

Table D-37: Fields on AP:Dtl-Sig-MoreInfoDialog (Sheet 2 of 2)


Field

Description

New Record

Opens the AP:More Information form in New mode, where you


can create a new More Information request.

Open

Opens the selected item in list.

Close

Close the form.

AP:More Information
This form contains More Information requests. It opens when you click New
Record or Open on the AP:Dtl-Sig-MoreInfoDialog form.
Figure D-34: AP:More Information form

Table D-38: Fields on AP:More Information


Field

Description

To

Select the recipients name from the menu, or enter the


recipients AR System user name. You can not select or enter
multiple names in this field.
The user names in this drop-down list are determined by the
menu specified in the process definition. For more information,
see AP:Process Definition on page 231.

From

AR System user name of the sender of the More Information


request. This field is read-only after the record is saved.

More Info Status

Status of the More Information request.

Application

The application to which the request belongs.

Request

Request ID of the request.

Question

The question pertaining to the More Information request.

Response

Response to question about the More Information request.

Assignee Group
Permission

The AR System populates this field with the Assignee Group for
the request. This field supports the multi-tenancy feature.

Appendix D

Approval forms

269

BMC Remedy Action Request System 7.6.04

AP:Password
This dialog box appears when an approver clicks Approve, Reject, or Reassign on
Approval Central for a request whose process requires a password. An approver
must enter the correct AR System user password and click Submit. If the password
in authenticated, the request status is changed. Otherwise, an authentication error
is displayed and no action is taken on the request.
Table D-39: Fields on AP:Password
Field

Description

Submit

Enter the correct password to approve or reject the request, and click
to submit the password for authentication.
If authenticated, an Approve or Reject action occurs. If not
authenticated, AR System returns an authentication error.

Cancel

Click to close the dialog box without submitting the password. No


action is taken on the request.

AP:Reassign
Figure D-35: AP:Reassign dialog box

This dialog box appears when an approver selects one or more approval requests
on Approval Central or opens AP:Show-Detail for a record, and clicks Reassign.
Select a name from the user list or enter the precise AR System login name of the
approver to whom you want to reassign the request, and click OK.
If the requests you selected belong to different processes, each of which have a
different menu configuration for the user list, the user list pertaining to the first
request is displayed. To choose from the appropriate user list for a request, work
with a single request at a time.
Click Cancel to close the dialog box without performing any action on the request.

270

BMC Remedy Approval Server Guide

User forms

AP:Rejection Justification
This dialog box appears when an approver selects one or more approval requests
on Approval Central or opens AP:Show-Detail and clicks Reject without entering
some text in the Justification For Action field.

The approver can perform the following actions:

Enter the justification for rejecting the request, and click OK.
When rejecting multiple requests simultaneously, the dialog box appears only
once. The same comment is added to the activity log of all the selected requests.

Click Cancel to close the dialog box without providing a comment.


If the process mandates rejection justification, the Reject action is skipped and a
message to that effect is displayed. The request remains in the Pending state.

AP:Show-Detail
The AP:Show-Detail form displays all the data related to an approval request. This
data is fetched from the AP:Detail form.
For more information, see AP:Detail on page 216.

Appendix D

Approval forms

271

BMC Remedy Action Request System 7.6.04

Figure D-36: AP:Show-Detail formApprover tab with multi-process preview

The P-C Phase, P-C GL Account, P-C Cost Center, and P-C Total Cost are generic
character fields, which application developers can use to show additional
character data. The labels of these fields can also be changed dynamically so that
the labels are in sync with the values. These labels are localized.

NOTE
Localized labels are visible only if the Localize Server option is enabled on the
Advanced tab of the AR System Administration: Server Information form. See the
Configuration Guide, Server InformationAdvanced tab, page 123.
The Action Date field indicates the duration after which the state of the approval
request is changed automatically or a notification is sent to the relevant approver
to act on the same. This occurs only if it is so defined in the process. For more
information, see AP:Process Definition on page 231 and Creating signature
escalations on page 101.

272

BMC Remedy Approval Server Guide

User forms

You can use this form to perform the following operations:

View a history of activities on a request for any approval process in the form of
a table or a flowchart.

Add or remove ad hoc approvers to the approval chain.

Add and view questions, comments, notes, and attachments for further
information.

Table D-40: Fields on AP:Show-Detail


Field

Description

Approver tab

Displays the approval process preview for the current request as


a flowchart or a table.
See Approver tab on page 274.

Activity Log tab

Displays the list of questions and comments associated with the


current request in a table. You can also add or delete questions
and comments.
See Activity Log tab on page 276.

Approve

Click to approve the current request.

Reject

Click to reject the current request.

Reassign

Click to reassign the current request to another person. If Can


Reassign is set to Yes for the corresponding process, a dialog box
prompts you to enter the name of an approver; otherwise an
error is displayed.

Hold

Click to put the current request on hold.

Adhoc

Click to add ad hoc approvers to the approval chain or remove


existing ad hoc approvers for the selected requests. The table or
flowchart in the Approver tab is updated accordingly.
The Adhoc button is disabled in the following conditions:

Ad Hoc Settings are not defined for the associated process.


The request is in the Process Done stage.

If the Default option is selected for the Ad Hoc Settings of a


process, the AP:AdhocDialog appears for the corresponding
request. See AP:AdhocDialog on page 263.
Close

Click to close the AP:Show-Detail form.

When you click any of the Approve, Reject, Reassign, Hold, or Adhoc buttons, a
dialog box prompts you to enter your password. The request status is changed, or
AP:AdhocDialog is displayed, only if you provide a valid password, otherwise an
error is displayed.

Appendix D

Approval forms

273

BMC Remedy Action Request System 7.6.04

Approver tab
This tab displays a preview of the processes through which the current request
might traverse until it reaches the Completion Check stage.
Table D-41: Fields on AP:Show-DetailApprover tab
Field

Description

Preview Type: Current Click to see a preview of how the current request might traverse
Process Only
through the current approval process.
This preview is generated after the process begins (when the
detail and signature records for the current request have been
created).
Preview Type:
Multiple Processes

Click to see a flowchart or tabular view of the path the current


request might traverse when it pertains to multiple processes.
This view appears only when the Generate-MultiProcess-Preview application command is executed, whose
input values determine the what appears in the view.
See Multi-process preview on page 170.

View As: Sequence


Diagram

Click to see a flowchart view of the current approval request.

View As: Table

Click to see a tabular view of the current approval request.

See Sequence diagram on page 274.


See Table on page 275.

Zoom

Click the icon to see an enlarged flowchart view in a new


window.
Note: This button is available only when viewing the Sequence

Diagram.
Refresh

Click to refresh the contents of this tab.


Note: This button is provided because the mid tier does not allow

the use of the F5 key (Windows) to refresh the contents of the


current screen.

A legend at the bottom of this tab indicates the meaning of the status icons attached
to each signature in the preview.

NOTE
When the AP:Show-Detail form is viewed through versions earlier than 7.5.00 of
BMC Remedy User or BMC Remedy Mid Tier, the Preview Type option on the
Approver tab is unavailable (disabled).

Sequence diagram
The sequence diagram is a flowchart representation of the approval chain for the
current request. If you add or remove an ad hoc approver, or perform any other
action on the request, it is reflected in the flowchart immediately. If an approver
name is not available, the flowchart displays empty blocks in its place. The
flowchart displays only valid approvers.

274

BMC Remedy Approval Server Guide

User forms

The flowchart view is localized; its elements can be displayed in all languages
available with AR System.

NOTE
Localized data is visible only if the Localize Server option is enabled on the
Advanced tab of the AR System Administration: Server Information form. See the
Configuration Guide, Server InformationAdvanced tab, page 123.
The flowchart view is available out-of-the-box on AP:Show-Detail, which has two
related active links, namely, AP:Show-Detail-LoadObject and AP:Show-DetailHandleEvent.
To display a customized flowchart view on your own form, you need:

A Data Visualization Field (DVF) pointing to the Visualizer module.

Two active links that accept three input values, namely, application request ID,
application form name, and detail ID. Providing the detail ID is optional.

NOTE
The DVF cannot be seen using Firefox 2.0.0.11 on Mac 10.4.11; this is an issue with
the browser.
The flowchart view is backward compatible with mid tier releases 7.1.00 and
7.0.01. You can use any version of BMC Remedy User to see the flowchart view for
an approval request, or view it through a browser.

NOTE
When the AR System server has encryption enabled (Premium Security or
Performance Security), the multi-process preview flowchart might take longer to
load.

Table
The table depicts the approval sequence. If you add or remove an ad hoc approver,
or perform any other action on the request, it is reflected in the flowchart
immediately.
Figure D-37: AP:Show-Detail formMulti-process preview table

Appendix D

Approval forms

275

BMC Remedy Action Request System 7.6.04

Activity Log tab


Figure D-38: AP:Show-DetailActivity Log tab

Table D-42: Fields on AP:Show-DetailActivity Log tab (Sheet 1 of 2)


Field

Description

Refresh

Click to refresh the contents of this tab.

Justification For Action Enter some meaningful text in this field to be recorded as a
justification for your action, and click Reject. An entry is added
to the Activity Log table.
If you click any other action button, this field is ignored.
For information about how your input is processed, see
Rejection justification for approval requests on page 40.
After you enter text in this field and click Reject, the entry might
not appear in the Activity Log table. However, the activity is
recorded and the corresponding entry is visible when the
request is opened again in AP:Show-Detail.

276

Activity Log Details

This section enables you add, modify, and delete comments,


questions, notes, and attachments to the current request.

Type

This drop-down list enables you to specify whether you are


creating a comment or a question.

BMC Remedy Approval Server Guide

User forms

Table D-42: Fields on AP:Show-DetailActivity Log tab (Sheet 2 of 2)


Field

Description

Question To

Select a name from the user list or enter the AR System login
name of the person to whom you want to raise a question. This
field is enabled only if you select Question from the Type dropdown list.
Using the Question To field, an approver can ask questions to the
requestor or any other person who belongs to the same group as
the approver.
Note: The approval server does not have any means to know

where a particular users details are stored. (The consuming


applications are responsible to validate the login name.) The
source of a user could be any form other than the User form
that AR System provides, for example, the user information
could be retrieved from an LDAP server.
Question / Summary

This field is labeled as Question when you choose to add a


question to the approval request; enter the question here. It is
labeled as Summary when you choose to add a comment; enter
the brief comment here.

Response / Notes

This field is labeled as Response when you view a question


about the approval request; the corresponding response appears
here. It is labeled as Notes when you choose to add a comment;
enter the detailed comment here.

Attachment

Use this field to add an attachment along with your comment.


Only one attachment is allowed per comment.
If you view a comment that has an attachment associated with it
this table field displays the file name, size, and label for the same.
Note that attachments cannot be associated with questions. This
field gets disabled when you select Questions from the Type
drop-down list.

Submitter

Displays the name of the submitter.

Submit Date

Displays the date and time of submission.

Add

Click to add a comment or question to the approval request. This


field is enabled only if you have the necessary permissions.

Save

Click to save a new comment or question.

Cancel

Click to cancel any new comment or question that you were


trying to add to the current request.

Delete

Click to delete the selected comment or question.

Right click anywhere in this tab to open the Preferences context menu. This menu
enables you to refresh the contents of the table, add or remove columns from the
view, set the refresh interval, and reset or save the changes you make to the table.

Comments
This feature enables submitters (requestor and approvers) to include comments
and attachments for an approval request. These could be useful as additional
information for the next approver in the chain.
Appendix D

Approval forms

277

BMC Remedy Action Request System 7.6.04

Approvers can work with comments in the following ways using this form:

Add or delete their own comments, and view the comments included by other
approvers.

Include an attachment at the time of creating a comment. They can also modify
or delete the attachments associated with their own comments.

Edit or delete comments of other approvers if they are the Alternate Approvers
or Administrators. Approvers other than these can only view the corresponding
details.

Requestors can work with comments in the following ways:

Provide a comment with an attachment through the application form. The


workflow on the Activity Log checks the respective application form for the
requestor's comment on the selected approval request. If a comment is available,
it displays the comment in the Activity Log table.

Modify or delete comments they created. If the requestor modifies a comment


or its attachment, or both, the Activity Log displays the modified details
whenever an approver invokes the Activity Log (or refreshes the table).

Questions
This feature enables approvers to ask questions about an approval request to
requestors and other approvers. These answers could be useful as clarifications to
the current and future approvers in the chain.
Approvers can work with questions in the following ways using this form:

Add, modify, and delete their own questions, and view the questions raised by
other approvers.

Edit or delete questions raised by other approvers if they are the Alternate
Approvers or Administrators. Approvers other than these can only view the
corresponding details.

Requestors can work with questions in the following ways:

Cannot create a question because the Activity Log, which is invoked from
Approval Central, is available only to approvers. A requester does not have
access to the Activity Log.

Provide the response to a question through the More Information form.

The Questions feature works as follows:

278

An approver can raise a question to any user of the system (or application). If
the notifications are configured, the respective user receives a notification. The
user then clicks the Response button in the Approval Request Summary section
of Approval Central to open the AP:MoreInformation form for the request.

An approver can raise only one question at a time per request because, when a
question is created, the status of the request is changed to More Information.
After a requestor or approver responds to the question, the request is again
assigned the Pending status.

BMC Remedy Approval Server Guide

User forms

Approvers can modify or delete the questions they raised before the addressees
respond to them. No notification is sent in this case.

The question details in the table are associated with the Approval ID, Signature
ID, and a Question ID.

Questions cannot be redirected.

Every question can be associated with only one answer.

AP:ShowDetail-DeleteVerify
This dialog box appears when an approver tries to delete an Activity Log entry in
AP:Show-Detail. The entry could be a question, comment, or justification that the
approver created.
You can delete only one entry at a time. You cannot delete entries created by the
requestor or other approvers.

Click Yes to delete the entry for the request. The corresponding record in
AP:Question-Comment-Info is deleted.

Click No to close the dialog box without deleting the entry.

Appendix D

Approval forms

279

BMC Remedy Action Request System 7.6.04

280

BMC Remedy Approval Server Guide

Appendix

Installing the approval server


in a server group
This section describes how to install BMC Remedy Approval Server (approval
server) in an AR System server group.
In an AR System server group environment, two or more servers share the same
database. If one server stops working, another one continues to process requests.
See the Configuration Guide, Configuring server groups, page 183.
In a server group environment, when an AR System server becomes unavailable,
the newly active AR System server performs the following actions:

Sets Approval-Server-Suspended: F in the ar.cfg (Windows) or ar.conf


(UNIX) file on the unavailable server. This indicates that the approval server on
that AR System server is unavailable for processing.

Sets Approval-Server-Suspended: T in the local ar.cfg (Windows) or


ar.conf (UNIX) file. The local approval server begins processing the approval
requests.

Consider that servers with the following configuration are used to set up a server
group named SvrGrp:
Table E-1: Sample server group configuration
Server type Server
name

Processor
Processor Available Operating Database
architecture type
RAM
system

AR System SvrA

SPARC

Dual

4 GB

Solaris 10 -

AR System SvrB

SPARC

Dual

4 GB

Solaris 10 -

Quad

16 GB

Solaris 10 Oracle 10g

Database

DataSvrC SPARC

Instance name:
svrgrpdb

Appendix E

Installing the approval server in a server group

281

BMC Remedy Action Request System 7.6.04

To install the approval server in a server group


1 Install the AR System server on SvrA so that svrgrpdb hosts the AR System server

data files.
2 Install the AR System server on SvrB, as follows:
a Use svrgrpdb as Database Name or Connection String.
b Choose the Server Group mode to install the AR System server.
3 Install the approval server on SvrA and SvrB.
4 Log in to SvrA, and perform the following steps:
a In a browser or BMC Remedy User, open the AR System Administration

Console > System > General > Server Information form.


b On the Configuration tab, select the Server Group Member checkbox.
c On the Advanced tab, enter SvrGrp as the Server Group Name.
d Click OK to apply the changes.

Restart the server for the changes to take effect.


5 Repeat step 4 for SvrB.

NOTE
The change in the Server Group Name is effective only when all servers in the
group are restarted.
6 Log in to any one of the servers, and perform the following steps:
a Open the AR System Server Group Operation Ranking form.
b Configure the approval server operation of Server SvrA to hold Rank 1, and save

the form.
c Configure the approval server operation of Server SvrB to hold Rank 2, and save

the form.
Restart SvrA and SvrB for the changes to take effect.

282

BMC Remedy Approval Server Guide

Appendix

Troubleshooting

This section contains troubleshooting information for BMC Remedy Approval


Server (approval server).
The following topics are provided:

Installation and upgrade (page 283)


Error 333 and Assignee Group Permission (page 284)
Approval server log files (page 284)
Runtime issues (page 285)
Approval server configuration file settings (page 286)
System error messages (page 287)
Accessibility issues (page 287)

Installation and upgrade


This section describes known concerns regarding the approval server installation
or upgrade.

Previous approval server installations


WARNING
Version 7.1.00 or later of the approval server is incompatible with the version of the
approval server bundled with certain Remedy applications. Do not install version
7.1.00 or later of the approval server on a system with any of the following Remedy
applications:

Remedy Purchasing@Work 2.x, or earlier


Remedy SetUp@Work 1.0, or earlier
Remedy Change Management 3.x, or earlier

Appendix F

Troubleshooting

283

BMC Remedy Action Request System 7.6.04

Installer terminates while checking for conflicts


If the installation terminates unexpectedly while the installer is checking for
conflicts, verify whether you have previously installed the approval server or an
application that includes a bundled approval server. You might have to uninstall
the previous installation before you can proceed.

Back up customized workflow


If you have customized a previous approval server installation, or customized an
application that includes a bundled approval server, you should back up your
customized forms, HTML files, and workflow before installation.

Error 333 and Assignee Group Permission


To enable users to enter information into approval server forms, the form, field,
and other object permissions must be set correctly. Most of the required
permission settings are imported when you install the approval server. Only an
AR System administrator, or a subadministrator with administrator permissions
to the objects in question can change access control settings. See the Form and
Application Objects Guide, Defining access control, page 21.
To support multi-tenancy, you must pass the -l parameter with the group values
to the New-Details or Add-Sig command. If you do not pass the -l parameter, the
approval server reports:
ARERR [333] You have no access to field: fieldID.

Approval server log files


The AR System suite installer creates a log that records the results of importing all
the approval server-related definitions and data. After installation, you can turn on
approval server logging.

Location of log files


Two copies of the installation log files are saved in the ARSystemServerInstallDir/
Logs/ folder:

Plain-text format

Approval-RIK_PreInstall.log

Approval-RIK_PostInstall.log

HTMLApproval-RIK_PostInstall.html

ARSystemServerInstallDir is the directory where the AR

System server executable


is installed, such as C:\Program Files\BMC Software\AR System (Windows) or
/opt/bmc/ARSystem (UNIX).
284

BMC Remedy Approval Server Guide

Runtime issues

Log data for an upgrade installation is written to the following files in the same
folder:

Approval-RIK_PostUpgradeInstall.log

upgrade.log

Approver server logging


To verify that the approval server is running or to audit its activities, you can turn
on logging as described in Configuring server settings on page 27. After you
provide the log file name and location and save the server settings, the approval
server begins logging. The first entry in the log file is:
<APPR> Approval Server Trace Log -- ON timeStamp

Runtime issues
This section describes how to resolve some possible runtime issues.

Approver receives request but cannot respond


When approving or rejecting an approval request, an approver might encounter
the following error:
You are not currently defined as an alternate for any user and you
are not on the Approvers list for this approval. (ARERR 10000)

Check the following and take the necessary actions to process the request further:

Is the approvers AR System user name is spelled correctly in the Validate


Approver rule?

Is the approver designated as an alternate approver for a time span in the past
or the future?

Deadlocked approval server


The approval server runs as an ARDBC plug-in. In some cases, such as when using
the preview feature, the approval server makes a call back to the AR System server
to retrieve and compile information. This is referred to as a loopback call, because
the call to the AR System server occurs in response to a call from the AR System
server. If the AR System server queues are overloaded, loopback calls can lead to
a deadlock, and the AR System server will freeze until the calls to the plug-in
server time out.
To prevent this, the approval server requires that the AR System server have a
reserved RPC queue for loopback calls from the Plug-in server. If you do not
configure this, the preview feature will not work. See Private queues for loopback
calls on page 28.

Appendix F

Troubleshooting

285

BMC Remedy Action Request System 7.6.04

Approval server configuration file settings


The ar.cfg (or ar.conf) file is the AR System configuration file. It contains
AR System server configuration settings and is created when you install
AR System server.
In most cases, you do not need to enter the configuration settings manually. When
you make a server configuration change in the Server Information dialog, or in the
Server Settings window of the approval server, AR System enters the
configuration parameters and their new values in the configuration file.
This section describes configuration file settings specific to the approval server. For
information about other configuration file settings, see the Configuration Guide,
AR System configuration files, page 347.
Table F-1: BMC Remedy Approval Server configuration file settings (Sheet 1 of 2)
Configuration setting Description

How to set it

AlternateApproval-Reg

The AR System server


installation creates this entry and
sets the value to T. To change the
setting, use a text editor to edit
the ar.cfg or ar.conf file.

Specifies whether applications such as the approval


server listen for the AR System servers signal
directly (F) or listen for the application dispatcher to
signal (T).
The default value of this setting is T, which makes
sure that the approval server receives the signals
sent by the dispatcher. You should change the value
to F only when the application dispatcher is not
working; this provides an alternative method to
receive signals form the AR System server.
See Application Dispatcher on page 289.

Appr-Defn-Check- The interval (in seconds) after which the approval


Interval
server checks for changed or updated data in the
data definition forms.

AP:Admin-ServerSettings

Approval-LogFile

Full path of the approval server log file.

AP:Admin-ServerSettings

Approval-Notify

Specifies the approval notifications configured from AP:Admin-ServerSettings


the Server Settings dialog box. Each event ID has an
Approval-Notify entry. Only change these settings
from the Server Settings dialog box.

Approval-RPCSocket

A specific RPC program number (RPC socket)


dedicated to the approval server for calls to the
AR System server. This setting defines a private
queue for the approval server.

AP:Admin-ServerSettings

Plugin-Loopback- An RPC program number (RPC socket) dedicated to AP:Admin-ServerSettings or


Server Information dialog box.
RPC-Socket
loopback calls from the Plug-in server. The
approval server runs as a plug-in. If this value is set
and Approval-RPC-Socket is not set, the Plug-in
server uses this queue for approval server loopback
calls.

286

BMC Remedy Approval Server Guide

System error messages

Table F-1: BMC Remedy Approval Server configuration file settings (Sheet 2 of 2)
Configuration setting Description
Approval-PollingInterval

How to set it

This setting causes the approval server to poll the Edit the ar.cfg or ar.conf file
AR System server for pending work. It is intended with a text editor.
to operate as a backup method, not the primary
contact method. Under normal circumstances, the
AR System server or the Application Dispatcher
(depending on the configuration) contacts the
approval server when work is pending.
With this setting in place, the approval server polls
the AR System server only if it does not receive any
signal from the AR System server in the specified
time.
Specify the interval in seconds. The minimum is 30
seconds, and the maximum is 3600 seconds (one
hour). For example:
Approval-Polling-Interval:600

System error messages


The approval server uses error messages in the AR System error range 4500 to
4899. These errors are documented in the Error Messages Guide along with all
other AR System error messages.
Error messages are displayed in English unless specified otherwise. To display
error messages in a localized format, select the Localize Server option on the
Advanced tab of the AR System Administration: Server Information form.

Accessibility issues
When working with approval server forms, you might encounter the following
accessibility issues:

The Select All button on Approval Central does not work for section 508 users.
If the user navigates to the Select All button by using the Tab key and presses
Enter, only the next request is selected instead of all the requests in the table.

The JAWS screen reader is unable to detect the check boxes that indicate which
requests are currently selected.

JAWS does not read aloud the following non-editable fields on Approval
Central:

The Approval Request Summary header

The Source ID link

The Activity Log header

Appendix F

Troubleshooting

287

BMC Remedy Action Request System 7.6.04

288

When a section 508 user opens a menu, a pop-up dialog box appears, which lists
the items in that menu. Then, JAWS reads the items out aloud. If the user presses
Tab, the focus moves to the Cancel button instead of the next item in the menu.

BMC Remedy Approval Server Guide

Glossary
action date

The duration within which an approver must


take action on a pending request. This value is
derived from various process intervals
defined on AP:Process Definition.
Ad Hoc process

An approval process type with no predictable


routing, in which the requester and approvers
select the subsequent approver. See also
Parent-Child, Level, and Rule-Based process
types.
Ad hoc override

In Parent-Child, Level, and Rule-Based


processes, ad hoc overrides approvers to alter
the predetermined routing. The Allow Ad
Hoc Next Approver? field controls whether
the process allows this.
alternate approve

An indication for notifications when an


alternate has responded with an approval.
alternate approver

An AR System user with the authority to


substitute for an approver within an approval
process.
alternate reject

An indication for notifications when an


alternate has responded by rejecting a request.
Application Dispatcher

An AR System server process (Windows) or


daemon (UNIX) installed with the AR System
server that monitors the Application Pending
form, and signals other server applications,
such as the approval server, when they have
work to do.

approval

An electronic signature by an authorized


person. In the approval server, an approval is
indicated by the status Approved on a
request that has followed an automated
process to gather the required signatures.
approval application

An interrelated set of forms, workflow,


processes and rules that allow users to enter a
request and approvers to respond, route the
request to completion, and generate
notifications related to the request.
Approval Audit Trail

A field in the detail form that tracks all status


changes to the approval request, including the
date, time, and approver name.
approval process

A procedure that generates all necessary


signatures to authorize an approval request in
an AR System application.
Approval Process Done

A rule type used to update the request when


the approval process is done. These rules are
used to indicate the result of the approval
process to the original request.
approval request

A request entered in an approval application


to request authorization for a change, an
expenditure, or any other business situation
that requires signatures.
approval request form

An AR System form used by requesters to


enter a request for approval.

Glossary

289

BMC Remedy Action Request System 7.6.04

BMC Remedy Approval Server

An AR System application server that runs as


a plug-in. It routes an applications approval
request form to generate signatures. The
approval server also creates an audit trail for
all approval activity.
approved

The status of a signature when the approver


has authorized the request. Also, the status of
a completed approval request when all
approvers have authorized the request.
approver

An AR System user with the authority to


approve or reject approval requests.
approver list

The list of approvers eligible to respond on the


signature lines for an approval process.
Auto Approval

A rule type that allows for automatic approval


by the approval server of a request that meets
specified criteria.
cancel at later level

An indication for notifications when an


approval process is cancelled after it has been
approved by a previous approver.
cancelled

The status of a completed approval request


that was withdrawn by the requester or
cancelled by an approver or process
administrator.
chained approval process

A sequence of approval processes that appear


to the user as one approval, but in fact are
made up of two or more separate approval
processes.
close approve

An indication for notifications when a request


has multiple possible but not required
approvers and another of the approvers
approves the request.
closed

The status of an approval request that has


been resolved and is no longer waiting for an
approver or More Information response.

290

BMC Remedy Approval Server Guide

close reject

An indication for notification when a request


has multiple possible approvers and another
of the approvers rejects the request.
Completion rule

A rule type that checks whether conditions


exist to stop routing a request. If a completion
check is successful, no new approvers will see
the request. The request might not be done,
but the request has been routed to everyone
who must respond.
detail record

The approval server creates an entry in the


AP:Detail form when a new approval request
is submitted. This form tracks the details of
the approval process for the request. It is part
of the two-way and three-way join forms that
are central to approval processing.
done

An approval request is done when all the


required approvers have responded to the
request, or the request is cancelled, or the
approval server has put the request into an
error state.
error

The status of an incomplete approval request


in which routing problems have occurred.
escalation

A workflow component that searches at


specified times or at regular intervals for
requests matching a specified condition and
performs specified operations on all matching
requests. For approval requests, escalations
are set relative to approval process actions
and states.
Get Authority

A rule type that gathers information about the


current approver or environment that is used
by subsequent Self Approval or Completion
rules.
Get Authority Regular

A rule type that gathers information about the


current approver or environment that is used
by subsequent completion rule tests.

Glossary

Get Authority Self

A rule type that gathers information about the


current approver or environment that is used
by subsequent Self Approval rule tests.
Get Next Approver

A rule type that finds the next approvers in


the current process, including the first
approver at the start of processing. Also, a
stage of the approval process.
hold

An indication for notifications when a request


is changed to the Hold status. This is also a
status in which an approval request is
assigned to an approver but the approver has
held the request. In this case, no approval
server activity occurs until the hold is
removed.
join form

A type of form that contains information from


two or more AR System forms. Join forms
point to the data stored on the AR System
forms that were used to create the join form.
The approval server uses the two-way join
form AP:Detail-Signature, and a three-way
join form, which is a join between the
applications approval request form and
AP:Detail Signature.
Level

An approval process type with relationships


based on the approvers membership in
organizational groups (not AR System
groups). See also Parent-Child, Ad Hoc process,
and Rule-Based.
More Information request

An approvers query for additional data that


becomes part of the audit trail of the approval
request. The approver is not required to delay
the approval request until someone responds.
more info return

An indication for notifications when a More


Information request has been responded to.
new signature

An indication for notifications that a new


signature record has been created for an
approval request.

notification

A message to a user from workflow. This can


be an alert, email, or other message using
integrations. Notifications are linked to the
approval request status and process states.
override approve

An indication for notifications when a process


administrator has approved a request in a
manner that circumvents the normal process.
override reject

An indication for notifications when a process


administrator has rejected a request in a
manner that circumvents the normal process.
Parameterized Get Next Approver

A rule type that uses run-time variables to


find approvers in the current process. It lets
requesters and approvers add additional
approvers to any level in an approval process
(not just the next level).
Parent-Child

An approval process type with a fixed


relationship between approvers, such as a
management hierarchy. See also Level, Ad Hoc
process, and Rule-Based.
pending

The status of an incomplete approval request


awaiting response or more information from
an approver. Also, the status of a signature
line that is waiting for a response from the
approver.
plug-in

An auxiliary program that works with the


AR System server. A plug-in is a dynamically
linked library (DLL) on Microsoft platforms
and a shared object on UNIX platforms. The
AR System plug-in service loads the plug-in at
start time. The approval server is a plug-in.
Prep Get Next Approver

A rule type that gathers information to be


used by the Get Next Approver rules.
process administrator

An AR System user who is a member of the


Approval Admin group (402). Process
administrators can have authority to set up
and maintain approval processes, or to act as
an override approver only.
Glossary

291

BMC Remedy Action Request System 7.6.04

qualification

A condition statement using search criteria


that can include field references, values, and
arithmetical and relational operators. In
approval server processes, rules, and
workflow objects, condition statements are
used to determine whether the process, rule,
or filter should run, and to control data
gathering.
reassign

An action for an approver to reroute a request


by changing the assigned approvers.
reject by another approver

An indication for notifications when multiple


required approvals are outstanding and one
of the other approvers rejects the request.
reject by later level

An indication for notifications when an


approval process is rejected by an approver
after it has been approved by a previous
approver.
rejected

The status of a completed approval request


when an approver has rejected the request.
Also the status of the signature line of the
approver who has rejected the request.
requester

A user who submits a form to request an


approval, triggering approval server action.
role

An entry in the AP:Signature form that


represents the response of an approver to an
approval request.
Signature Accumulator

A rule type that is used to collect statistical


information about the signature records
associated with an approval process.
signature authority

The ability of an approver to authorize a


request, based on policies established by the
organization and defined in a signature
authority form.
signature authority form

A form created by the administrator that


contains approver names or roles and their
signature authority limits, to support data
gathering by get authority rules.
signature record

A database record in the AP:Signature form


that represents the signature of an approver. If
an approval request requires more than one
signature, multiple signature records are
generated for that single approval request.
Statistical Override

A rule type that is used to preempt the default


behavior of the approval process and follow
an approve or reject path before all pending
signatures have been completed.
Status field

A named alias for one or more approvers.


Using roles allows the definition of a position
regardless of the individual approvers who
are currently fulfilling that position.
Rule-Based

A custom approval process type designed by


the process administrator, in which
relationships are defined by rules rather than
by data in a form. See also Parent-Child, Level,
and Ad Hoc process.
Self Approval

A rule type that allows for automatic approval


of a request if the submitter of the request has
sufficient authority for the request to be
approved.

292

signature

BMC Remedy Approval Server Guide

The core field (ID 7) in which AR System


tracks the status of a request. In the approval
server, the AP:Detail form uses this field to
track the overall status of the request. In the
AP:Signature form, the field is renamed to
Approval Status, and it tracks the approval
status of the individual signature line.
Validate Approver

A rule type that is used to verify that a name


specified as the next approver is a valid user.
Only used to verify a user specified in an Ad
Hoc process or an ad hoc override of another
process type.

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
ad hoc
approvers for a request 208, 263
getting next approver in process 78
overrides 43
processes 78
Allow Ad Hoc Next Approver 43
alternate approvers
about 21, 50
acting as 52
defining for others 54
designating 50
modifying 52
Application Dispatcher 72
Application Pending form 72
Application-Command processes
See also Approval Server commands
about 179
Application Pending form and 180
run process action 180
syntax 180
approval applications
connecting to the Approval Server 152
designing 152
Approval Central
about 36
fields 255
form 255
opening from home page 37
opening in a browser 37
opening in BMC Remedy User 37
using 60
approval events 31
Approval Process Done rules
creating 139
examples 93, 140
worksheet 205
approval processes
about 19, 72, 75
Ad Hoc processes 78
Approver Response stage 74

associating with an application 231


chaining 147, 158
completion 236
Completion Check stage 74
creating 98, 157, 196
deleting 104
filters and 148, 157
Level processes 77
modifying 103
Next Approver stage 74
Parent-Child processes 75
Process Done stage 74
process status field and 148
renaming 104
restarting 149
routing 74
Rule-Based processes 79
rules and 72, 157
Self Check stage 74
stages of 73
types 75
workflow and 157
worksheets 196
approval request form 71
approval requests
Approval Status field 41
approving and rejecting 41, 60
checking 66
complete versus done 74
creating 59
detail view 41
pending 38
processing 38
reassigning 45, 61
retrieving 38
routing 74, 76, 77, 78, 85
search criteria 38
viewing 41
approval rule types, diagram 82
approval rules
all get authority 116
Approval Process Done rules 93
Index

293

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
associating with a process 112
Auto Approval rules 83
Completion rules 92
creating 110, 200
defining actions 113
deleting 141
Get Authority Regular rules 91
Get Authority rules 84
Get Authority Self rules 84
Get Next Approver rules 85
modifying 141
order 112
Parameterized Get Next Approver rules 86
Prep Get Next Approver rules 85
processes and 82
qualifying conditions 112
querying 113
running server processes 113
Self Approval rules 84
setting values 113
Signature Accumulator rules 88
SQL commands in 113
Statistical Override rules 88
Validate Approver rules 86
worksheets 200
Approval Server
basic concepts 19
configuring 24, 286
connecting an application 152
error messages 287
flowcharts and 33
forms 207
server settings 27
upgrading 174
Approval Server commands
Add-PGNA-Values 168, 182
Add-Sig 183
Det-Approved 184
Det-Cancelled 184
Det-Error 185
Det-Rejected 185
Generate-Multi-Process-Preview 186
Generate-Preview 186
MoreInfo-Return 187
New-Details 187
Rename-Form 188
Rename-Process 188
Sig-Approved 189
Sig-Cancelled 189
Sig-Notify 190
Sig-Notify-Change 190
Sig-Notify-State 191

294

BMC Remedy Approval Server Guide

Sig-Reassign 192
Sig-Rejected 192
Update-Config 193
Approval Status options 87
approver list
about 20
Get Next Approver rules and 124
approver name length 95
Approver Response stage
about 74
rules in 87
approvers
about 20
adding 43
cannot respond 285
field menu of approver names 168
manual specification of 43
multiple 106
next approver 43
AR System configuration files 286
AR System object list 37
ar.cfg 286
ar.conf 286
arjoinfix
connecting applications to the Approval
Server 156
portnum parameter 156
updating three-way join forms 176
Assignee Group Permissions field
multi-tenancy and 238
rule configuration 112
Auto Approval rules
about 82
creating 114
examples 83, 115
Self Check stage and 74

B
BMC Software, contacting 2
business time, configuring 32

C
chaining approval processes 147, 158
Completion Check stage
about 74
rules in 91
Completion rules
about 92
configuring processes and 236
creating 138

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
determining success 92
examples 91, 92, 138
worksheet 204
configuring
Approval Server 24
flowcharts 33
process administrator 26
customer support 3

D
debug log 27
definition check interval 30
documentation, AR System 13

E
error messages 287
escalations, configuring 32

F
field permissions, troubleshooting 284
filters, approval processes and 148
flowcharts, Approval Server and 33
forms
See also forms, application; forms, Approval
Server; forms, Get Agreement; forms, Lunch
Scheduler
administration forms 208
renaming 104
user forms 255
workflow and 166
forms, application
approval request
about 71
arjoinfix and 156
connecting to the Approval Server 152
creating 153
linking a process to 231
linking to the Approval Server 157
permissions 153
signature authority 72
supporting forms
about 70
examples 146
three-way joins
about 71, 153
arjoinfix and 177
creating 154
request details 41

updating for release 7.x.xx functionality 176


two-way joins
about 153
creating 154
forms, Approval Server
AP:Admin-DeleteVerify, fields in 210
AP:Administration
creating processes 98
creating rules 110
fields in 209
Form tab 157
using 24
AP:Admin-Rename
fields in 210
using 104
AP:Admin-ServerSettings
escalations 32
fields in 212
notifications 31
using 27
AP:Alternate, fields in 266
AP:Detail
about 70
fields in 216
AP:Detail-Signature
about 71
fields in 217
AP:Dtl-Sig-MoreInfoDialog, fields in 268
AP:Form, fields in 220
AP:More Information
about 72
fields in 269
permissions 64
using 62
AP:Notification
Basic 159
Details 162
Email 163
fields in 223
AP:Password, fields in 270
AP:Pending Approvals 255
AP:PreviewInfo
approver name length and 95
configuring previews 33
fields in 227
retrieving data from 168
AP:PreviewSignatures 95
AP:Process Administrator, fields in 229
AP:Process Definition
creating a process 98
defining More Information escalations 103
defining signature escalations 101

Index

295

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
fields in 231
AP:Reserved Word, fields in 245
AP:Role
defining roles 106
fields in 246
AP:Rule Definition
Basic 111
fields in 247
Set Fields 113
AP:Signature
about 71
fields in 252
Application Pending, about 72
Approval Central
Approval Central and 36
fields in 255

G
Get Agreement
about 58
activating rules 136
AP-Sample2:Get Agreement form 59
AP-Sample2:Issue Detail Signat form 62
sample users 58
statistical decision-making rules in 133
three-way join form 62
Get Authority Regular rules
Completion stage and 91
creating 116
worksheet 203
Get Authority rules
about 82
creating 116
examples 117
using with Self Approval rules 84
versus Get Authority Self rules 84
worksheet 200
Get Authority Self rules
about 82
creating 116
using with Self Approval rules 84
versus Get Authority rules 84
worksheet 201
Get Next Approver rules
about 85
approver list and 124
creating 121, 123
examples 85, 125
Level processes 122
multiple rules 124
Parent-Child processes 122
296

BMC Remedy Approval Server Guide

Rule-Based processes 123


worksheet 202

I
If Multiple Approvers
field values for 106
installation, troubleshooting and 283

L
Level processes
about 77
examples 145
getting next approver 77
requirements 77
licensing sample users 150
log files
about 27
configuring 30
using 284
loopback calls
avoiding deadlocks 285
private queues and 28
Lunch Scheduler
about 144
AP-Sample:Company form 146
AP-Sample:Lunch Scheduler form 145
AP-Sample:Lunch-Detail form 145
AP-Sample:Lunch-Detail-Signatu form 145
AP-Sample:Restaurant form 146
AP-Sample:Signature Authority form 72, 146
defining signature limits 134
forms in 145
Level process example 147
licensing users 150
Parent-Child process example 146
process functionality 148
processes in 145, 146
Rule-Based process example 147
users 150

M
More Information escalations, creating 103, 196
More Information requests
about 45
Approval Status and 63
creating 46, 62
responding 47, 63
viewing 47

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
viewing responses 48, 65
viewing your submitted 48
multi-tenancy
Assignee Group Permissions field 112
supporting 238

N
Next Approver stage
about 74
ad hoc next approvers 86
rules in 85
notifications
configuring 31
creating 158
Notify On options 160
workflow-based 165
Notify On options 160

O
overrides
global 55
performing 54
single signature 55

P
Parameterized Get Next Approver rules
about 85
creating 126
examples 128
previews and 86, 168
versus Get Next Approver rules 86
worksheet 203
Parent-Child processes
about 75
examples 145
getting next approver 76
requirements 76
passwords
requiring for approval 237
show field dynamically 167
Plugin Loopback RPC Socket, configuring 28, 30
Plug-in server
configuring 30
loopback calls 285
portmapper, arjoinfix and 156
Prep Get Next Approver rules
about 85
creating 120

examples 85, 120


Get Next Approver rules and 85
worksheet 202
previews
Add-PGNA-Values command and 168
AP:Preview Data form 226
configuring 33, 168, 234
flowchart view 274
multi-process preview 170, 226
options 234
Parameterized Get Next Approver rules and 168
tabular view 275
Private AR Server RPC Socket, configuring 28, 30
private queues
See also Plugin Loopback RPC Socket; Private
AR Server RPC Socket
about 285
process administrators
about 21
capabilities 25
configuring 26
creating 26
defining alternate approvers 54
performing overrides 54
prerequisites 26
responsibilities 25
Process Done stage
about 74
rules in 93
process status field 148
processes, about approval 19
product support 3

R
requesters 20
requests
AP:Show-Detail form 271
reassigning 45
viewing details 271
roles
about 20, 106
defining 106
RPC sockets 30
Rule-Based processes
about 79
examples 145
getting next approver 79
requirements 79

Index

297

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

sample applications
Get Agreement 58
Lunch Scheduler 144
sample forms
Get Agreement 59
Lunch Scheduler 145
sample users, approval authority 150
security, requiring passwords to approve 237
Self Approval rules
about 82
creating 118
examples 84, 119
get authority rules and 83
Self Check stage and 74
worksheet 201
Self Check stage
about 74
rules in 82
Signature Accumulator rules
about 88
creating 131
default statistical data and 131
examples 89, 132
Get Agreement functionality 133, 135
Level processes and 89
signature lines and 89
worksheet 204
signature authority
form 72
Lunch Scheduler sample application and 150
signatures
creating escalations 101, 197
creating lines 85
limits 134
specifying additional approvers 43
statistical decision-making rules
See also Signature Accumulator rules; Statistical
Override rules
about 88
Statistical Override rules
about 88
actions 89
creating 132
default data and 90, 137
examples 133
Get Agreement functionality 135
process types and 89
worksheet 204
status 41
support, customer 3

technical support 3
three-way join forms
See also forms, application
example 145
troubleshooting
configuration file settings 286
deadlocked Approval Server 285
error messages 287
field permission errors 284
installation 283
two-way join forms
See also forms, application
example 145

298

BMC Remedy Approval Server Guide

U
upgrading the Approval Server 174
users, licensing sample 150

V
Validate Approver rules
about 85
creating 129
examples 86, 130
worksheet 201

W
Web access 178
workflow
enhancing Approval Server forms 166
notifications and 165
worksheets
More Information escalations 196
processes 196
rules 200
signature escalations 197

*183967*
*183967*
*183967*
*183967*
*183967*