ApprovalServer 7604 PDF

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 Telephone 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.
Copyright 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Overview of the approval server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Flexibility and common experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Notification with feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Basic approval server concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Approval roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 2 Configuring the approval server 23

Using the approval server Administration form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Process administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring process administrator capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Process administrator prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Creating a process administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Configuring server settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Approval server debug log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Private queues for loopback calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Configuring settings on the Basic tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring settings on the Notifications tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Configuring settings on the Escalations tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Configuring business times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Configuring previews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Configuring the approval server to work with flowcharts . . . . . . . . . . . . . . . . . . . . . . 33
Chapter 3 Processing approval requests 35

Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Opening Approval Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
AR System Object List in browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Working with pending approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Processing an approval request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Performing a search on Approval Central. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Contents 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Creating a rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Using the Basic tab on the Rule Definition form. . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Using the Set Fields tab on the Rule Definition form. . . . . . . . . . . . . . . . . . . . . . . 113
Example of the Set Fields tab for a query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Defining approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Defining Auto Approval rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Example of an Auto Approval rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Defining all Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Example of a Get Authority rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Defining Self Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Example of a Self Approval rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Defining Prep Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Example of a Prep Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Defining Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Process type and Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Creating a Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Example of a Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Defining Parameterized Get Next Approver rules. . . . . . . . . . . . . . . . . . . . . . . . . 126
Example of Parameterized Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . 128
Defining Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Example of a Validate Approver rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Defining Signature Accumulator rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Example of a Signature Accumulator rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Defining Statistical Override rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Example of decision-making rules in a sample application . . . . . . . . . . . . . . . . . 133
Example of a Statistical Override rule with default data. . . . . . . . . . . . . . . . . . . . 137
Defining Completion rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Example of a Completion rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Defining Approval Process Done rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Example of an Approval Process Done rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Contents 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

Example of an application command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Approval server commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Add-PGNA-Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Sig-Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Sig-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Update-Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Appendix C Worksheets 195

Process worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Defining a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
More Information escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Signature escalations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Rule worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Auto Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Get Authority Self rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Self Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Prep Get Next Approver rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Get Authority Regular rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Parameterized Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Signature Accumulator rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Statistical Override rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Completion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Approval Process Done rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Appendix D Approval forms 207

Administration forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
AP:AdhocDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
AP:Admin-DeleteVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Contents 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

Glossary 289
Index 293
Contents 11
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 Audience

Concepts Guide1 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 Information about the development of AR System Developers2
Development with applications, including an introduction to using
BMC Remedy Developer BMC Remedy Developer Studio.
Studio
Form and Application Information about AR System applications and their user Developers
Objects Guide interface components, including forms, fields, views,
menus, and images.
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 Administrators
clients, localizing, importing and exporting data, and
archiving data.
BMC Remedy Mid Tier Information about configuring the mid tier, setting up Administrators
Guide applications for the mid tier, and using applications in
browsers.
Integration Guide Instructions for integrating AR System with external Administrators/
systems by using web services, plug-ins, and other products, Developers/
including LDAP, OLE, and ARDBC. Programmers3
Optimizing and Information about monitoring and maintaining AR System Administrators/
Troubleshooting Guide and AR System applications to optimize performance and Developers/
solve problems. Programmers
Database Reference Database administration topics and rules related to how Administrators/
AR System interacts with specific databases; includes an Developers/
overview of the data dictionary tables. Programmers
BMC Remedy Distributed Information about implementing a distributed AR System Administrators
Server Option Guide server environment with BMC Remedy Distributed Server
Option (DSO).
BMC Remedy Flashboards Instructions for creating, modifying, and administering Administrators/
Guide flashboards to display and monitor AR System information. Developers
C API Reference Information about AR System data structures, C API Programmers
function calls, and OLE support.
C API Quick Reference Quick reference to C API function calls. Programmers

AR System documents
Title Description Audience

Java API Information about Oracle Java classes, methods, and Programmers
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 Instructions for configuring and using BMC Remedy Email Administrators
Guide Engine.
Error Messages Guide Descriptions of AR System error messages. Administrators/
Developers/
Programmers
Master Index Combined index of all books. Everyone
BMC Remedy Approval Instructions for using BMC Remedy Approval Server to Administrators
Server Guide automate approval and signature processes in your
organization.
Release Notes Information about new features, compatibility, and Everyone
international issues.
Release Notes with Known Information about new features, compatibility, international Everyone
Issues issues, installation planning, and open issues.
BMC Remedy User Help Instructions for using BMC Remedy User. Everyone
BMC Remedy Developer Instructions for using BMC Remedy Developer Studio to Developers
Studio Help develop AR System forms, workflow objects, and
applications.
BMC Remedy Data Import Instructions for using BMC Remedy Data Import. Administrators
Help
BMC Remedy Alert Help Instructions for using BMC Remedy Alert. Everyone
BMC Remedy Mid Tier Instructions for configuring BMC Remedy Mid Tier. Administrators
Configuration Tool Help
BMC Remedy Browser Instructions for using AR System forms in browsers. Everyone
Help
BMC Remedy Migrator Outlines procedures for installing BMC Remedy Migrator, Administrators /
7.6.04 BMC Remedy setting options, and performing migration tasks. Developers
Migrator Guide
BMC Remedy Migrator Procedures for setting BMC Remedy Migrator options and Administrators /
online help performing migration tasks. Developers
BMC Remedy Encryption Provides an overview of the BMC Remedy Encryption Administrators
Security 7.6.04 Security products and explains how to install and configure
BMC Remedy Encryption them.
Security Guide
1
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
the BMC Remedy Migrator Guide and BMC Remedy Encryption Security Guide.
2 Application developers who use BMC Remedy Developer Studio.
3 C and Java programmers who write plug-ins and clients for AR System.

Chapter
1 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)

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

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.

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.

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.

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
2 Configuring the approval

server
This section describes the procedures that process administrators use to configure
BMC Remedy Approval Server (approval server).
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)

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.

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.

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

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.

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

<APPR> Tag -- Approval-Defn-Check-Interval:

<APPR> Other Short --
<APPR>
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.

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-Loopback-
RPC-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, Approval-
RPC-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-Loopback-
RPC-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.

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 sub-
plugin.
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

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.

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.

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.

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.

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

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.

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.

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.

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

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)

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

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.

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
To specify next approvers

The relevant request form appears.
3 Click the Show Signatures button.
The appropriate three-way join form.

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.

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

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.

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.

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

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

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-Sig-
MoreInfoDialog 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

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.

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

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.

To view a pending More Information request

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.

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.

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

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.

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

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.

Figure 3-8: Acting as an alternate approver
To view all requests for which you are an alternate approver

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.

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.

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).
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.
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).
In the Acting As field, select Global Override.
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
4 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.
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)

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.

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.

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.


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.

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

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.

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.

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.

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.

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.

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.

Chapter
5 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).
Approval server data and forms (page 70)
Approval processes (page 72)
Approval server rules (page 82)
Approver fields (page 94)

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.

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 AP-
Sample2: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.

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

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 Someone
Requester Another Entirely
Approver Arbitrary
Requester 1 Requester
not approved More Information
Self Check Request (optional)
Requester
2
Next Approver
approved Approver Response
Yes
3
More
approvers? Approval
Cycle
5 No 4
Process Completion Approved
Done Check
Rejected

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.

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.

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

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.

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.

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 Get Next Approver and Parameterized
process administrator defines Get Next Approver rules determine
the relationships between the relationship of the next approver to
individuals. 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 Determined manually by users.
approvers entered by the
requester or approvers.
Rule-Based Custom, as determined by the Custom, as determined by the Process
Process Administrator. Administrator. Parameterized Get
Next Approver rules can add
approvers.

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.

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.

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 Ad hoc?
Approver No
Yes
Invalid
Validate
Approver?
Requester
Valid
Submit Request
Signature
line error
Approver
1 Response
No Get (Wait for)
Auto Approval? Authority Correction
Yes
Signature
Get Accumulator
Yes Authority No More
Self
approvers?
Approval
Cycle Rejected
Statistical
Self Override
approval?
No Yes 3
5 Approved
Process Yes No Outstanding
Done signatures?
Get Authority
Yes Get Authority

Regular
4
No
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:
Auto Approval
Get Authority or Get Authority Self
Self Approval

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 No 2
Auto Approval? Get
Authority Next
Approver
Yes Get Approval

Authority Cycle
Self
Self No
Approval?
Process Yes
Done
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.

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.

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 Rule-
Based process)
To create a Get Next Approver rule, see Defining Get Next Approver rules on
page 121.

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.

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 Ad hoc?
Approver No
Yes
Invalid
Validate
Approver?
Submit Request
Valid
Requester Not Signature

approved line error
Self Check
(Wait for)
Approved Correction Approver
Response
Yes
Approved
More
approvers? Approval
Cycle
No
Process Completion
Done 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.

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.

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 Rejecting requests
Level Only signatures for Preempts the approval server Preempts the approval server to reject
the current level to proceed to the next level. the request and stop the processing.
Parent-Child All signatures, at all Preempts the approval server Preempts the approval server to reject
times to proceed to proceed to next the request and stop the processing.
parent.
Ad Hoc All signatures, at all Preempts the approval server Preempts the approval server to reject
times to approve the request. the request and stop the processing.
Rule-Based All signatures, at all Preempts the approval server Preempts the approval server to reject
times to proceed to the next set of the request and stop the processing.
approvers.

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 No
Override Default
Rules? Logic
Yes
Signature
Accumulator Statistical
Rules
Statistical
Override
No More Yes
Preempt? Signatures?
Yes No
Cancel Active Wait for more

Signatures Error Signatures
No Yes Default
Reject Approve?
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:
Total Signatures
Total Approved
Total Rejected
Total Pending

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.

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.

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

Submit Request
Requester Requester
not approved
Self Check
Next Approver
Requester Approver Response
approved
Yes
Signature
No More Accumulator
approvers? Approval
Cycle
No
Rejected
Process Statistical
Done Override?
Completion
Approved
Yes
Yes
No Get Authority
Outstanding
signatures?
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.

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 AP:Signature
AP:PreviewSignatures
13205 Next Approvers AP:Signature
13207 Approvers AP:Signature
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 DB2 4000
IBM Informix 255
Microsoft SQL Server 8000
Note: Even though the VARCHAR limit on SQL Server is 8000
characters, apchgschema sets the field length to 4000
characters to support Unicode.
Oracle 4000
Sybase 255

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.

Table 5-5: Parameters for the apchgschema utility

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

Chapter
6 Defining an approval process
This section describes the procedures to create and modify processes in

BMC Remedy Approval Server (approval server).
Using the Process tab on AP:Administration (page 98)
Creating a process (page 98)
Working with existing processes (page 103)
Defining roles (page 106)

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

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.

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.

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.

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.

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.

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.

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.
2 Click Rename in the navigation pane.
The approval server Rename dialog box (AP:Admin-Rename form) appears as

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.

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.

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
7 Defining approval rules
This section describes how to create and modify rules in BMC Remedy Approval
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)

Using the Rule tab on AP:Administration

To create and manage rules, you use the Rule tab on the AP:Administration form.
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.

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.

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.

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.

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.

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

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

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

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

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.

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

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

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

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.

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

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

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.

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.
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.
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.
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.
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
12 Click Save.

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.

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

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

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.
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.
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.
8 For a query, select a form name from the From Form menu. This value indicates in
which form to search for the query.

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.

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.

To define a Validate Approver 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.
AlternateThe form exists on another server. Enter the server name where the
form is located in the Server field.
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).

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.

To define Signature Accumulator rules

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

To define a Statistical Override 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.
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.
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.

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

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.

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.

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

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

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.

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

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.
3 Select a value from the Set Field Type list. See Using the Set Fields tab on the Rule
Definition form on page 113.

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

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

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

To delete a rule
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.

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

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

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.

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 Parent-
Child 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 New-
Details on page 187.

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 New-
Details on page 187.

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.

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

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, AP-
Sample:Test Level Approval, runs whenever the approval request is modified.
This filter runs only after the Approval Workspace field is marked Cost-
Approved, 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.)

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

Chapter
9 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.

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)

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.

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 Allow any user to
submit
1 Request ID Assignee (view)
Public (view)
2 Submitter Assignee (view) Yes
Public (view)
3 Create Date Assignee (view)
Public (view)
4 Assigned To Assignee (change) Yes
Public (view)
5 Last Modified By Assignee (view)
6 Modified Date Assignee (view)
7 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.

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.

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.

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.

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.

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:
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

Creating notifications
When the normal approval cycle has been overridden by an approver or the
Process Administrator
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.

The AP:Notification form opens in New mode, with the Basic tab selected, as
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)

Option Triggering event Default notify list
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 An alternate approves the approval request. Individual
Approve Approved for.


Alternate Reject An alternate rejects the approval request. Individual
Approved for.
Override Approve A user with override capability approves the Approver list.
approval request.
Override Reject A user with override capability rejects the Approver list.
approval request.
Global Approve An administrator performs a global approve, Approver list.
terminating a process for a request.
Global Reject An administrator performs a global reject, Approver list.
terminating a process for a request.
Reassign An approval is reassigned to a different Approver list.
approver.
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 The approval request is rejected after this Approver list.
Level signature is approved.
Cancel at Later The approval request is cancelled after this Approver list.
Level signature is approved.
Reject by Another The approval request is rejected by another Approver list.
Approver signature record.
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 A Still Active notification has been sent and no Approver list.
(repeat) 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 A Still Pending notification has been sent and Approver list.
(repeat) 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 Approver list.
action has occurred.


Still More Info More information has been requested for an Approver list.
approval request and there has been no action.
Still More Info A Still More Info notification has been sent and Approver list.
(repeat) no action has occurred.
Still Error An error in the approval cycle has occurred Approver list.
and there has been no action to correct the
error.
Still Error (repeat) A Still Error notification has been sent and no Approver list.
action has occurred to correct the error.
Change After A change occurs that all past approvers should Approver list.
Approved 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:

No MessageSend no notification.

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.

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.

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.

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-Sig-
MoreInfoDialog 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.

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 three-
way 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.

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.

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.

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:
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:Show-
Detail.
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.

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 10012 Set to Yes to indicate that this record is ready to be used for the
corresponding request.
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$


Appendix
A 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 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)

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 Form
7.1.00 or later Process Instance ID AP:Alternate
Requestor 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
s The name of the AR System server.
portnum If the AR System server is configured to run on a port, the appropriate
port number.
i The location of the AR System installer.
For example, C:\Program Files\BMC Software\ARSystem
u The admin users login ID.
p The admin users password.
l 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.

Running one-time escalations to configure new data
Table A-2: The approval server upgrade utility parameters (Sheet 2 of 2)

Parameter Value
o 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.
f 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.
h 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.

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.

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.

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

Appendix
B Application commands
To support interaction between the AR System server and BMC Remedy Approval
Server (approval server), you use a special AR System process, Application-
Command. You can run this process from filters, escalations, and active links using
the Run Process action.
Using Application-Command processes (page 180)
Approval server commands (page 182)

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)

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.

Using Application-Command processes
Table B-1: Application command parameters (Sheet 2 of 2)

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

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

-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"

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

-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.
1Signature line is not independent
0 or any other valueSignature line is independent
-2 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.
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.
-l 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.

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

-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

Cancelled.

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

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

Rejected.

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

-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

-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.
For example:
Generate-Preview -o Generate-Preview -e $RequestID$
-s AS ADDSIG:Lunch Scheduler
-t AS ADDSIG:Management Cost Authorization

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

-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

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.

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

-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

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

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

-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

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.

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:Detail-
Signature join.
Table B-16: Sig-Notify command parameters

-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]
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

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.

Sig-Notify-State
Sig-Notify-State -s formName -e requestID [-t processName]
[-1 numNotifications] -2 {0|3|4|6|otherState} [-3 {0|1}]
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

-s formName must be the AP:Signature form.
-e requestID identifies the request being processed.
AP:Signature form.
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.
-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.
-2 This parameter specifies the numeric value of the state the notification is for.
It can be set to 0 (Pending), 3 (Hold), 4 (More Information), or 6 (Error).
otherState will default to 0 (Pending).
-3 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.

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

-s If supplied, formName must be the AP:Signature form.
-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

-s If supplied, formName must be the AP:Signature form.
-t If supplied, processName must match the process specified by the detail
record that is associated with the specified signature line.

Update-Config
Update-Config -t settingLabel [-o settingValue]
This command updates administrative configuration settings for the application.
Table B-21: Update-Config command parameters

-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
C 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.
Process worksheets (page 196)
Rule worksheets (page 200)

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 One Must Sign All Must Sign Allow Only One
Approvers Approver
Allow Ad Hoc Next Anyone Approver No one
Approver?
For Self Assignment Use Get Next Assign to Always Assign to
Approver Rules Owner If Owner
Approver
Validate Approvers? Yes No
Require Password? Yes No
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
First Interval Unit
Repeat Interval Unit

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 Unit
Change State o Pending o Approved o Rejected
First Interval Unit
Notification: Still in StatePending
First Interval Unit
Notification: Still in StateError
First Interval Unit
Notification: Still in StateHold
First Interval Unit
Notification: Still in StateMore Information
First Interval Unit

Urgent priority notifications

Use Schedules
Business Calendar
Holiday Calendar
Automatic Action
After Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit

Process worksheets
Low priority notifications

Use Schedules
Business Calendar
Holiday Calendar
Automatic Action
After Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit
First Interval Unit

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 o Process o Other
From Form
On Server Server
Qualification
Set Field Value

Rule worksheets
Get Authority Self rules

Rule Name
Purpose
For Process
Run If
Qualification
From Form
On Server Server
Qualification
Set Field Value
Self Approval rules

Rule Name
Purpose
For Process
Rule
Audit Text

Rule Name
Purpose
For Process
Run If
Qualification
From Form
On Server Server
Qualification


Rule Name
Purpose
Rule Type
Run If Statement
From Form
On Server Server
Qualification
Set Field Value

Rule Name
Purpose
Rule Type
If Multiple o Value from First o Values from All
Results o Return Error o clear
If Multiple o One Must Sign o All Must Sign o clear
Approvers
Next Approver o Additive o Ending o Exclusive o clear
Rule Is
Run If Statement
From Form
On Server Server
Qualification
Set Field Value

Rule worksheets
Get Authority Regular rules

Rule Name
Purpose
For Process
Run If
Qualification
From Form
On Server Server
Qualification
Set Field Value
Parameterized Get Next Approver rules

Rule Name
Purpose
Rule Type
If Multiple o Value from First o Values from All
Results o Return Error o clear
If Multiple o One Must Sign o All Must Sign o clear
Approvers
Next Approver o Additive o Ending o Exclusive o clear
Rule Is
Guaranteed Add o No o Yes
Run If Statement
From Form
On Server Server
Qualification
Set Field Value


Rule Name
Purpose
For Process
Run If
Qualification
From Form
On Server Server
Set Field Value

Rule Name
Purpose
For Process
Run If
Qualification
From Form
On Server Server
Set Field Value
Completion rules
Rule Name
Purpose
For Process
Rule

Rule worksheets
Approval Process Done rules

Rule Name
Purpose
For Process
Rule State o Approved o Rejected o Cancelled o Error
From Form
On Server Server
Set Field Value


Appendix
D 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.
Administration forms (page 208)
User forms (page 255)

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 OneIndicates that at least one ad hoc approver must approve the
AllIndicates that at all the ad hoc approver must approve the
Independent 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.

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 The current sequence of the corresponding process.
Sequence
Application The request ID of the application through which the corresponding
Request ID 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

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, Click a tab to display a list of items of that type. This also selects
notification, role, which category of items is used when you click the buttons on this
form, administrator, form.
alternate
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:Admin-
Rename 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:Question-
Comment-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.

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 Select the process name from the menu. When AR System
renamed / supplies the GUID, select the supplied GUID.
Select GUID of the
process to be renamed
Enter new process Type the replacement name for the process or form.
name / The name of a process can be as long as 80 bytes. This equates to
Enter new form name 80 characters in English and most European languages, but only
40 characters in double-byte languages.
Scope of update Select an option from the menu to determine which of the
associated detail records are renamed.
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.
Including object itself 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.

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 Type the directory path and file name for the log file.

Table D-4: Fields on AP:Admin-ServerSettingsBasic tab (Sheet 2 of 2)

Field Description
Other Settings
Definition Check Type a number of seconds to define how often the approval
Interval 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 Type the RPC socket number of a private queue used for
Socket 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
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.

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 Error

Approve Cancel
Reject More Info Return
Alternate Approve Reject by /at Later Level
Alternate Reject Cancel at Later Level
Override Approve Reject by Another Approver
Override Reject Hold
Global Approve More Info
Global Reject Change After Approval / Approved
Reassign 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.

Escalations tab
Figure D-6: AP:Admin-ServerSettings formEscalations tab
Table D-5: Fields on AP:Admin-ServerSettingsEscalations tab

Field Description
Still Active Disabled means the approval server disables escalations for
Still Active (repeat) this event type during an approval process.
Still Pending Enabled means the approval server enables escalations for
the approver list when this event type occurs during an
Still Pending (repeat) approval process.
Still Hold Enabled Including Alternate (default setting) means the
Still Hold (repeat) approval server enables escalations to the approver list as
Still More Info well all active alternates when this event type occurs during
an approval process.
Still More Info (repeat)
These settings enable escalations for each event type. To use
Still Error
escalations, you must define the specific escalations for each
Still Error (repeat) 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.

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)

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.

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 The AR System populates this field with the Assignee Group for
Permissions 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

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

Table D-7: Fields on AP:Detail-Signature (Sheet 2 of 2)

Field Description
Permission 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:Show-
Detail form. The default labels for these fields are GL Account, Cost Center, Total
Cost, and Phase, respectively.
Figure D-9: AP:DynamicLabels form

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)

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.

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

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 Map to an application IDit could be the request ID or any other
ID 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} The values from the mapped fields are displayed in the top panel
Field 4 {14509} on AP:Show-Detail.
For example, for a request of the Lunch Scheduler sample
Field 5 {14510}
application, these values appear against the following labels:
Field 6 {14511} 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.

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.

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

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

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
Footer Enter the names of templates to use for the footer of the email

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 Generate-
Multi-Process-Preview command. See Generate-Multi-Process-Preview on
page 186.

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

Table D-15: Fields on AP:PreviewInfo

Field Description
Request/Ticket The request ID that you want previewed.
Number
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 Select the application form name related to the request.
Name
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.

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

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.
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.
Notify Method 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.
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.
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.
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.


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.


Field Description
Type Select the process type from the available options:
Parent-Child
Level
Ad Hoc
Rule-Based
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.
form.
This field is required for Ad Hoc process type, optional if you
allow ad hoc overrides, and otherwise unused.


Field Description
Type Select the process type from the available options:
Parent-Child
Level
Ad Hoc
Rule-Based
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.
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.
form.
This field is required for Ad Hoc process type, optional if you
allow ad hoc overrides, and otherwise unused.


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.


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.


Field Description
Approval Success Select the manner with which the approval server determines
whether the approval process for a request is complete:
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.
If Multiple Approvers 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.
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.


Field Description
Allow Ad Hoc Next This field applies to Parent-Child, Level, and Rule-Based process
Approver? types.
Specify using the available option whether users can add
approvers to the approver list for a request:
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.
For Self Assignment 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.
Always Assign to OwnerUse the requestor as the first
approver in all cases.
Validate Approvers 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:
YesValidate the approvers when saving a request.
No(Default) Skip validating approvers.
Require password 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.


Field Description
Permissions 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:
Default(Default) Disables the adjacent Ad Hoc Form field.
When an approver clicks the Adhoc button on AP:Show-
Detail, 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:Show-
Detail, 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.
Ad Hoc Form 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.
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.

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.

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

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 Select the menu from which to derive user names for the
Reassign corresponding operations.
Ad-hoc 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 Select Yes to make it mandatory for an approver to provide a
on Rejection 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:Question-
Comment-Info. See AP:Rejection Justification on page 271.

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 Select the unit of Hours or Days as the unit for the interval in the
previous field.

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:Show-
Detail on page 271 and Approval Central on page 255.
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.
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.
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
field.

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
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.
field.
For more information about the Administrative Information tab, see

Administrative Information tab on page 267.

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:Show-
Detail, 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 Response
Notes
Application form 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

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 Select the name of the special control group for you want to have
Permissions 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

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.

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.
ActiveThis role can be used by any approval process.
InactiveThis role is disabled for all approval processes.
Member List 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 double-
byte languages.
For Process Use the drop-down list to select a process for this rule.


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.
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.
approvers. Only one of those approvers needs to take action
on the request.
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.
See Error 333 and Assignee Group Permission on page 284.


Field Description
Qualification
Run if This field label appears for the following rule types:
Get Authority
Get Authority Self
Get Next Approver
Parameterized Get Next Approval Rule
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
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
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
$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.


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

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.
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.
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
$Submitter$ = John
then the value from the current transaction is returned:
John = John

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.

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

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:
approvers in the Next Approver field. Only one of those
approvers needs to take action on the request.
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.
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.

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

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.

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.

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.

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 Click this link to open the AP:Alternate form in New mode.
Approvers 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

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.

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

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.

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.

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.

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.
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.
Independent Select one of the options.
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.
Note: This menu is available on the mid tier only.

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.

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.

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

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)

Field Description
Existing More This field displays any More Information records attached to the
Information records current approval process.
Refresh Refreshes the list.

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.

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.

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.

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

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.

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: Click to see a flowchart or tabular view of the path the current
Multiple Processes request might traverse when it pertains to multiple processes.
This view appears only when the Generate-Multi-
Process-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 Click to see a flowchart view of the current approval request.
Diagram See Sequence diagram on page 274.
View As: Table Click to see a tabular view of the current approval request.
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.

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
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-Detail-
HandleEvent.
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

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

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 drop-
down 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.

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

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
E 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 Processor Processor Available Operating Database
name architecture type RAM system
AR System SvrA SPARC Dual 4 GB Solaris 10 -
AR System SvrB SPARC Dual 4 GB Solaris 10 -
Database DataSvrC SPARC Quad 16 GB Solaris 10 Oracle 10g
Instance name:
svrgrpdb
Appendix E Installing the approval server in a server group 281

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.

Appendix
F Troubleshooting
This section contains troubleshooting information for BMC Remedy Approval

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

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

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.

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
Alternate- Specifies whether applications such as the approval The AR System server
Approval-Reg server listen for the AR System servers signal installation creates this entry and
directly (F) or listen for the application dispatcher to sets the value to T. To change the
signal (T). setting, use a text editor to edit
The default value of this setting is T, which makes the ar.cfg or ar.conf file.
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 AP:Admin-ServerSettings
Interval server checks for changed or updated data in the
data definition forms.
Approval-Log- Full path of the approval server log file. AP:Admin-ServerSettings
File
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-RPC- A specific RPC program number (RPC socket) AP:Admin-ServerSettings
Socket dedicated to the approval server for calls to the
AR System server. This setting defines a private
queue for the approval server.
Plugin-Loopback- An RPC program number (RPC socket) dedicated to AP:Admin-ServerSettings or
RPC-Socket loopback calls from the Plug-in server. The Server Information dialog box.
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.

System error messages
Table F-1: BMC Remedy Approval Server configuration file settings (Sheet 2 of 2)
Configuration setting Description How to set it
Approval-Polling- This setting causes the approval server to poll the Edit the ar.cfg or ar.conf file
Interval 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

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.

Glossary
action date approval

The duration within which an approver must An electronic signature by an authorized
take action on a pending request. This value is person. In the approval server, an approval is
derived from various process intervals indicated by the status Approved on a
defined on AP:Process Definition. request that has followed an automated
Ad Hoc process process to gather the required signatures.
An approval process type with no predictable approval application
routing, in which the requester and approvers An interrelated set of forms, workflow,
select the subsequent approver. See also processes and rules that allow users to enter a
Parent-Child, Level, and Rule-Based process request and approvers to respond, route the
types. request to completion, and generate
Ad hoc override notifications related to the request.
In Parent-Child, Level, and Rule-Based Approval Audit Trail
processes, ad hoc overrides approvers to alter A field in the detail form that tracks all status
the predetermined routing. The Allow Ad changes to the approval request, including the
Hoc Next Approver? field controls whether date, time, and approver name.
the process allows this. approval process
alternate approve A procedure that generates all necessary
An indication for notifications when an signatures to authorize an approval request in
alternate has responded with an approval. an AR System application.
alternate approver Approval Process Done
An AR System user with the authority to A rule type used to update the request when
substitute for an approver within an approval the approval process is done. These rules are
process. used to indicate the result of the approval
alternate reject process to the original request.
An indication for notifications when an approval request
alternate has responded by rejecting a request. A request entered in an approval application
Application Dispatcher to request authorization for a change, an
An AR System server process (Windows) or expenditure, or any other business situation
daemon (UNIX) installed with the AR System that requires signatures.
server that monitors the Application Pending approval request form
form, and signals other server applications, An AR System form used by requesters to
such as the approval server, when they have enter a request for approval.
work to do.
Glossary 289
BMC Remedy Approval Server close reject

An AR System application server that runs as An indication for notification when a request
a plug-in. It routes an applications approval has multiple possible approvers and another
request form to generate signatures. The of the approvers rejects the request.
approval server also creates an audit trail for Completion rule
all approval activity. A rule type that checks whether conditions
approved exist to stop routing a request. If a completion
The status of a signature when the approver check is successful, no new approvers will see
has authorized the request. Also, the status of the request. The request might not be done,
a completed approval request when all but the request has been routed to everyone
approvers have authorized the request. who must respond.
approver detail record
An AR System user with the authority to The approval server creates an entry in the
approve or reject approval requests. AP:Detail form when a new approval request
approver list is submitted. This form tracks the details of
The list of approvers eligible to respond on the the approval process for the request. It is part
signature lines for an approval process. of the two-way and three-way join forms that
are central to approval processing.
Auto Approval
A rule type that allows for automatic approval done
by the approval server of a request that meets An approval request is done when all the
specified criteria. required approvers have responded to the
request, or the request is cancelled, or the
cancel at later level approval server has put the request into an
An indication for notifications when an error state.
approval process is cancelled after it has been
approved by a previous approver. error
The status of an incomplete approval request
cancelled in which routing problems have occurred.
The status of a completed approval request
that was withdrawn by the requester or escalation
cancelled by an approver or process A workflow component that searches at
administrator. specified times or at regular intervals for
requests matching a specified condition and
chained approval process performs specified operations on all matching
A sequence of approval processes that appear requests. For approval requests, escalations
to the user as one approval, but in fact are are set relative to approval process actions
made up of two or more separate approval and states.
processes.
Get Authority
close approve A rule type that gathers information about the
An indication for notifications when a request current approver or environment that is used
has multiple possible but not required by subsequent Self Approval or Completion
approvers and another of the approvers rules.
approves the request.
closed A rule type that gathers information about the
The status of an approval request that has current approver or environment that is used
been resolved and is no longer waiting for an by subsequent completion rule tests.
approver or More Information response.

Glossary
Get Authority Self notification

A rule type that gathers information about the A message to a user from workflow. This can
current approver or environment that is used be an alert, email, or other message using
by subsequent Self Approval rule tests. integrations. Notifications are linked to the
Get Next Approver approval request status and process states.
A rule type that finds the next approvers in override approve
the current process, including the first An indication for notifications when a process
approver at the start of processing. Also, a administrator has approved a request in a
stage of the approval process. manner that circumvents the normal process.
hold override reject
An indication for notifications when a request An indication for notifications when a process
is changed to the Hold status. This is also a administrator has rejected a request in a
status in which an approval request is manner that circumvents the normal process.
assigned to an approver but the approver has Parameterized Get Next Approver
held the request. In this case, no approval A rule type that uses run-time variables to
server activity occurs until the hold is find approvers in the current process. It lets
removed. requesters and approvers add additional
join form approvers to any level in an approval process
A type of form that contains information from (not just the next level).
two or more AR System forms. Join forms Parent-Child
point to the data stored on the AR System An approval process type with a fixed
forms that were used to create the join form. relationship between approvers, such as a
The approval server uses the two-way join management hierarchy. See also Level, Ad Hoc
form AP:Detail-Signature, and a three-way process, and Rule-Based.
join form, which is a join between the
applications approval request form and pending
AP:Detail Signature. The status of an incomplete approval request
awaiting response or more information from
Level an approver. Also, the status of a signature
An approval process type with relationships line that is waiting for a response from the
based on the approvers membership in approver.
organizational groups (not AR System
groups). See also Parent-Child, Ad Hoc process, plug-in
and Rule-Based. An auxiliary program that works with the
AR System server. A plug-in is a dynamically
More Information request linked library (DLL) on Microsoft platforms
An approvers query for additional data that and a shared object on UNIX platforms. The
becomes part of the audit trail of the approval AR System plug-in service loads the plug-in at
request. The approver is not required to delay start time. The approval server is a plug-in.
the approval request until someone responds.
more info return A rule type that gathers information to be
An indication for notifications when a More used by the Get Next Approver rules.
Information request has been responded to.
process administrator
new signature An AR System user who is a member of the
An indication for notifications that a new Approval Admin group (402). Process
signature record has been created for an administrators can have authority to set up
approval request. and maintain approval processes, or to act as
an override approver only.
Glossary 291
qualification signature
A condition statement using search criteria An entry in the AP:Signature form that
that can include field references, values, and represents the response of an approver to an
arithmetical and relational operators. In approval request.
approval server processes, rules, and Signature Accumulator
workflow objects, condition statements are A rule type that is used to collect statistical
used to determine whether the process, rule, information about the signature records
or filter should run, and to control data associated with an approval process.
gathering.
signature authority
reassign The ability of an approver to authorize a
An action for an approver to reroute a request request, based on policies established by the
by changing the assigned approvers. organization and defined in a signature
reject by another approver authority form.
An indication for notifications when multiple signature authority form
required approvals are outstanding and one A form created by the administrator that
of the other approvers rejects the request. contains approver names or roles and their
reject by later level signature authority limits, to support data
An indication for notifications when an gathering by get authority rules.
approval process is rejected by an approver signature record
after it has been approved by a previous A database record in the AP:Signature form
approver. that represents the signature of an approver. If
rejected an approval request requires more than one
The status of a completed approval request signature, multiple signature records are
when an approver has rejected the request. generated for that single approval request.
Also the status of the signature line of the Statistical Override
approver who has rejected the request. A rule type that is used to preempt the default
requester behavior of the approval process and follow
A user who submits a form to request an an approve or reject path before all pending
approval, triggering approval server action. signatures have been completed.
role Status field
A named alias for one or more approvers. The core field (ID 7) in which AR System
Using roles allows the definition of a position tracks the status of a request. In the approval
regardless of the individual approvers who server, the AP:Detail form uses this field to
are currently fulfilling that position. track the overall status of the request. In the
Rule-Based AP:Signature form, the field is renamed to
A custom approval process type designed by Approval Status, and it tracks the approval
the process administrator, in which status of the individual signature line.
relationships are defined by rules rather than Validate Approver
by data in a form. See also Parent-Child, Level, A rule type that is used to verify that a name
and Ad Hoc process. specified as the next approver is a valid user.
Self Approval Only used to verify a user specified in an Ad
A rule type that allows for automatic approval Hoc process or an ad hoc override of another
of a request if the submitter of the request has process type.
sufficient authority for the request to be
approved.

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 associating with an application 231

chaining 147, 158
ad hoc completion 236
approvers for a request 208, 263 Completion Check stage 74
getting next approver in process 78 creating 98, 157, 196
overrides 43 deleting 104
processes 78 filters and 148, 157
Allow Ad Hoc Next Approver 43 Level processes 77
alternate approvers modifying 103
about 21, 50 Next Approver stage 74
acting as 52 Parent-Child processes 75
defining for others 54 Process Done stage 74
designating 50 process status field and 148
modifying 52 renaming 104
Application Dispatcher 72 restarting 149
Application Pending form 72 routing 74
Application-Command processes Rule-Based processes 79
See also Approval Server commands rules and 72, 157
about 179 Self Check stage 74
Application Pending form and 180 stages of 73
run process action 180 types 75
syntax 180 workflow and 157
approval applications worksheets 196
connecting to the Approval Server 152 approval request form 71
designing 152 approval requests
Approval Central Approval Status field 41
about 36 approving and rejecting 41, 60
fields 255 checking 66
form 255 complete versus done 74
opening from home page 37 creating 59
opening in a browser 37 detail view 41
opening in BMC Remedy User 37 pending 38
using 60 processing 38
approval events 31 reassigning 45, 61
Approval Process Done rules retrieving 38
creating 139 routing 74, 76, 77, 78, 85
examples 93, 140 search criteria 38
worksheet 205 viewing 41
approval processes approval rule types, diagram 82
about 19, 72, 75 approval rules
Ad Hoc processes 78 all get authority 116
Approver Response stage 74 Approval Process Done rules 93
Index 293
associating with a process 112 Sig-Reassign 192

Auto Approval rules 83 Sig-Rejected 192
Completion rules 92 Update-Config 193
creating 110, 200 Approval Status options 87
defining actions 113 approver list
deleting 141 about 20
Get Authority Regular rules 91 Get Next Approver rules and 124
Get Authority rules 84 approver name length 95
Get Authority Self rules 84 Approver Response stage
Get Next Approver rules 85 about 74
modifying 141 rules in 87
order 112 approvers
Parameterized Get Next Approver rules 86 about 20
Prep Get Next Approver rules 85 adding 43
processes and 82 cannot respond 285
qualifying conditions 112 field menu of approver names 168
querying 113 manual specification of 43
running server processes 113 multiple 106
Self Approval rules 84 next approver 43
setting values 113 AR System configuration files 286
Signature Accumulator rules 88 AR System object list 37
SQL commands in 113 ar.cfg 286
Statistical Override rules 88 ar.conf 286
Validate Approver rules 86 arjoinfix
worksheets 200 connecting applications to the Approval
Approval Server Server 156
basic concepts 19 portnum parameter 156
configuring 24, 286 updating three-way join forms 176
connecting an application 152 Assignee Group Permissions field
error messages 287 multi-tenancy and 238
flowcharts and 33 rule configuration 112
forms 207 Auto Approval rules
server settings 27 about 82
upgrading 174 creating 114
Approval Server commands examples 83, 115
Add-PGNA-Values 168, 182 Self Check stage and 74
Add-Sig 183
Det-Approved 184
Det-Cancelled 184 B
Det-Error 185 BMC Software, contacting 2
Det-Rejected 185 business time, configuring 32
Generate-Multi-Process-Preview 186
Generate-Preview 186
MoreInfo-Return 187 C
New-Details 187
chaining approval processes 147, 158
Rename-Form 188
Completion Check stage
Rename-Process 188
about 74
Sig-Approved 189
rules in 91
Sig-Cancelled 189
Completion rules
Sig-Notify 190
about 92
Sig-Notify-Change 190
configuring processes and 236
Sig-Notify-State 191
creating 138

determining success 92 updating for release 7.x.xx functionality 176

examples 91, 92, 138 two-way joins
worksheet 204 about 153
configuring creating 154
Approval Server 24 forms, Approval Server
flowcharts 33 AP:Admin-DeleteVerify, fields in 210
process administrator 26 AP:Administration
customer support 3 creating processes 98
creating rules 110
fields in 209
D Form tab 157
debug log 27 using 24
definition check interval 30 AP:Admin-Rename
documentation, AR System 13 fields in 210
using 104
AP:Admin-ServerSettings
E escalations 32
fields in 212
error messages 287
notifications 31
escalations, configuring 32
using 27
AP:Alternate, fields in 266
F AP:Detail
about 70
field permissions, troubleshooting 284 fields in 216
filters, approval processes and 148 AP:Detail-Signature
flowcharts, Approval Server and 33 about 71
forms fields in 217
See also forms, application; forms, Approval AP:Dtl-Sig-MoreInfoDialog, fields in 268
Server; forms, Get Agreement; forms, Lunch AP:Form, fields in 220
Scheduler AP:More Information
administration forms 208 about 72
renaming 104 fields in 269
user forms 255 permissions 64
workflow and 166 using 62
forms, application AP:Notification
approval request Basic 159
about 71 Details 162
arjoinfix and 156 Email 163
connecting to the Approval Server 152 fields in 223
creating 153 AP:Password, fields in 270
linking a process to 231 AP:Pending Approvals 255
linking to the Approval Server 157 AP:PreviewInfo
permissions 153 approver name length and 95
signature authority 72 configuring previews 33
supporting forms fields in 227
about 70 retrieving data from 168
examples 146 AP:PreviewSignatures 95
three-way joins AP:Process Administrator, fields in 229
about 71, 153 AP:Process Definition
arjoinfix and 177 creating a process 98
creating 154 defining More Information escalations 103
request details 41 defining signature escalations 101
Index 295
fields in 231 Rule-Based processes 123

AP:Reserved Word, fields in 245 worksheet 202
AP:Role
defining roles 106
fields in 246 I
AP:Rule Definition If Multiple Approvers
Basic 111 field values for 106
fields in 247 installation, troubleshooting and 283
Set Fields 113
AP:Signature
about 71 L
fields in 252
Level processes
Application Pending, about 72
about 77
Approval Central
examples 145
Approval Central and 36
getting next approver 77
fields in 255
requirements 77
licensing sample users 150
G log files
about 27
Get Agreement configuring 30
about 58 using 284
activating rules 136 loopback calls
AP-Sample2:Get Agreement form 59 avoiding deadlocks 285
AP-Sample2:Issue Detail Signat form 62 private queues and 28
sample users 58 Lunch Scheduler
statistical decision-making rules in 133 about 144
three-way join form 62 AP-Sample:Company form 146
Get Authority Regular rules AP-Sample:Lunch Scheduler form 145
Completion stage and 91 AP-Sample:Lunch-Detail form 145
creating 116 AP-Sample:Lunch-Detail-Signatu form 145
worksheet 203 AP-Sample:Restaurant form 146
Get Authority rules AP-Sample:Signature Authority form 72, 146
about 82 defining signature limits 134
creating 116 forms in 145
examples 117 Level process example 147
using with Self Approval rules 84 licensing users 150
versus Get Authority Self rules 84 Parent-Child process example 146
worksheet 200 process functionality 148
Get Authority Self rules processes in 145, 146
about 82 Rule-Based process example 147
creating 116 users 150
using with Self Approval rules 84
versus Get Authority rules 84
worksheet 201 M
More Information escalations, creating 103, 196
about 85
More Information requests
approver list and 124
about 45
creating 121, 123
Approval Status and 63
examples 85, 125
creating 46, 62
Level processes 122
responding 47, 63
multiple rules 124
viewing 47
Parent-Child processes 122

viewing responses 48, 65 examples 85, 120

viewing your submitted 48 Get Next Approver rules and 85
multi-tenancy worksheet 202
Assignee Group Permissions field 112 previews
supporting 238 Add-PGNA-Values command and 168
AP:Preview Data form 226
configuring 33, 168, 234
N flowchart view 274
Next Approver stage multi-process preview 170, 226
about 74 options 234
ad hoc next approvers 86 Parameterized Get Next Approver rules and 168
rules in 85 tabular view 275
notifications Private AR Server RPC Socket, configuring 28, 30
configuring 31 private queues
creating 158 See also Plugin Loopback RPC Socket; Private
Notify On options 160 AR Server RPC Socket
workflow-based 165 about 285
Notify On options 160 process administrators
about 21
capabilities 25
O configuring 26
creating 26
overrides
defining alternate approvers 54
global 55
performing overrides 54
performing 54
prerequisites 26
single signature 55
responsibilities 25
Process Done stage
P about 74
rules in 93
Parameterized Get Next Approver rules process status field 148
about 85 processes, about approval 19
creating 126 product support 3
examples 128
previews and 86, 168
versus Get Next Approver rules 86 R
worksheet 203
requesters 20
Parent-Child processes
requests
about 75
AP:Show-Detail form 271
examples 145
reassigning 45
viewing details 271
requirements 76
roles
passwords
about 20, 106
requiring for approval 237
defining 106
show field dynamically 167
RPC sockets 30
Plugin Loopback RPC Socket, configuring 28, 30
Rule-Based processes
Plug-in server
about 79
configuring 30
examples 145
loopback calls 285
portmapper, arjoinfix and 156
requirements 79
about 85
creating 120
Index 297
S T
sample applications technical support 3
Get Agreement 58 three-way join forms
Lunch Scheduler 144 See also forms, application
sample forms example 145
Get Agreement 59 troubleshooting
Lunch Scheduler 145 configuration file settings 286
sample users, approval authority 150 deadlocked Approval Server 285
security, requiring passwords to approve 237 error messages 287
Self Approval rules field permission errors 284
about 82 installation 283
creating 118 two-way join forms
examples 84, 119 See also forms, application
get authority rules and 83 example 145
Self Check stage and 74
worksheet 201
Self Check stage U
about 74 upgrading the Approval Server 174
rules in 82 users, licensing sample 150
about 88
creating 131 V
default statistical data and 131
examples 89, 132
about 85
Get Agreement functionality 133, 135
creating 129
Level processes and 89
examples 86, 130
signature lines and 89
worksheet 201
worksheet 204
signature authority
form 72
Lunch Scheduler sample application and 150
W
signatures Web access 178
creating escalations 101, 197 workflow
creating lines 85 enhancing Approval Server forms 166
limits 134 notifications and 165
specifying additional approvers 43 worksheets
statistical decision-making rules More Information escalations 196
See also Signature Accumulator rules; Statistical processes 196
Override rules rules 200
about 88 signature escalations 197
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

*183967*
*183967*
*183967*
*183967*
*183967*

ApprovalServer 7604 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ApprovalServer 7604 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

BMC Remedy Action Request System 7.6.

BMC Remedy Approval

Copyright 19912011 BMC Software, Inc.

Restricted rights legend

Support by telephone or email

Before contacting BMC Software

Chapter 1 Introduction to the approval server 17

Chapter 2 Configuring the approval server 23

Chapter 3 Processing approval requests 35

Chapter 4 Using the Get Agreement sample application 57

Chapter 5 Introduction to approval forms, processes, and rules 69

6 BMC Remedy Approval Server Guide

Chapter 6 Defining an approval process 97

Chapter 7 Defining approval rules 109

Chapter 8 Using the Lunch Scheduler sample application 143

Chapter 9 Adding approvals to your application 151

Appendix A Upgrading the approval server 173

Appendix B Application commands 179

8 BMC Remedy Approval Server Guide

Appendix C Worksheets 195

Appendix D Approval forms 207

Appendix E Installing the approval server in a server group 281

Appendix F Troubleshooting 283

10 BMC Remedy Approval Server Guide

Title Description Audience

14 BMC Remedy Approval Server Guide

Title Description Audience

16 BMC Remedy Approval Server Guide

1 Introduction to the approval

Chapter 1 Introduction to the approval server 17

Approvals in business processes

Overview of the approval server

18 BMC Remedy Approval Server Guide

Flexibility and common experience

Notification with feedback

Basic approval server concepts

Chapter 1 Introduction to the approval server 19

20 BMC Remedy Approval Server Guide

Chapter 1 Introduction to the approval server 21

22 BMC Remedy Approval Server Guide

2 Configuring the approval

Chapter 2 Configuring the approval server 23

Using the approval server Administration form

Figure 2-1: AP:Administration form

To open the AP:Administration form

24 BMC Remedy Approval Server Guide

Chapter 2 Configuring the approval server 25

Configuring process administrator capabilities

Process administrator prerequisites

Creating a process administrator

To create a process administrator

Figure 2-2: Creating a process administrator

26 BMC Remedy Approval Server Guide

Configuring server settings

Approval server debug log

Chapter 2 Configuring the approval server 27

<APPR> Tag -- Approval-Defn-Check-Interval:

Private queues for loopback calls

Private AR Server RPC Socket

Plugin Loopback RPC Socket

28 BMC Remedy Approval Server Guide

How the approval server uses RPC settings

Chapter 2 Configuring the approval server 29