BMC Remedy Approval Server 70 Guide For Users and Administrators

BMC Remedy Approval Server 7.
Guide for Users and Administrators
May 2006 Part No: 59459
Copyright 1991-2006 BMC Software, Inc. All rights reserved. BMC, the BMC logo, all other BMC product or service names, BMC Software, the BMC Software logos, and all other BMC Software product or service names, are registered trademarks or trademarks of BMC Software, Inc. All other trademarks belong to their respective companies. BMC Software, Inc., considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable end user license agreement or nondisclosure agreement for the product and the proprietary and restricted rights notices included in this documentation. For license information about the OpenSource files used in the licensed program, please read OpenSourceLicenses.pdf. This file is in the \Doc folder of the distribution CD-ROM and in the documentation download portion of the product download page. 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.
Contacting Us If you need technical support for this product, contact Customer Support by email at support@remedy.com. If you have comments or suggestions about this documentation, contact Information Development by email at doc_feedback@bmc.com. This edition applies to version 7.0 of the licensed program.
BMC Software, Inc.

www.bmc.com
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Whats new in 7.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Related BMC Remedy documents . . . . . . . . . . . . . . . . . . . . 16 Learn more about the AR System Developer Community. . . . . . . . . . 17 Why should you participate in the Developer Community? . . . . . . . . 17 How do you access the Developer Community? . . . . . . . . . . . . . 17
Chapter 1
Installation and configuration
. . . . . . . . . . . . . . . . . . 19
Installation notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 AR System server installation notes . . . . . . . . . . . . . . . . . . 20 Approval Web installation notes . . . . . . . . . . . . . . . . . . . 20 Licensing the Approval Server . . . . . . . . . . . . . . . . . . . . . 20 Installing the Approval Server on Windows. . . . . . . . . . . . . . . . 21 Installing the Approval Server on UNIX . . . . . . . . . . . . . . . . . 23 Using the Approval Server on the web . . . . . . . . . . . . . . . . . . 25 Manually starting and stopping the Approval Server . . . . . . . . . . . . 27 WindowsStarting the server . . . . . . . . . . . . . . . . . . . . 27 WindowsStopping the server . . . . . . . . . . . . . . . . . . . . 27 UNIXStarting and stopping the server manually . . . . . . . . . . . . 28 Using an AR System server without portmapper. . . . . . . . . . . . . . 30 Configuring the AR System server without portmapper . . . . . . . . . . 30 Configuring the Approval Server without portmapper . . . . . . . . . . 31
Contents
BMC Remedy Approval Server
Uninstalling the Approval Server . . . . . . . . . . . . . . . . . . . . 31 Removing a Windows installation . . . . . . . . . . . . . . . . . . . 31 Removing a UNIX installation . . . . . . . . . . . . . . . . . . . . 31 Where to go next . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 2
Understanding the approval process . . . . . . . . . . . . . . . 33

The basic approval. . . . . . . . . . . . . . . . . . . . . . . . . . . 34 The approval process . . . . . . . . . . . . . . . . . . . . . . . . . 34 The BMC Remedy Approval Server . . . . . . . . . . . . . . . . . . . 35 Common experience across applications . . . . . . . . . . . . . . . . 36 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Notification plus feedback . . . . . . . . . . . . . . . . . . . . . . 37
Chapter 3
The BMC Remedy model for approvals . . . . . . . . . . . . . . 39

Key concepts of the Approval Server . . . . . . . . . . . . . . . . . . . 40 The approval process . . . . . . . . . . . . . . . . . . . . . . . . 40 Who participates in the approval process . . . . . . . . . . . . . . . . 40 Acknowledging approvals . . . . . . . . . . . . . . . . . . . . . . 44 Where to go next . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter 4
Working as an approver
. . . . . . . . . . . . . . . . . . . . . 45
Processing an approval request . . . . . . . . . . . . . . . . . . . . . 46 Viewing approval requests . . . . . . . . . . . . . . . . . . . . . . . 46 Performing other approval actions . . . . . . . . . . . . . . . . . . . 47 Requesting more information. . . . . . . . . . . . . . . . . . . . . 48 Reassigning an approval request. . . . . . . . . . . . . . . . . . . . 48 Specifying the next approver . . . . . . . . . . . . . . . . . . . . . 48 Handling approval errors. . . . . . . . . . . . . . . . . . . . . . . . 49 Designating alternate approvers . . . . . . . . . . . . . . . . . . . . . 49 Designating alternate approvers for yourself. . . . . . . . . . . . . . . 49 Serving as an alternate approver. . . . . . . . . . . . . . . . . . . . 50 Managing alternate approver definitions . . . . . . . . . . . . . . . . 51 Performing overrides . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Contents
Chapter 5
Processing approval requests with Approval Central . . . . . . . 53

Logging in to Approval Central with a browser . . . . . . . . . . . . . . 54 Logging in to Approval Central with BMC Remedy User . . . . . . . . . . 56 Defining approval details . . . . . . . . . . . . . . . . . . . . . . . . 58 Approving approval requests . . . . . . . . . . . . . . . . . . . . . 59 Specifying next approvers . . . . . . . . . . . . . . . . . . . . . . 60 Specifying multiple approvers. . . . . . . . . . . . . . . . . . . . . 61 Reassigning approval requests . . . . . . . . . . . . . . . . . . . . 61 Processing More Information Requests . . . . . . . . . . . . . . . . . 62 Requesting more information about approval requests . . . . . . . . . . 62 Viewing and responding to the More Information Requests to you . . . . . 63 Viewing More Information Requests you have submitted . . . . . . . . . 65 Using alternate approvers . . . . . . . . . . . . . . . . . . . . . . . 65 Designating alternate approvers . . . . . . . . . . . . . . . . . . . 66 Acting as an alternate approver . . . . . . . . . . . . . . . . . . . . 68 Managing alternate approver definitions . . . . . . . . . . . . . . . . 68 Additional options for process administrators . . . . . . . . . . . . . . 70 Defining alternates for other approvers. . . . . . . . . . . . . . . . . 70 Performing overrides . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 6
Using a sample application . . . . . . . . . . . . . . . . . . . . 73

Using the Get Agreement sample application . . . . . . . . . . . . . . . 74 Making a new approval request . . . . . . . . . . . . . . . . . . . . 74 Approving a request . . . . . . . . . . . . . . . . . . . . . . . . . 75 Requesting more information. . . . . . . . . . . . . . . . . . . . . 77 Responding to a more information request . . . . . . . . . . . . . . . 78 Reassigning an approval request. . . . . . . . . . . . . . . . . . . . 79 Displaying answers to More Information Requests . . . . . . . . . . . . 80 Finishing the sample request . . . . . . . . . . . . . . . . . . . . . 81 Summary of sample . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Chapter 7
Preparing process administrators . . . . . . . . . . . . . . . . . 83

The role of the process administrator . . . . . . . . . . . . . . . . . . 84 Process administrator responsibilities . . . . . . . . . . . . . . . . . 84 Sharing process administration authority . . . . . . . . . . . . . . . . 84 Delegating process administration capability . . . . . . . . . . . . . . 85
Contents
Key features of the Approval Server . . . . . . . . . . . . . . . . . . . 85 Approval data . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Approval process . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Common rules and operations . . . . . . . . . . . . . . . . . . . . . 88 Self Check rulesPreventing unnecessary routing . . . . . . . . . . . . 90 Approver roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Next approver rulesDetermining who is next . . . . . . . . . . . . . 93 Approver responseSignature line . . . . . . . . . . . . . . . . . . 96 Statistical Decision-Making rulesDo you want to base your decision upon statistical data? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Routing completion checkWho is left? . . . . . . . . . . . . . . . 102 Process done rules . . . . . . . . . . . . . . . . . . . . . . . . 105 Summary of common process elements . . . . . . . . . . . . . . . 106 Approval process types . . . . . . . . . . . . . . . . . . . . . . . . . 107 Summary of process types . . . . . . . . . . . . . . . . . . . . . 114 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Chapter 8
Working with the Approval Server . . . . . . . . . . . . . . . 117

Using the Approval Server Administration form . . . . . . . . . . . . . 118 Using the Administration form . . . . . . . . . . . . . . . . . . . 120 Renaming a process or form . . . . . . . . . . . . . . . . . . . . 121 Configuring the server settings . . . . . . . . . . . . . . . . . . . 122 Setting up administrator capabilities. . . . . . . . . . . . . . . . . . . 125 Using approval notifications . . . . . . . . . . . . . . . . . . . . . . 127 Defining the events to trigger notifications . . . . . . . . . . . . . . 127 Defining an approval notification . . . . . . . . . . . . . . . . . . 129 Configuring business times . . . . . . . . . . . . . . . . . . . . . . . 136 Where to go next . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 9
Defining an approval process . . . . . . . . . . . . . . . . . . 139

Using the Process Definition form . . . . . . . . . . . . . . . . . . . . 140 Creating a process . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Entering more information escalations . . . . . . . . . . . . . . . 148 Working with existing processes. . . . . . . . . . . . . . . . . . . . . 149 Modifying processes. . . . . . . . . . . . . . . . . . . . . . . . 149 Deleting processes . . . . . . . . . . . . . . . . . . . . . . . . 150 Renaming processes . . . . . . . . . . . . . . . . . . . . . . . . 151
6 Contents
Chapter 10
Defining approval rules . . . . . . . . . . . . . . . . . . . . . 153

Using the Rule Definition form . . . . . . . . . . . . . . . . . . . . . 154 Creating a rule . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Using the Basic tab on the Rule Definition form . . . . . . . . . . . . 156 Using the Set Fields tab on the rule definition form . . . . . . . . . . 157 Example of the Set Fields tab . . . . . . . . . . . . . . . . . . . . 159 Working with Auto-Approval rules . . . . . . . . . . . . . . . . . . . 159 Defining Auto-Approval rules . . . . . . . . . . . . . . . . . . . 160 Auto-Approval rule example . . . . . . . . . . . . . . . . . . . . 161 Working with Self-Approval rules . . . . . . . . . . . . . . . . . . . . 162 Defining Self-Approval rules . . . . . . . . . . . . . . . . . . . . 162 Self-Approval rule example . . . . . . . . . . . . . . . . . . . . . 164 Working with Prep Get Next Approver rules . . . . . . . . . . . . . . . 165 Defining Prep Get Next Approve rules . . . . . . . . . . . . . . . . 165 Example of a Prep Get Next Approve rule . . . . . . . . . . . . . . 167 Working with Get Next Approver rules . . . . . . . . . . . . . . . . . 168 Working with a Parent-Child process . . . . . . . . . . . . . . . . 168 Working with a Level process . . . . . . . . . . . . . . . . . . . . 169 Working with an Ad Hoc process . . . . . . . . . . . . . . . . . . 169 Working with a Rule-Based process . . . . . . . . . . . . . . . . . 170 Defining Get Next Approver rules . . . . . . . . . . . . . . . . . . 170 Example of Get Next Approver rule . . . . . . . . . . . . . . . . . 172 Working with Parameterized Get Next Approver rules . . . . . . . . . . . 174 Defining Parameterized Get Next Approver rules . . . . . . . . . . . 174 Example of Parameterized Get Next Approver rule . . . . . . . . . . . 177 Working with Validate Approver rules . . . . . . . . . . . . . . . . . . 179 Defining validate approver rules. . . . . . . . . . . . . . . . . . . 179 Example of a validate approver rule . . . . . . . . . . . . . . . . . 180 Working with Get Authority rules . . . . . . . . . . . . . . . . . . . . 181 Defining Get Authority rules . . . . . . . . . . . . . . . . . . . . 181 Example of a Get Authority rule. . . . . . . . . . . . . . . . . . . 182 Working with Get Authority Regular rules . . . . . . . . . . . . . . . . 183 Defining Get Authority Regular rules . . . . . . . . . . . . . . . . 183 Example of a Get Authority Regular rule . . . . . . . . . . . . . . . 184
Contents
Working with Get Authority Self rules . . . . . . . . . . . . . . . . . . 185 Defining get authority self rules . . . . . . . . . . . . . . . . . . . 185 Example of a Get Authority Self rule . . . . . . . . . . . . . . . . . 187 Working with Completion rules . . . . . . . . . . . . . . . . . . . . . 187 Defining Completion rules . . . . . . . . . . . . . . . . . . . . . 188 Example of a completion rule . . . . . . . . . . . . . . . . . . . . 188 Working with Signature Accumulator rules. . . . . . . . . . . . . . . . 189 Defining Signature Accumulator rules . . . . . . . . . . . . . . . . 190 Example of a Signature Accumulator rule. . . . . . . . . . . . . . . 191 Working with Statistical Override rules . . . . . . . . . . . . . . . . . 193 Defining Statistical Override rules . . . . . . . . . . . . . . . . . . 193 Example of a Statistical Override rule . . . . . . . . . . . . . . . . 195 Statistical Decision-Making approvals in a sample application . . . . . . . 196 Statistical decision making rules in the Get Agreement sample . . . . . . 199 Working with Approval Process Done rules . . . . . . . . . . . . . . . 201 Defining Approval Process Done rules . . . . . . . . . . . . . . . . 201 Example of an Approval Process Done rule . . . . . . . . . . . . . . 202 Working with existing rules. . . . . . . . . . . . . . . . . . . . . . . 203 Viewing rule stages . . . . . . . . . . . . . . . . . . . . . . . . 203 Modifying rules. . . . . . . . . . . . . . . . . . . . . . . . . . 205 Deleting rules . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Chapter 11
Managing users and roles . . . . . . . . . . . . . . . . . . . . 207

Defining roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Defining alternate approvers . . . . . . . . . . . . . . . . . . . . . . 209 Assigning process override capability . . . . . . . . . . . . . . . . . . 211
Chapter 12
Implementing sample application features . . . . . . . . . . . 213

Overview of the Lunch Scheduler application . . . . . . . . . . . . . . . 214 Key forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Sample process descriptions . . . . . . . . . . . . . . . . . . . . . . 216 Management cost authorization. . . . . . . . . . . . . . . . . . . 217 Major account level approval . . . . . . . . . . . . . . . . . . . . 217 Special overdue approval. . . . . . . . . . . . . . . . . . . . . . 217 Previewing approvers . . . . . . . . . . . . . . . . . . . . . . . 218
8 Contents
Chaining approval processes . . . . . . . . . . . . . . . . . . . . . . 221 Using a status field in chained processes . . . . . . . . . . . . . . . 221 Flow between chained processes. . . . . . . . . . . . . . . . . . . 221 Restarting an approval process . . . . . . . . . . . . . . . . . . . . . 222 Special techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 More information. . . . . . . . . . . . . . . . . . . . . . . . . 223 Show summary and signatures . . . . . . . . . . . . . . . . . . . 224 Show password field if required . . . . . . . . . . . . . . . . . . . 225 Recommended technique: menu of valid names . . . . . . . . . . . . 225 Sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Sample user approval authority . . . . . . . . . . . . . . . . . . . 227
Chapter 13
Adding approvals to your application . . . . . . . . . . . . . . 229

Connecting an application to the Approval Server . . . . . . . . . . . . . 230 Enabling workflow-based notifications . . . . . . . . . . . . . . . . . 235 Preparing your application to interact with Approval Central . . . . . . . . 237 Adding your form to the Approval Central application . . . . . . . . . 237 Integrating your form with Approval Central workflow . . . . . . . . . 238 Adding optional navigational aids . . . . . . . . . . . . . . . . . . 239
Appendix A
Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Process worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Defining a process . . . . . . . . . . . . . . . . . . . . . . . . 242 More information escalations . . . . . . . . . . . . . . . . . . . . 242 Signature escalations . . . . . . . . . . . . . . . . . . . . . . . 243 Rule worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Auto-Approval rules . . . . . . . . . . . . . . . . . . . . . . . 245 Get Authority Self rules . . . . . . . . . . . . . . . . . . . . . . 246 Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . 246 Self-Approval rules . . . . . . . . . . . . . . . . . . . . . . . . 247 Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . 247 Prep Get Next Approver rules. . . . . . . . . . . . . . . . . . . . 248 Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . 249 Get Authority Regular rules . . . . . . . . . . . . . . . . . . . . 250 Completion rules . . . . . . . . . . . . . . . . . . . . . . . . . 250 Parameterized Get Next Approver rules . . . . . . . . . . . . . . . 251
Contents
Signature Accumulator Done rules . . . . . . . . . . . . . . . . . 252 Statistical Override Done rules . . . . . . . . . . . . . . . . . . . 252 Approval Process Done rules . . . . . . . . . . . . . . . . . . . . 253
Appendix B
Application commands . . . . . . . . . . . . . . . . . . . . . 255

Basic information . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Specific Approval Server commands . . . . . . . . . . . . . . . . . . . 258 Add-Sig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Add-PGNA-Values . . . . . . . . . . . . . . . . . . . . . . . . 259 Det-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Det-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Det-Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Det-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 MoreInfo-Return . . . . . . . . . . . . . . . . . . . . . . . . . 261 New-Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Rename-Form . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Rename-Process . . . . . . . . . . . . . . . . . . . . . . . . . 262 Sig-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Sig-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Sig-Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Sig-Notify-Change . . . . . . . . . . . . . . . . . . . . . . . . 264 Sig-Notify-State . . . . . . . . . . . . . . . . . . . . . . . . . 264 Sig-Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Sig-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Update-Config . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Appendix C
Approval forms . . . . . . . . . . . . . . . . . . . . . . . . . 267

Approval Central application . . . . . . . . . . . . . . . . . . . . . . 268 AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . 269 AP:Alternate . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 AP:Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 AP:Detail-Signature . . . . . . . . . . . . . . . . . . . . . . . . 280 AP:Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 AP:More information . . . . . . . . . . . . . . . . . . . . . . . 285 AP:Notification. . . . . . . . . . . . . . . . . . . . . . . . . . 286 AP:PreviewInfo. . . . . . . . . . . . . . . . . . . . . . . . . . 292
10 Contents
AP:Process administrator . . . . . . . . . . . . . . . . . . . . . 293 AP:Process definition . . . . . . . . . . . . . . . . . . . . . . . 295 AP:Reserved word . . . . . . . . . . . . . . . . . . . . . . . . 301 AP:Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 AP:Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . 303 AP:Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 APW:Access Privileges . . . . . . . . . . . . . . . . . . . . . . . 310 APW:Approval Central . . . . . . . . . . . . . . . . . . . . . . 312 APW:More info requests . . . . . . . . . . . . . . . . . . . . . . 313 Business time holidays . . . . . . . . . . . . . . . . . . . . . . . 315 Business time workdays . . . . . . . . . . . . . . . . . . . . . . 315 User form xxx . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Appendix D
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . 319
Installation concerns. . . . . . . . . . . . . . . . . . . . . . . . . . 320 Previous Approval Server installations . . . . . . . . . . . . . . . . 320 Public group permissions . . . . . . . . . . . . . . . . . . . . . 320 Application pending form . . . . . . . . . . . . . . . . . . . . . 321 Errors not reported . . . . . . . . . . . . . . . . . . . . . . . . 322 Approval Web concerns . . . . . . . . . . . . . . . . . . . . . . . . 322 The Approval Central URL . . . . . . . . . . . . . . . . . . . . . 322 Sample application concerns . . . . . . . . . . . . . . . . . . . . . . 322 Sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Miscellaneous runtime concerns . . . . . . . . . . . . . . . . . . . . 323 Approver receives request but cannot respond. . . . . . . . . . . . . 323 Deadlocked approval server . . . . . . . . . . . . . . . . . . . . 323 Error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Appendix E
Installation directory structures . . . . . . . . . . . . . . . . . 333

Default installation directories . . . . . . . . . . . . . . . . . . . . . 334 Directory structure for Windows installations . . . . . . . . . . . . . . 334 Approval Server 7.0 files for Windows . . . . . . . . . . . . . . . . 334 Directory structure for UNIX installations . . . . . . . . . . . . . . . . 335 Approval server 7.0 files for UNIX . . . . . . . . . . . . . . . . . . 335
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Contents 11
12 Contents
Preface
This chapter provides the following introductory information about the BMC Remedy Approval Server application: Audience (page 14) Whats new in 7.0? (page 15) Related BMC Remedy documents (page 16) Learn more about the AR System Developer Community (page 17)
Important: The compatibility information listed in the product documentation is subject to change. See the compatibility matrix at http://supportweb.remedy.com for the latest, most complete information about what is officially supported.
Carefully read the system requirements for your particular operating system, especially the necessary patch requirements.
Preface
13
Audience
This AR System 7.0 Approval Server guide is written for: Action Request System (AR System) users who want to understand approval workflow. Process Administrators who design and maintain approval processes. AR System Administrators who are responsible for installing and licensing the AR System Approval Server.
Note: The Approval Server Process Administrator is not the same as your AR System Administrator. See Chapter 7, Preparing process administrators, for a discussion of the Process Administrators responsibilities.
This guide assumes you are familiar with the BMC Remedy Action Request System. The administration sections assume you want to add the Approval Server to an existing application. This guide includes instructions for installing Windows and UNIX Approval Server forms and workflow, and assumes you are familiar with the environment in which you install the software.
Note: See Chapter 1, Installation and configuration, for instructions on how to install Approval Server 7.0.
14 Preface
Whats new in 7.0?

The following Approval Server features are new in 7.0: Generating a list of previewersLets you see a preview list of all approvers working on a request in the Preview Signatures form. For information, see Creating a process on page 140 and Previewing approvers on page 218. Parameterized Get Next Approver ruleNew rule that lets you add additional Ad Hoc approvers to any stage in an approval process. For information, see Working with Parameterized Get Next Approver rules on page 174. Workflow-based notificationsIn addition to email and BMC Remedy Alert as notification methods, notifications can be fired when certain workflow is triggered. Applications can now use their custom notification systems for approval events. Workflow-based notification provides an integration for approval events to be propagated to their notification systems. For more information, see Defining an approval notification on page 129 and Enabling workflow-based notifications on page 235. ARDBC Plug-inReplaces approval server Windows service and UNIX daemon. For more information, see the Action Request System 7.0: Integrating with Plug-ins and Third-Party Products guide. Process instance IDUnique GUID that identifies each process. This is especially useful if processes use the same name. All workflow that needs to see this process can now see the GUID and not just the name. You can now change process names as needed, without affecting underlying workflow. For information, see Working with Auto-Approval rules on page 159. New application commandsThe Add-PGNA-Values command provides the variable values for the Parameterized Get Next Approver rule type. For information, see Appendix B, Application commands.
Whats new in 7.0?
15
Multitenancy supportThe 7.0 Approval Server supports multitenancy for use by application service providers. In the same AR System server, you can now include approval processes for applications that are shared by multiple companies. Field 112 with permissions to the Assignee Group only has been added to all 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. To use with application commands, see Add-Sig on page 258 and NewDetails on page 261. For information on access control in the AR System, see the BMC Remedy AR System Form and Application Objects guide.
Related BMC Remedy documents

title and part number Concepts guide Description Overview of AR System architecture and features with in-depth examples; includes information about other AR System products as well as a comprehensive glossary for the entire AR System documentation set. Audience Everyone Format Print and PDF
Form and Application Objects Basic procedures for creating and guide modifying an AR System application for tracking data and processes. Workflow Objects guide Advanced procedures for extending and customizing AR System applications.
Administrators
Print and PDF Print and PDF
Administrators
Unless otherwise noted, online documentation is available in Adobe Acrobat (PDF) format on AR System product installation CDs or on the Customer Support website.
16 Preface
Learn more about the AR System Developer Community

If you are interested in learning more about AR System, looking for an opportunity to collaborate with fellow AR System developers, and searching for additional resources that can benefit your AR System solution, then this online global community sponsored by BMC Remedy is for you. In the Developer Community, you will find collaboration tools, product information, resource links, user group information, and be able to provide BMC Remedy with feedback. The Developer Community offers the following tools and information: Community message board Community Downloads AR System Tips & Tricks Community recommended resources Product information User Experience Design tips Suggestion box
Why should you participate in the Developer Community?

You can benefit from participating in the Developer Community for the following reasons: The community is a direct result of AR System developer feedback. BMC Remedy provides unsupported applications and utilities by way of Community Downloads, an AR System application. BMC Remedy posts the latest AR System product information in the Developer Community to keep you up to date. It is an opportunity to directly impact product direction through online and email surveys. Its free!
How do you access the Developer Community?

Go to www.remedy.com/dev_community.
Learn more about the AR System Developer Community
17
18 Preface
Chapter
The AR System 7.0 Approval Server is available for Windows and UNIX (including Linux). Installation directions for both platforms appear in this chapter. The following topics are provided: Installation notes (page 20) Licensing the Approval Server (page 20) Installing the Approval Server on Windows (page 21) Installing the Approval Server on UNIX (page 23) Using the Approval Server on the web (page 25) Manually starting and stopping the Approval Server (page 27) Using an AR System server without portmapper (page 30) Uninstalling the Approval Server (page 31) Where to go next (page 32)
19
Installation notes
Updates to other AR System products (such as the BMC Remedy Change Management application) that are compatible with the 7.0 Approval Server release are being planned. Further information will be available as these updates become available. For the most current information about compatibility of various AR System products with the 7.0 Approval Server, see the Product Compatibility Matrix found at the following URL:
http://supportweb.remedy.com
AR System server installation notes

You must be an AR System administrator to install this product. You must have AR System server 7.0 or later installed before you proceed with the Approval Server installation. Approval Server 7.0 is supported on only AR System 7.0 or later. You must install the Approval Server on your AR System server machine. If the Application Pending form is not already present on your AR System, you must stop and restart the AR System server before you can start using the Approval Server.
Approval Web installation notes

All Approval Web components are automatically installed with the Approval Server. Before using Approval Web, you must install the AR System mid tier component and you should configure the AR System Object List for use with your browser. For more information, see the Installing and Configuring guides.
Licensing the Approval Server

Starting with the 5.1 release, the BMC Remedy Approval Server no longer requires a purchasable license to operate. The BMC Remedy Approval Server now automatically comes free with each licensed copy of the AR System. As a result, you no longer need to call BMC Remedy Customer Support to obtain a license for each AR System form that you want to attach an approval process to.
20 Chapter 1Installation and configuration
Installing the Approval Server on Windows

Use the following procedure to install the Approval Server on a Windows computer with an existing AR System installation 7.0 or later.
Note: If you are upgrading the Approval Server to 7.0, the installation program automatically migrates all your Approval Server forms, including any new fields that you have added. However, you might have to open these forms in BMC Remedy Administrator and rearrange their appearance.
You do not need to quit all applications before running the installer.
To install the Approval Server on Windows

1 Insert the Action Request System CD-ROM into your CD-ROM drive.
The CD Browser appears. If your computer is not set up to autorun CDROMs, then use Windows Explorer to view the root directory of the CDROM and double-click approval.exe.
2 Click Install Products.
The Install Products window appears.

3 Click BMC Remedy Approval Server.
A splash screen appears and the installer begins. After a short delay a welcome screen appears.
4 Click Next.
The Software License Agreement screen appears.

5 Click the I Agree button to accept the software license agreement.
A dialog box appears asking you for the name of the AR System server where the Approval Server will be installed.
6 Enter the name of your server and, if needed, the number of the TCP port,
and then click Next. The installer starts the specified AR System server, if it is not already started. A dialog box then appears asking you for an AR System Administrator user name and password.
Installing the Approval Server on Windows
21
7 Enter this information into the appropriate fields and click Next.
A dialog box appears asking for additional localized views and data to install.
8 Select the localized views and data you want to install and click Next.
A dialog box appears asking if you want to install the Approval Server sample applications.
9 Click Next.
A dialog box appears asking for the destination path to install the BMC Remedy Approval Server.
10 Click Next to use the default or click Browse to select another directory.
You should use the default to install in the same directory as the AR System server.
11 Click Next to continue.
The installer might prompt you to change the permissions of the Public group from View to Change.
12 Click Yes to continue.
The installer continues installing the Approval Server software and imports workflow and data. When it is finished, the Import Completion dialog box appears.
13 Click OK.
The installer starts the service required for the Approval Server. The Log File Location dialog box appears, and the installation is complete. Log files are generated during the installation of this product. Upon successful completion, these files can be removed.
14 Click OK.
Usually you do not have to restart your machine to use the Approval Server. If a restart is necessary, a dialog box prompts you to do so. You can now log in to the AR System to start using the Approval Server, or continue to the next section to install Approval Web. See the end of this chapter for a road map for first-time process administrators.
Installing the Approval Server on UNIX

Use the following procedure to install the Approval Server on a UNIX computer (including Linux) with an existing AR System installation 7.0 or later. You do not need to quit any applications before running the installer.
To install the Approval Server on UNIX

1 Uncompress and extract the approval_<UNIX_platform>.tar.gz file.
For instructions on using the gunzip and tar utilities to uncompress and extract the contents of the approval_<UNIX_platform>.tar.gz file, see the Installing guide.
2 Change your current directory to the directory where you downloaded the
installation file. From this directory, run the script:

ar_apinstall
3 The installer script asks

On which AR System Server is the AR System Approval Server to be installed?
and provides a default server name based on the host name. Press Enter or type the proper server name and press Enter.
4 The installer script confirms the server name, asking
AR System Approval Server will be installed on <server_name>. Is this correct?
Press Enter if the directory is correct, or type N to return to the previous step.
What is a valid AR System Administrator ID?
and provides a default if able. Press Enter to use the default, or type a valid Administrator ID and press Enter.
6 The installer script confirms the Administrator ID, asking
<ID> is the AR System Administrator ID to use. Is this OK?
Press Enter if the ID is correct, or type N to return to the previous step.

What is the password for the AR System Administrator?
Type the password for this Administrator ID you provided, and press Enter.
Installing the Approval Server on UNIX 23

Please re-enter the password for verification
Type the password for the Administrator ID you provided, and press Enter.
What is the directory to install AR System Approval Server?
and provides a default directory. Press Enter or type the proper directory and press Enter. Without a specific reason, you should use the default values and install in the same directory as your AR System server.
10 The installer script then displays information about disk space requirements,
and verifies how much is available. If there is enough disk space, the installer asks
AR System Approval Server will be installed in the <directory_xxx>. Is this correct?
Press Enter if the directory is correct, or type N to return to the previous step.
Note: If there is not enough disk space available, the installer displays a message asking
Do you want to try to install in <directory _xxx> anyway?
Note: Press Enter or type Y to proceed. Type N to return to the previous step.
11 The installer script displays messages about the forms to install, and asks
Load AR System Approval Server forms into the AR System?
Press Enter to continue, or type N to proceed with the installation of only the Approval Server executable.
Note: If you do not install the Approval Server forms, the Approval Server cannot function. Answer No only if you are restoring the forms in another way.
The installer script displays many messages as it loads definitions of the Approval Server forms into the AR System. Loading might take several minutes to complete, so please be patient.
12 When the installation is successful, the installer script reports

AR System Approval Server installed.
The installer starts the daemon for the Approval Server. The Approval Server is ready to use as soon as the installation is complete. Log files are generated during the installation of this product. Upon successful completion, these files can be removed. You can now log in to the AR System to start using the Approval Server, or continue to the next section to install Approval Web. See the end of this chapter for a road map for first-time process administrators.
Using the Approval Server on the web

The AR System 7.0 mid tier makes it easy for you to administer the Approval Server from a browser. You no longer need to create and deploy the Approval Server forms for use with browsers.
To use the Approval Server on the web

1 After installing the mid tier and Approval Server, open a browser. 2 Do one of the following steps:
To open the Approval Central application in your browser (as shown in Figure 1-1), enter the following URL:
http://<host_name>/arsys/apps/<server_name>/Approval Central
Using the Approval Server on the web
25
BMC Remedy Approval Server Figure 1-1: Approval Central displayed in browser
To view a list of all Approval Server forms in your browser, enter the following URL to open the AR System Object List:
http://<host_name>/arsys/forms
Your Approval Web and Administration components are ready for web users to access.
Note: For more information, see the Configuring and Form and Application Objects guides.
Manually starting and stopping the Approval Server

Since the Approval Server is an ARDBC plug-in, the installation script starts the AR System server (and with it, the Approval Server) automatically. The installation procedures should automatically start the Approval Server along with the AR System server. But you can stop the server and start it manually to verify the installation or troubleshoot problems. For more information, see the Installing guide.
WindowsStarting the server

This section describes how to start Approval Server manually on Windows.
To start the Approval Server on Windows

1 Access the Services screen. a Choose Start > Settings > Control Panel. b Double-click Administrative Tools. c Double-click the Services icon. 2 Select the appropriate server.
The first or only server installed on a computer is called Remedy Action Request System Server. Additional servers are listed as Action Request System <server name>.
3 Choose Action > Start.
WindowsStopping the server

This section describes how to stop the Approval Server manually on Windows. You can stop other services using the same procedure. To stop multiple services, stop them in the following order:
1 AR System server 2 Approval Server Portmapper
27
To stop the server

1 Access the Services screen: a Choose Start > Settings > Control Panel. b Double-click Administrative Tools. c Double-click the Services icon. 2 Select the appropriate server.
The first or only server installed on a computer is named Remedy Action Request System Server. Additional servers are listed as Action Request System <server name>.
3 Choose Action > Stop.
UNIXStarting and stopping the server manually

This section describes how to start and stop the Approval Server manually on Windows.
To start the server manually

1 Log in as root or, in a non-root installation, log in as the user who starts the
AR System server.
Note: Make sure that you have read/write access to the /dev/console file before you restart the server as non-root.
2 Enter the appropriate command, as shown in the following UNIX start
commands table.
If you install multiple servers, your directory might be called arsystem_<servername>.

System Type HP-UX Command If you added a startup script, use /sbin/init.d/arsystem start or, if you accepted the default installation directory, use /usr/ar/<server_name>/bin start or, if you installed into another directory, use <ar_install_dir>/bin/arsystem start. If you accepted the default installation directory, use /usr/ar/<server_name>/bin start or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
start.
IBM AIX
Solaris
If you added a startup script, use /etc/init.d/arsystem start or, if you accepted the default installation directory, use /usr/ar/<server_name>/bin/arsystem start or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
start.
Linux
If you added a startup script, use /etc/init.d/arsystem start or, if you accepted the default installation directory, use /usr/ar/<server_name>/bin/arsystem start or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
start.
To stop the server manually

1 Log in as root or, in a non-root installation, log in as the user who starts the
AR System server.
2 Enter the appropriate stop command: System Type HP-UX Command If you added a startup script, use /sbin/init.d/arsystem stop or, if you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/arsystem
stop.
IBM AIX
If you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/ arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/ arsystem stop. If you added a startup script, use /etc/init.d/arsystem stop or, if you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/arsystem stop. If you added a startup script, use /etc/init.d/arsystem stop or, if you accepted the default installation directory, use sb/usr/ar/<server_name>/bin/arsystem stop or, if you installed into another directory, use <ar_install_dir>/bin/arsystem stop.
Solaris
Linux
29
If you install multiple servers, your directory might be called arsystem_<server_name>.

WARNING: Do not use the kill -9 command to stop the server. Doing so might leave your database in an inconsistent state.
Using an AR System server without portmapper

Without Portmapper running, an AR System server requires manual port configuration for communication with the Approval Server. For more information about Portmapper, see the Configuring guide. The following section lists the procedures you must perform for this configuration.
Note: The following procedures use example port number values. Your configuration can use any port numbers that do not conflict with existing ports. You can discover your existing ports in use with the command netstat -a (Windows) or rpcinfo -p (UNIX).
Configuring the AR System server without portmapper

You can use BMC Remedy Administrator to disable Portmapper and to assign one port number to the whole AR System server.
To configure the AR System server without portmapper

1 From BMC Remedy Administrator, log in to the appropriate AR System
server.
2 Choose File > Server Information > Server Ports and Multiple queues. 3 Enter a port number in the Server TCP/IP Port field.
The example port number in these procedures is 9030.

4 Clear the Register with Portmapper check box. 5 Stop the AR System server and restart it.
The AR System server is listening on the ports now.
Configuring the Approval Server without portmapper

For the Approval Server to communicate with an AR System server, one entry has to be added to the configuration file.
To configure the Approval Server without portmapper

1 Open the file
<ar_install>/conf/ar.cfg,
(Windows) or
ar.conf
(UNIX).
Note: You must modify this file on each AR System server to be used without portmapper.
2 Add the following line to specify the port number.
Approval-Specific-Port: 9030
3 Stop and restart the Approval Server.
See Manually starting and stopping the Approval Server on page 27 for the procedures for Windows and UNIX.
Uninstalling the Approval Server

These procedures explain how to uninstall the Approval Server on Windows and UNIX. Log files are generated during the uninstallation of this product. Upon successful completion, these files can be removed.
Removing a Windows installation

To uninstall the Approval Server for Windows, use the Add/Remove Programs control panel. Locate and remove the AR System Approval Server.
Removing a UNIX installation

The Approval Server uninstaller, ar_apuninstall, is located in the directory <install_dir>/approval/bin/.
WARNING: The UNIX uninstaller references other files relative to its own directory. Set the current directory to the one in which the uninstaller executable resides.
Uninstalling the Approval Server
31
Each uninstaller displays instructions at runtime. To proceed, you must enter a valid administrator login ID and password. You must also specify whether you want to uninstall shared forms.
Where to go next
See Chapter 2, Understanding the approval process, for basic Approval Server concepts. See Chapter 7, Preparing process administrators, for process administration concepts. See Chapter 5, Processing approval requests with Approval Central, for instructions on how to approve requests. See Chapter 6, Using a sample application, for a demonstration of acting as an approver using one of the sample applications. See Chapter 12, Implementing sample application features, for a demonstration of process administration using one of the sample applications. See Chapter 13, Adding approvals to your application, for instructions on how AR System administrators configure the Approval Server to work with existing applications.
Chapter
Understanding the approval process

This chapter is written for all users and administrators of the AR System Approval Server. The following topics are provided: The basic approval (page 34) The approval process (page 34) The BMC Remedy Approval Server (page 35)
Understanding the approval process
33
The basic approval

An approval indicates agreement or rejection of a request. In business, approvals are generally signatures of key individuals, recorded for the purposes of providing an audit trail or proof of authenticity. Approval example When you ask your boss to sign for your vacation or a new computer, you are requesting an approval. Your signed check is an approval of the transfer of funds from your account, and your signed lease is an approval for living under the terms of your landlord. An approval is always a means to an end. A signature in the previous examples enables another activity or process: a paid vacation, a computer purchase, a funds transfer, or promise of living conditions. The Approval Server is a means to approving AR System workflow.
The approval process

An approval process is the set of rules and procedures for selecting people to review and authorize a request in the proper manner. 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, although sometimes the process or signatures are not obvious. For example, even if everyone in the company is automatically reimbursed for up to $25 in office supplies, there is a hidden process with implied signatures that are not actually demanded. The Approval Server handles these hidden processes as well as those requiring traditional routing to multiple people for sign off. In the business world, approval processes rarely require only one persons approval. Business processes often require many people to sign off in order of their chain of command. Some businesses route approvals to more than one department at the same time. All business processes need to cope with substitutions for unavailable people, holidays, or other complications.
34 Chapter 2Understanding the approval process
A given request might require one process for completion, or several processes that work with each other. Often the appearance of a single operation involves multiple approvals. One request can generate multiple approval processes Imagine an office employee requesting a faster personal computer. The request to purchase a new computer has to be approved by the employees manager. If the manager approves, a separate MIS department approval process then determines the model of computer to buy. These approval processes are separate, but both must be completed successfully for a computer to be delivered. Approval processes must be able to handle a variety of situations without failing. Imagine a process that skips required people, or gets routed to a person without authority, or a process that cannot cope with vacationing persons and other anomalies. When an approval process fails, so does the attached activity. The funds are not transferred, the apartment is leased to someone else, or the computer is never delivered.
The BMC Remedy Approval Server

The BMC Remedy Approval Server is a self-contained, shared module that can be attached to any AR System application. the Approval Server is an extremely powerful and flexible solution for automating any approval process across any organization. You can have multiple Approval Servers running with multiple AR System servers on one machine.
Figure 2-1: Using approval server with AR System applications
35
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 (approving or rejecting). The Approval Server then reactivates the original application, reporting the result of the approval process. Finally, the Approval Server includes built-in contingency handling that makes sure approvals are completed quickly and properly within the system.
Common experience across applications

With the Approval Server, there is no need to build custom workflow or separate solutions for each application. All processes can share the same approval engine. The Approval Server lets you use one central approval engine for all applications, and it lets administrators swiftly implement one common solution. Consequently, there is no need to look at different applications.
Flexibility
Todays diverse demands require the Approval Server to be flexible enough for any AR System application. There are often differences in how approvals should work between different applications within the same company. Who needs to sign this next? Do I have all of the signatures I need? How many is enough? What happens if there is an error? The Approval Server provides flexibility so you can easily define or modify how each approval process should work. You can quickly set up new processes and adapt existing processes as changes appear in your environment. Customization of the Approval Server does not require programming, for example, when changing approval cycles, models, or approvers.
Notification plus feedback

Although the system is named an Approval Server, it is really more than an application that asks for approvals. You can use the Approval Server for any process where there is a need for agreement or acknowledgment from others. Acknowledge or agreement Imagine you had to turn off an important system for maintenance. It would be helpful to send out approvals to affected customers in advance. While the customers are not really approving the downtime, their approval is an acknowledgment of the coming change and the fact they are prepared for it. If they reject the change, those customers are indicating that they are not prepared, and might need additional assistance. An alternative process could be a simple AR System notification. There is no feedback loop defined with notifications, however, so it is difficult to know if everyone has seen the notice and is ready for the upcoming event. The Approval Server adds notifications to feedback loops, ensuring your workflow has been seen and approved by all the relevant parties.
37
Chapter
The BMC Remedy model for approvals

This chapter provides an overview of the Approval Serverfrom approach and key concepts through the interaction of both approvers and administrators. The following topics are provided: Key concepts of the Approval Server (page 40) Where to go next (page 44)
The BMC Remedy model for approvals
39
Key concepts of the Approval Server

An approval requires a process for people to acknowledge. This chapter discusses process, the people, and the acknowledgment.
The approval process

An approval process is the set of rules and forms that generate data to authorize specific AR System workflow. An approval process consists of some definitions for the operation itself, rules that define what happens at each specific stage in the process, and a place to store signatures. These rules need to be understood by process administrators, but are transparent to approvers. The types of rules and how they interact are described under Common rules and operations on page 88. The data generated by an approval process, such as sign-off signatures, requests for clarifications, and time stamps for audit trails, is stored in the Detail Record and other supporting forms. For more information about data, see Approval data on page 85.
Complex processes
Sometimes a single operation actually involves multiple approval processes chained together, such as when a manager has to approve a new computer purchase, but MIS has to pick out a specific model of computer. Process administrators need to set up these chained processes carefully. Properly designed, a chained approval process is transparent to the approvers and people requesting approval, so that it appears as one smooth operation.
Who participates in the approval process

Three kinds of people are involved in the approval process: those requesting approval, those approving requests, and process administrators who set up and modify the Approval Server configuration. Most approval processes are transparent to the requester, who therefore does not need to understand the Approval Server. This guide is written for approvers and process administrators.
40 Chapter 3The BMC Remedy model for approvals
Requesters
Requesters are the people who want something to be approved. Requesters work within an application that starts an approval process. They enter requests within the application and at some stage their application request must be approved. Their requests are routed to all required approvers and the results returned without further action by the requesters. The Approval Server allows requesters two interactions besides initiating a request: Requesters can check on the status of their requests. An approver can ask for more information from the requester, who will have to respond with the information to allow the approval process to continue.
Approvers
Approvers are people with the authority to approve or reject a request in a given process. Once you approve a request, you never see it again, and have no chance to change your mind. The request is routed only to the remaining approvers. Likewise, once you reject a request, you cannot change your mind. No one else sees it; the routing stops and the request is closed. Valid approvers for each process are set up in the Approval Server, and they are used to form a specific Approver List for each request. Different requesters can have different approver lists for the same process. An approver list specifies the exact list of signatures required for a specific request. A signature can come from an individual, or it can come from a role containing multiple individuals. The Approval Server allows you the flexibility to work with any combination of individuals and roles to create an Approver List for a particular process. Individual approver versus role Franks company rules say he can get the signature of any manager to authorize reimbursement for office supplies. However, company rules say Frank must get his direct supervisor to authorize reimbursement for travel related expenses. Jack, Larry, and Samantha have the role of manager, so any of them can approve Franks office supplies. Jack is the individual who supervises Frank, so only Jack can authorize Franks travel expenses.
Key concepts of the Approval Server 41
Approvers interact with the Approval Server more than requesters. They need to review outstanding requests that are assigned to them and take action on those requests. Approver actions are performed using one central form, called Approver Central. The actions they can take include: Approving Rejecting Reassigning Holding Requesting and responding to More Information Requests Checking status Approvers have access to the details of the item being processed as well as to the history of the approval detail record itself. This history includes all approvers who have had the request, and the actions they took. Also, any comments that have been entered by other approvers are available for review. As an Approver, you can define alternates to act as you for any approval process in which you participate. This substitution occurs during a time period you must specify.
Alternate
Approvers are not always available. When vacations or business trips occur, someone needs to cover for the individual who is out. Approvers can define an alternate with exactly their own capability and authority within an approval process. Having an alternate is not the same thing as having a peer with authority to approve the same process as you. An alternate is someone who substitutes for you and acts with your authority and privileges for a duration of your choice. Approvers have the option to set up any number of alternates, and each alternate might be set up to substitute within one or more approval processes.
When approvers designate you as an alternate, the Approval Server gives you the option to see your own approvals, or to see this other persons approvals as his or her alternate. You are always logged in as yourself, but you must specify whether you are acting as yourself or as an alternate. Acting as an alternate Jack is a regular approver for technical reviews. Samantha designates Jack as her alternate for technical reviews. Brigid designates Jack as her alternate for legal reviews. After Jack logs in to the Approval Server, he must select whether he wants to act as Jack, to act as Samantha, or to act as Brigid. Although Jack can switch between three approver identities, Jack can act as only one identity at a time. Because Jack must specify one identity before he sees any approval requests, there is no possibility that Jack can sign Samanthas requests with Brigids authority, or his own. When Jack acts as Samantha, it is irrelevant that he also has authority within the technical review process when acting as himself. When Jack acts as Samantha, he sees only Samanthas technical review requests and approves or rejects them with Samanthas authority. Likewise, when Jack acts as Brigid, he has Brigids authority within the legal review process, and cannot act as Brigid for technical reviews.
Process administrator
To automate approval processes, one person or authority must define each process. The Process Administrator is the person with the ability to define processes for the Approval Server. A second ability of the Process Administrator is the override. Sometimes emergencies require someone to override the normal flow of a process. The third ability of the Process Administrator is to grant others limited authority, allowing specific individuals an ability to configure a process, to override a process, or both. The Process Administrator also has the ability to designate alternates for any approver. Process Administrator actions are performed using one central form, called AP:Administration.
Key concepts of the Approval Server
43
Note: An Approval Server Process Administrator is not the same as your BMC Remedy Action Request System Administrator. See Chapter 7, Preparing process administrators, for an explanation of the Process Administrators responsibilities.
Acknowledging approvals
The Approval Server has three methods to allow AR System users who are not approvers to track, or interact with, an approval process.
Notification
For every stage of the approval process, AR System notifications can be defined to inform interested parties of the status of an approval request.
More Information Requests

An approver who has questions can send a more information request to the requestor (or any other AR System user). More Information Requests and their responses are handled by the Approval Server.
Audit trail
All activity within the system is recorded within the detail record. The AR System captures approver activity, the time an activity occurred, and what that activity was. This allows you to track the progress of the entry and see which activity was performed at each stage.
Where to go next
Now that you understand the basic concepts of the AR System Approval Server, you can review the following chapters covering approvers, installation, and process administrators. Chapter 1, Installation and configuration, contains installation instructions for AR System administrators. Chapter 4, Working as an approver through Chapter 6, Using a sample application, contain concepts, procedures, and examples for approvers. Chapter 7, Preparing process administrators, and later chapters contain information for Approval Server Process Administrators.
Chapter
This chapter discusses the approval process as it pertains to approvers. The following topics are provided: Processing an approval request (page 46) Viewing approval requests (page 46) Performing other approval actions (page 47) Handling approval errors (page 49) Designating alternate approvers (page 49) Performing overrides (page 51) Chapter 5, Processing approval requests with Approval Central, covers procedures for acting on approvals.
45
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 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. If the request appears unacceptable, you can reject it. Rejection typically ends the process for this request.
Note: The exception to the rejection outcome is statistical rules, introduced with the 5.1 release. For more information, see Get authority on page 104.
If you feel that you are not the appropriate person to approve the request, you can reassign it. For procedural information, see Chapter 5, Processing approval requests with Approval Central.
Viewing approval requests

The Approval Central form is the primary form for approvers. Approval Central lets you view approval requests and More Information Requests. Approval Central allows you to display your own requests, or the requests for which you can respond as an alternate for someone else.
46 Chapter 4Working as an approver
Guide for Users and Administrators Figure 4-1: Approval Central in browser
You can also view the Detail-Signature record for requests that have you as an approver. This is useful if you need historical information about a completed request, or if you want to verify the status of a current approval request that you have already approved.
Performing other approval actions

For some approval requests, you might need to perform additional actions such as the following procedures: Requesting more information on page 48 Reassigning an approval request on page 48 Specifying the next approver on page 48
Performing other approval actions
47
Requesting more information

Asking for clarification is more friendly than rejecting a request for which you have insufficient knowledge. For example, you might want clarification of dates or other details. Within the Approval Server, you can create a More Information request before acting on an approval request.
Note: A More Information request creates an independently routed AR System form, separate from the original approval request.
As an approver, you can use the More Information request to ask a question regarding the original request. The original request then pauses until you respond to it. Others can see that the request is paused in a More Information status. Your response to the original approval is independent from the More Information routing. You never have to wait for the More Information answer. However, if you do approve or reject the original approval request, the Approval Server immediately closes your outstanding More Information Requests. For procedural information, see Processing More Information Requests on page 62.
Reassigning an approval request

If you feel you are not the correct person to act on an approval request, many processes allow you to reassign a request to a different approver. In such cases, a Reassign field is displayed on the approval form. When you reassign an approval request, your obligation to act on it ends. For procedural information, see Reassigning approval requests on page 61.
Specifying the next approver

Some approval processes allow you to specify the next approver instead of automatically routing the request. Other approval processes might actually require you to provide the next approver.
For example, you receive an approval request for a piece of equipment that will be shared with another workgroup, and you need a signature from that workgroup in addition to your own. You can specify the approver in the other workgroup to whom the request is routed after you act on it. For procedural information, see Specifying next approvers on page 60.
Note: Specifying the next approver is not the same as reassigning an approval request. The option to specify the next approver requires you to approve or reject the request first. Use the option to reassign a request if instead of you, you want someone else to approve or reject a request.
Handling approval errors

If you enter an invalid name when you specify the next approver, a properly designed process generates a signature line error. The approval process stops with an error status until you correct the error by specifying a valid next approver.
Note: Errors from an improperly designed approval process cannot be corrected by an approver. Process administrators can see Get next approver automatically on page 93, for information to make sure a process validates the next approver properly.
Designating alternate approvers

Alternate approvers are approvers, assigned either by you or by the Process Administrator, to serve in your place if you are unavailable. You can assign alternates for yourself, or you can be asked to serve as an alternate for another approver.
Designating alternate approvers for yourself

If you will be unavailable for approving processes, you can designate other persons to fill in for you as alternate approvers to prevent delays in the approval process.
Handling approval errors
49
Typically, one alternate is chosen for all approval processes, but you can designate more than one alternate approver, and you can also specify specific approval processes for each alternate. You must specify both a time period and the processes for which the alternate can grant approvals. For example, you can designate one alternate for three days, and another for four. You can designate one alternate with approval authority for all processes, and another alternate with authority to process your vacation requests but not your purchase requisitions.
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.
Alternate authority is not transferable
Violet is out of the office for a week and designates Larry as her alternate. Larry departs on a surprise business trip, and designates Jack as his alternate. Jack does not have signature authority for Violets requests. Jack cannot see Violets requests. For procedural information, see Designating alternate approvers on page 66.
Serving as an alternate approver

If you have been designated as an alternate approver, you have signature rights and responsibilities identical to those of the original approver for as long as you serve as an alternate. Your authority as an alternate approver exists for a specific time period. Your authority can be defined for all processes, or a specific process. Alternate approver scenario Jack goes out of town to a trade show August 18. Jack designates Samantha as alternate for all his approval processes from August 15. However, from August 68, Samantha is limited to acting as alternate for only the office supply approval process, because the district manager Larry is going to be onsite acting as Jacks alternate for Jacks other processes. When you have been designated as an alternate, you see and respond to approvals in the same manner as when you are a normal approver, but the system knows you are acting as another person. The Approval Server shows you only approval requests for one person at a time.
Acting as an alternate
The Approval Server reinforces the separate identities Larry can assume, by asking him to choose for whom he is acting: as himself, or as an alternate. If Brigid designates Larry as alternate, when Larry acts as himself, he reviews only his own approval requests. When Larry acts as Brigids alternate, he reviews requests only within processes where she has designated Larry as alternate. Acting as Brigid, Larry responds to Brigids requests with her authority in that process, even if Larry normally has weaker or stronger signature authority. For information about processing approvals, see Processing an approval request on page 46. For specific procedural information about serving as an alternate, see Acting as an alternate approver on page 68.
Managing alternate approver definitions

With the 7.0 release, you now use the Approval Central application to designate (create), verify, and modify alternate approver information. For example, with this application you can create a new alternate, change an alternate to someone else, modify the time period during which an alternate will serve, or cancel an alternate so this person can no longer approve requests in your name.
Note: Although you can use the Alternate Approver form to designate and change information regarding alternate approvers, it is now best to use Approval Central for all alternate approver information.
For procedural information, see Managing alternate approver definitions on page 68.
Performing overrides
Overrides can be thought of as a special power to correct unexpected situations. An override is performed by a process administrator instead of the normally defined approver, to move a request forward when the normal approver is not responding. An override is useful for emergencies such as when an approver is absent or unable to respond, and no alternate approver is designated. The process administrator can override that signature line so the process can continue.
51
An override closes one approver signature, similar to acting as an alternate approver for one signature line, allowing the approval request to move on within the regular process. 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 there are more approvers, the request is routed to them.
Note: A process administrator can give out override-only administrator privileges to any user without granting other approval process administrator privileges.
Global overrides
An advanced global override closes all open signatures, stops routing the request, and terminates the approval process for that request. This global override is useful for emergencies, such as ending an approval process for a request that is no longer necessary. Example of global override Imagine Sue makes a time-sensitive request that requires the approval of Samantha and Ned, in that order. Samantha is delayed by traffic and will not arrive in time to approve the request before it is required, therefore the sympathetic process administrator performs an override, immediately approving the request, which routes the request to Neds desk. Should it happen that Samantha and Ned are both delayed in traffic, the process administrator can perform a global override, approving or rejecting the request for all approvers at once, so Sue can react before her time limit expires. For procedural information about overrides, see Additional options for process administrators on page 70.
Chapter
Processing approval requests with Approval Central

This chapter shows how to use the Approval Central application to process approval requests with both web clients and BMC Remedy User. For the 7.0 Approval Server release, there is now a consistent look and feel between the web and BMC Remedy User views of Approval Central. Nearly all the examples in this chapter use the web client. The following topics are provided Logging in to Approval Central with a browser (page 54) Logging in to Approval Central with BMC Remedy User (page 56) Defining approval details (page 58) Processing More Information Requests (page 62) Using alternate approvers (page 65) Additional options for process administrators (page 70)
Processing approval requests with Approval Central
53
Logging in to Approval Central with a browser

The following procedure outlines the basic steps for processing an approval request using browsers. For information about additional approval actions you might need to perform, see Defining approval details on page 58.
Note: the Approval Server web views allow approvers to process approval requests from a browser once an administrator has installed Approval Web using the steps in Using the Approval Server on the web on page 25. Process Administrators must use BMC Remedy Administrator and BMC Remedy User to configure approval processes and perform overrides.
To log in to Approval Central with web clients

1 Launch your browser and type in the Approval Central URL for your
Approval Server. See your AR System Administrator for the exact Approval Central URL of your Approval Server. For example, with a web server named acme that is accessing an AR System server named apex, the Approval Server URL might appear as follows:
http://acme/arsys/apps/apex/ApprovalCentral
2 When the login window appears, log in to the Approval Server.
Approval Central appears.
54 Chapter 5Processing approval requests with Approval Central
Guide for Users and Administrators Figure 5-1: Approval CentralBrowser
In this example, Approval Central displays a table for each application on your Approval Server that lists your pending approval requests within that application. The applications displayed here are AP-Sample2:Get Agreement and AP-Sample:Lunch Scheduler. To add additional applications, see Connecting an application to the Approval Server on page 230.
3 From the applications displayed, click the request for which you are
processing an approval.
4 For each request, select the appropriate response from the menu list:
Approve, Reject, or No Action. You can also enter the name of the Next Approver, if appropriate.
5 In the Next Approver field, enter the name of the next approver.
This must be an AR System login ID.

6 Click Submit when you have completed the entire page of requests.
You do not have to click Submit after each response.
Logging in to Approval Central with a browser
55
WARNING: There is no undo option when you respond to a request. Once you respond to a request, you do not have any opportunity to change your mind.
7 Click a link in the navigation pane to access additional information.
Access Privileges lets you both specify alternate approvers for yourself and log in as an alternate approver for someone else. More Info Requests lets you view and modify More Information Requests you created and More Information Requests others have sent you. Help opens a new browser window to display context-sensitive online help. The Logout button logs you out of the Approval Server.
Logging in to Approval Central with BMC Remedy User

The following procedure outlines the basic steps for processing an approval request using BMC Remedy User. For information about additional approval actions you might need to perform, see Defining approval details on page 58.
To log in to Approval Central with BMC Remedy User

1 From BMC Remedy User, log in to the appropriate AR System server. 2 Select File > Open.
The Open dialog box appears.

3 From the list of forms, choose Approval Central Application and click Open.
Approval Central appears.
Guide for Users and Administrators Figure 5-2: Approval CentralRemedy User
In this example, Approval Central displays a table for each application on your Approval Server that lists your pending approval requests within that application. The applications displayed here are AP-Sample2:Get Agreement and AP-Sample:Lunch Scheduler. To add additional applications, see Connecting an application to the Approval Server on page 230.
4 From the applications displayed, click the request for which you are
processing an approval. When you click the Approve/Reject cell of a request, an arrow appears. This indicates a menu list you can use to process the approval request by choosing one of the following options: Approve Reject No Action For example, to approve the Get Agreement request displayed in Figure 5-2, select Approve.
5 For each request, select the appropriate response from the menu list.
Logging in to Approval Central with BMC Remedy User
57
6 Click the Next Approver cell to enter the name of the next approver.
This must be an AR System login ID.

7 Click Submit when you have completed the entire page of requests.
You do not have to click Submit after each response.

WARNING: There is no undo option when you respond to a request. Once you respond to a request, you do not have any opportunity to change your mind.
8 Click a link in the navigation pane to access additional information.
Access Privileges lets you both specify alternate approvers for yourself and log in as an alternate approver for someone else. You can also create an alternate for yourself. More Info Requests lets you view and modify More Information Requests you created and More Information Requests others have sent you.
9 Choose Help > Help on Approval Central Application (or press F1) to open
the Approval Server 7.0 online help window.
Defining approval details

This section describes how to perform the following actions with the Approval Details window: Approving approval requests Specifying next approvers on page 60 Specifying multiple approvers on page 61 Reassigning approval requests on page 61
Approving approval requests

This section describes how to approve requests.
To approve requests
1 Log in to the Approval Server as shown in Logging in to Approval Central
with a browser on page 54 or Logging in to Approval Central with BMC Remedy User on page 56.
2 Double-click the Req. ID column entry for the request you want to examine.
For example, in Figure 5-1 on page 55 you would click the number 0001 for the Get Agreement request. The Approval Detail view appears. You can now review the details of the request.
Figure 5-3: Reviewing the details of an approval request
3 From the Approval Status menu list, choose the status to which you want to
set this request, such as Approved or Rejected.
59
If you do not want to respond with approval or rejection, you can ask for more information, as described in Processing More Information Requests on page 62.
4 Add comments to the Comments field, if necessary. 5 Click Save Changes.
The Approval Central window appears with the updated information.
Specifying next approvers

Perform the following procedure if you must specify the next approver instead of automatically routing the request. With some processes, approvers can or must specify the next approver. You must specify the next approvers before or at the same time as you approve or reject the approval request. After you have approved or rejected the request, you will no longer have access to the Next Approvers field. For conceptual information, see Specifying the next approver on page 48.
To specify next approvers

1 In Approval Central, click the request for which you are processing an
approval.
2 In the Next Approver field, enter the names of the next approvers.
This must be one or more exact AR System login IDs. To specify multiple approvers, separate each name with a semicolon (;).
3 Click Submit to save your changes.
Or:
1 Open the Details of the approval request as shown in Approving approval
requests on page 59.

2 Enter the names of the next approvers in the Next Approvers field.
This must be one or more exact AR System login IDs. To specify multiple approvers, separate each name with a semicolon (;).
3 Click Save Changes to save your changes.
Specifying multiple approvers

Perform the following procedure if you must specify multiple approvers.
To specify multiple approvers


2 If you choose to specify multiple approvers, determine the appropriate
option for the If Multiple Approvers field: To allow the request to be approved by a single signature, select One Must Sign. To require all specified approvers to sign for the request to be approved, select All Must Sign. Otherwise, use None, the default process setting for multiple approvers.
Reassigning approval requests

Perform the following procedure if you must reassign an approval request. For conceptual information, see Reassigning an approval request on page 48.
To reassign approval requests


2 In the Reassign To field, enter the name of the approver to whom you want
to reassign the request. This must be one persons exact AR System login ID.
The Approval Server routes the request to the reassigned approver.
61
Processing More Information Requests

Some approval requests can require other actions, such as requesting more information. The following procedures outline the basic steps for requesting more information and responding to anothers More Information Requests. Requesting more information about approval requests Viewing and responding to the More Information Requests to you on page 63 Viewing More Information Requests you have submitted on page 65
Requesting more information about approval requests

Use the following procedure to request more information before approving a request. For conceptual information, see Requesting more information on page 48.
To request more information about approval requests

1 Open the Details of the approval request, as shown in Defining approval
details on page 58.

2 Click the Request More Information button to create a More Information
request. The Request More Information dialog box appears.

Figure 5-4: Creating a more information request
3 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 one persons exact AR System login ID.
4 In the Request field, enter your question or a description of the information
you need.
5 Click Submit to save your More Information request.
The following now occurs: The Approval Status for the approval request automatically changes to reflect your request for more information, and the Approval Server routes your request to the person in the To field. The More Information Requests appears in the Approval Detail window.
Figure 5-5: More Information Requests displayed
Viewing and responding to the More Information Requests to you

Use this procedure to display and respond to the More Information Requests directed to you regarding an approval.
To view and respond to More Information Requests to you

2 Click More Info Requests in the navigation pane.
The More Information Requests window appears. The top table lists the More Information Requests to you.
Processing More Information Requests
63
BMC Remedy Approval Server Figure 5-6: Displaying More Information Requests
3 Double-click the More Info ID for the request you want to respond to.
The Modify More Info Request dialog box opens.

Figure 5-7: Responding to a more information request
4 Type your answer in the Response field. 5 Click Submit to save your changes.
The status of the request will automatically change to Completed. The request no longer appears in More Information Requests window but the Approval Server routes your response back to the More Information requester.
Viewing More Information Requests you have submitted

Use this procedure to display the requests for more information you have asked from others.
To view More Information Requests you have submitted

The More Information Requests window appears, as shown in Figure 5-6 on page 64. The bottom table lists the More Information Requests from you.
3 Double-click the More Info ID of any request for which you want to view
details. Review the read-only information in the More Information form
Using alternate approvers

The following sections provide instructions for designating alternate approvers and for serving as an alternate approver. For conceptual information, see Designating alternate approvers on page 49. Designating alternate approvers Acting as an alternate approver on page 68 Managing alternate approver definitions on page 68
65
Designating alternate approvers

Use the following procedure to create an alternate approver for yourself. If you want multiple alternates, repeat this procedure for each alternate.
To designate alternate approvers

2 Click Access Privileges in the navigation pane.
The Access Privileges view appears.

Figure 5-8: Access Privileges window
3 Click the Add New Alternate button.
The Add New Alternate dialog box appears.
Guide for Users and Administrators Figure 5-9: Creating an alternate
4 In the Alternate field, type the AR System login name for the person to
designate as your alternate.

5 Use the Start Date and End Date fields to specify the time frame in which you
want the alternate to act on your behalf.

Note: There might be a time lapse up to 60 minutes past your defined End Date before an alternate loses their privileges because of the escalation interval. For performance reasons, this interval is set to 60 minutes in the Approval Server.
6 With the Covering menu list, select the process for which you want the
alternate to have your signature authority. To authorize all processes for which you have signature authority, select All. To authorize a specific process, select Specific Process, and then select a process from the Process menu list.
7 Select No from the Notify Alternate menu if you want to prevent
notifications from being sent to the alternate for each new approval.
8 Click Submit to save your changes. 9 The Alternate Approvers table is refreshed with the new entry.
67
Acting as 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. The steps for processing an approval request as an alternate are the same as for the original approver; however, before you act on an approval request, you must identify yourself as an alternate approver.
To act as an alternate approver

The Access Privileges form appears, including the Change Current Approver section.
Figure 5-10: Entering an alternate login ID to act as Enter AR System Logon ID of the person for whom you are alternating.
3 From the I would like to approve request: menu list, select For Someone Else. 4 In the (Enter Login Name) field, type the AR System login name of the
person for whom you are acting as alternate.

5 Click Change Approver to see requests as an alternate approver.
The Approval Central screen appears. You can now approve requests with the signature authority of the person who designated you as alternate.
Managing alternate approver definitions

Use the following procedures to review or modify information about an alternate approver.
Viewing the record for an alternate approver

To view the record for an alternate approver
The Access Privileges form appears, including the list of active alternate approvers.
Figure 5-11: Reviewing your designated alternates
Modifying the record for an alternate approver

If the circumstances for an alternate approver change, you can modify the record for that approver by performing the following procedure.
To modify the record for an alternate approver

1 Open the list of alternates as shown previously in Viewing the record for an
alternate approver on page 69.

2 Click on the name of the alternate you want to modify.
The Modify Alternate dialog box appears.
69
BMC Remedy Approval Server Figure 5-12: Modifying an alternate record
3 Modify the fields you want to change.
If you want to cancel this approver, select Cancelled from the Status field.
4 Click Submit to save your changes.
Additional options for process administrators

The Approval Server allows process administrators capabilities beyond those of the normal approver. Process administrators can define alternates for other approvers, and they can override processes for one or all remaining signatures.
Defining alternates for other approvers

As process administrator, you can define alternates for any approver within any process where you have process administrator authority.
To define alternates for other approvers

1 Create an alternate. See Using alternate approvers on page 65 for the
procedure.
2 In the For field, type the AR System user ID of the person this alternate will
be substituting for.
3 Click Save to save your changes.
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. For conceptual information about overrides, see Performing overrides on page 51.
Performing an override to a single signature

You can perform an override to a single signature.
To perform an override to a single signature

Figure 5-13: Selecting the override option
Enter AR System Logon ID of the person for whom you are alternating.
3 From the I would like to approve request: menu list, select As Override. 4 In the Login Name field, enter the name of the approver whose signature
authority you want to override.

5 Click Change Approver to see requests as the override approver.
The Approval Central screen appears with a list of the persons pending process records. You can now approve or reject their requests with override authority by performing one of the following tasks: Approve or reject the request from Approval Central. Open the request in the Approval Detail window if you need to add additional details.
Additional options for process administrators
71
Performing a global override

Global overrides include approving or rejecting a request regardless of any response by normal approvers.
To perform global overrides

Figure 5-14: Selecting the global override option
3 From the I would like to approve request: menu list, select As Global
Override.
4 Click Change Approver to see requests as the global override approver.
The Approval Central screen appears with a list of all pending process records. With global override authority, you can now approve or reject their requests with override authority by performing one of the following tasks: Approve or reject the request from Approval Central. Open the request in the Approval Detail window if you need to add additional details.
Chapter
Using a sample application
This chapter demonstrates how to use Get Agreement, one of the sample applications bundled with the Approval Server. The following topics are provided: Using the Get Agreement sample application (page 74) Summary of sample (page 82)
Using a sample application
73
Using the Get Agreement sample application

This sample application Get Agreement demonstrates an Ad Hoc process. See Ad HocApprovers choose who is next on page 112 for the definition of an Ad Hoc process type. First you will use Get Agreement to request a new computer. Then you will log into the AR System Approval Server as different approvers to request and respond to a More Information request, and to reassign the approval request. After all approvers have approved the request, you will retrieve and examine the approved form.
Note: The procedures in this chapter require sample users Frank Williams, Jack Miller, Larry Goldstein, Violet Anderson, and Sue Smith to be licensed AR System login names. If you find you cannot log in or write AR System records as the sample users, ask your Approval Server process administrator to license the sample application login names. For more information, see Licensing sample users on page 226.
Making a new approval request

This section shows how to use the sample application to start the approval process by creating a new approval request.
To make a new approval request

1 Log on to the appropriate AR System server as sample user Frank Williams.
For more information, see the following methods: Logging in to Approval Central with a browser on page 54. Logging in to Approval Central with BMC Remedy User on page 56
2 Open the Get Agreement form in New mode.
Figure 6-1 illustrates the Get Agreement form displayed in a browser.
74 Chapter 6Using a sample application
Guide for Users and Administrators Figure 6-1: New request within Sample2:GetAgreement
3 Type I need a new computer in the Summary field. 4 Type a longer description in the Details field. Exact wording of the Details
field is not critical for this example.

5 Type the names of three sample users in the Initial Approvers field.
Since this is an Ad Hoc process, every approver must be chosen manually. Use Jack Miller, Larry Goldstein, and Violet Anderson. Type a semicolon between each approvers name.
6 Click Save to save your request for a new computer.
Approving a request
The next procedure demonstrates how an approver responds to a request. It requires that you have completed the previous procedure, Making a new approval request.
1 Log in to the Approval Server as sample user Jack Miller using one of the
methods described in Processing approval requests with Approval Central on page 53.
75
Approval Central appears. Although most of the examples in this chapter use the web client, you could also use BMC Remedy User when processing approvals in Approval Central.
Figure 6-2: Approval Central application
2 Select the I need a new computer request from the Get Agreement
approvals.
3 Select Approve from the Approve/Reject cell in the Get Agreement
approvals, as shown in Figure 6-2. When you click the Approve/Reject cell of a request, a menu list appears for selecting approval options.
Note: If you see a warning saying you do not have permission to write to certain fields, this means Jack Miller is not a properly licensed AR System user. To continue with this example, your AR System administrator must license the sample users.
4 Click Submit to make your change permanent.
Notice that Franks request no longer appears in the list of Get Agreement approvals for Jack Miller. The next procedure requires that you followed the previous procedures regarding Frank Williams computer request.
Requesting more information

The More Information request allows approvers to ask questions and have them answered before responding to an approval request.
To request more information

1 Log in to the Approval Server as sample user Larry Goldstein using one of the
methods described in Processing approval requests with Approval Central on page 53.
2 In Approval Central, open the I need a new computer request.
The Approval Detail window appears.

3 Click the Request More Information button.
The Request More Information dialog box appears.

Figure 6-3: Larry creates a new more information request
4 Type the name Violet Anderson in the To field.
You can assign a More Information request to any valid AR System login name, including the requester. For this example, you are asking for more information from another approver.
77
5 Type a question in the Question field. The exact words are not critical for this
example.
6 Click Submit to create the More Information request.
The new More Information Request you created for Violet Anderson now appears in the Approval Detail window.
7 Click Save Changes in the Approval Detail window to save your changes.
Approval Central redisplays.

8 Click More Info Request in the navigation pane.
In the requests from Larry Goldstein, the More Info Status field of this request displays Pending.
Note: Larry could approve or reject the approval request without waiting for Violets response to the More Information request. In this event, Larrys More Information request will be closed when Franks computer request is done, regardless of whether the More Information request was seen by Violet.
Responding to a more information request

This procedure shows you how to answer a More Information request. It requires that you followed the previous procedures creating Frank Williams computer request, and Larry Goldsteins More Information request.
To respond to a more information request

1 Log in to Approval Central as sample user Violet Anderson. 2 In Approval Central, open the I need a new computer request as shown in
Approving a request on page 75.

The More Information Requests window opens, displaying More Information Requests to Violet and from Violet.
4 Open the Pending item from Larry Goldstein.
The More Information dialog box appears with the Response field enabled.
Guide for Users and Administrators Figure 6-4: Responding to a more information request
5 Enter a response to the More Information request into the Response field.
The exact wording is not critical to this example.

6 Click Save to make your changes permanent.
The dialog box closes. The More Information Request is no longer visible to Violet after she responds to it.
Reassigning an approval request

This procedure shows how an approver can transfer a request to another approver without otherwise responding to the request. It requires that you followed the previous procedures to generate Frank Williams computer request. You must be logged in as Violet Anderson.
Note: The ability to reassign a request might not be available in all processes.
To reassign approval requests

1 Return to Approval Central. 2 Open the request I need a new computer. 3 Type Sue Smith in the Reassign To field. 4 Click Save Changes to make your changes permanent.
Franks request is no longer available in Approval Central for Violet to approve or reject. Only Sue Smith and Larry can see Franks request now.
79
Displaying answers to More Information Requests

This shows you how to display and review More Information responses. To respond, you must use the procedure Responding to a more information request on page 78. It requires that you followed the previous procedures to generate Frank Williams computer request through Violets More Information responses.
To display answers to More Information Requests

1 Log in to Approval Central as sample user Larry Goldstein. 2 In Approval Central, click More Info Requests from the navigation pane.
The More Information Requests window appears. It displays information requests for you to answer and information requests from you to other users.
Figure 6-5: Larrys completed more information request
3 Select the completed More Information request.
The Modify More Info Request dialog box appears. With Violets response, Larry now has sufficient information to approve Franks request.
4 Cancel the Modify More Info Request dialog box.
5 Click Approval Central in the navigation pane. 6 In Approval Central, approve the I need a new computer request.
You can also open the request I need a new computer in the Approval Detail window, select Approved from the Approval Status menu list, and then click Save Changes to make your change permanent. Jack and Larry have approved, Violet has reassigned the request, so now only Sue Smith remains to approve or reject Franks computer request.
Finishing the sample request

This procedure shows you how to verify the status of a request after approval. It requires that you followed the previous procedures to generate Frank Williams computer request.
1 Log in as Sue Smith and approve the request as shown in Approving a
request on page 75.

2 Log out as Sue Smith. 3 In either a browser or BMC Remedy User, open the Get Agreement form in
Search mode as Frank Williams.

4 Click Search.
The list appears displaying Franks Get Agreement requests.

5 Select the request for the new computer.
Notice the status of the request is now Approved.
81
BMC Remedy Approval Server Figure 6-6: Status field displays approved
Franks request for a new PC has been approved.
Summary of sample
The procedures in this chapter demonstrated how to respond to an approval request, as well as how to create and respond to a More Information request. You also learned how to reassign a request to another person when that option is available. If you want to explore the new statistical rules that were introduced in the 5.1 release, go to Statistical Decision-Making approvals in a sample application on page 196. There you will continue using the Get Agreement application to see how statistical decision-making rules operate.
Chapter
Preparing process administrators

This chapter introduces concepts to prepare Process Administrators for setting up and maintaining the Approval Server. The following topics are provided: The role of the process administrator (page 84) Key features of the Approval Server (page 85) Common rules and operations (page 88) Approval process types (page 107) Notifications (page 115)
Preparing process administrators
83
The role of the process administrator

A Process Administrator is an AR System user with the authority to define an approval process for others to use. The first Process Administrator must be set up by the BMC Remedy 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 off for approval requests. As a Process Administrator, you perform the first three of the responsibilities following, and determine who can share each responsibility with you.
Process administrator responsibilities

This section introduces Process Administrator responsibilities. Exact procedures are discussed in other chapters. A Process Administrator: Designs the approval process for generating approval signature data when AR System workflow needs to be authorized. Connects Approval Server forms to workflow to accomplish the designed approval process. This includes setting up routing, and creating the list of authorized approvers. See Chapter 13, Adding approvals to your application, for a discussion of attaching the Approval Server to your existing forms. Can override a process, or parts of a process, should circumstances arise that must be handled outside of the capability of established workflow. See Assigning process override capability on page 211 for the discussion of overrides. Can assign limited administration rights to individuals for any specific processes, and can create and delete other Process Administrators as needed.
Sharing process administration authority

A Process Administrator has the authority to construct, configure, and manage all approval workflow, across every process within the AR System. Process Administrators also have the ability to create and delete other Process Administrators.
84 Chapter 7Preparing process administrators
Delegating process administration capability

A Process Administrator can also delegate limited authority to individuals who need authority for specific approval processes. Limited Process Administrators manage only the parts of approval process that have been specifically delegated by a regular Process Administrator. Override Only Process Administrators can approve or reject requests when they are not on the Approver List. However, an override-only administrator cannot create or modify process definitions. Specific Process means a user can act as a full Process Administrator, but only for a specific process. For example, you might wish to create a limited-authority Process Administrator for only purchasing approvals, or allow a department manager to override approval processes within only that department. See Setting up administrator capabilities on page 125 for the discussion of setting up Process Administrator rights.
Key features of the Approval Server

The two main components of any approval request are the data collected by a request, and the process used to generate approvals.
Approval data
The most important data generated by an approval request consists of the signatures of every person who approves or rejects the request. Other data useful for an audit trail includes More Information Requests and specific dates and times for each activity. The Approval Server collects this information about a Detail record for each request.
Detail record
All data about the approval are held in the Detail record. The Approval Server stores data about who authorized or rejected a request using the AP:Detail form. You can use this form to determine the status of a request, and see a history of activity on the request for a given approval process. The AP:Detail form captures and displays the essential data of every authorization and rejection generated by an approval process.
85
Supporting records
A number of supporting forms store and display information regarding each approval request. AP:Signature stores and displays the data regarding the signatures collected in the approval process. AP:More Information stores and displays the response should an approver ask for additional information before approving or rejecting a request. Join forms display information about your application and the approval forms. See the Connecting an application to the Approval Server on page 230 for more information about these join forms.
Approval process
When a group of employees needs to sign off on somethinga birthday card for another employee, for exampleyou must make sure every appropriate employee has a chance to sign the card, and that the card is delivered afterwards. Workers route approvals such as this birthday card without conscious thought to the rules for routing it. Yet there are rules in place. Usually it does not matter in what order people sign the card, but it would be inappropriate to request a second signature from someone who has already signed. Additionally, no one is usually required to sign a birthday card. And finally, it is inappropriate to request a signature from the person with the birthday! Processes abide by rules such as these without anyone thinking of them as rules. However, the Process Administrator setting up a business process must determine and implement all the rules.
Processes and rules

Understanding the difference between an approval process and the rules it uses is critical to setting up the Approval Server. An approval process is like a flowchart, defining the routing of the item requiring signatures. Like a flowchart, an approval process consists of many components: operations, transitions, and decision points, each contributing toward a defined destination. Also, like a flowchart, each approval process remains the same for all individuals. The Process Administrator can develop one process for approving new hires and another process for approving purchase orders, but the individual processes are not different each time they are performed. There are four types of processes: Parent-Child, Level, Ad Hoc, and Rulebased. See Approval process types on page 107 for a discussion of process types. Approval rules are those diamond decision boxes in your flowchart. Each time a process can diverge, you will need to set up a rule to control the direction of the process flow. For example, while a hypothetical new hire process remains the same for all candidates, a rule allows for a hiring managers approval to be handled differently than the personnel departments approval. Constructing the approval processes and rules is the hardest part of being a Process Administrator. You have to decide at the outset who has to sign off for each part of the workflow to be approved, and also decide how to route approvals so the proper people have an opportunity to approve or reject. The next section examines the common rules followed by all approval processes, followed by a section that applies the rules to the four different process types.
87
Common rules and operations

The Approval Server automatically includes certain rules and operations in every approval process: Self Check rulesPreventing unnecessary routing on page 90 (Can I approve my own request?) Next approver rulesDetermining who is next on page 93 (Who is the next approver?) Approver responseSignature line on page 96 (How did this approver react?) Statistical Decision-Making rulesDo you want to base your decision upon statistical data? on page 97 (Are there multiple rejections or approvals?) Routing completion checkWho is left? on page 102 (Does this persons approval complete the request?) Process done rules on page 105 (Is the request approved or rejected?) The following diagram displays the process of any approval request:
Figure 7-1: The approval process
Submit Request
Requester
Another Approver
Someone Entirely Arbitrary
Requester
1
Self Check Requester approved
Requester not approved
More Information Request (optional)
2
Yes
Next Approver
Approver Response
3
Approval Cycle
More approvers?
5
Process Done
No
4
Completion Check Approved Rejected
An approval process starts when someone requests an approval.

Step 1 The Approval Server immediately performs a one-time Self Check 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.
Step 2 If the requester does not have enough authority to approve the request, the
Approval Server checks rules to find Next Approver. Next approver rules start a cycle of locating people who need to approve this request.
Step 3 If an approver rejects the request, the approval process is typically done and
the rejected workflow is returned to the requester.

Note: The exception is statistically driven rules, introduced with the 5.1 release. For more information, see Statistical Decision-Making rules Do you want to base your decision upon statistical data? on page 97.
Step 4 If a person approves the request, then the Approval Server checks whether
enough people with sufficient authority have signed to Complete the authorization.
Step 5 When the approval process is Done, the Approval Server determines if the
approval was successful, and takes appropriate action.

Note: The difference between complete and done is important. When a request is complete, this means that it has been routed to all approvers. Even when routing is complete, all required approvers have not necessarily responded. The request is not done until all approvers have approved or rejected the request.
Process complete versus process done
Sue has a purchase order that has to be approved by two committee members, Samantha and Ned, in no particular order. Sue makes two photocopies and puts one in each of the approvers mailboxes. The approval process is complete at this point. No more routing actions need to occur. All approvers have received Sues request. However, Sues request is still active. Until Samantha and Ned have responded, the approval process for Sues purchase order is not done.
89
The Approval Server uses rules to determine the exact sequence of events to process an approval request. As Process Administrator, you should have some background on the types of rules available before you attempt to create your own approval processes.
Self Check rulesPreventing unnecessary routing

Self Check rules determine whether the requester has sufficient authority to approve his or her own request. The Self Check includes two tests that are conducted by rules of different types, auto approval and self approval, as shown in the following diagram.
Figure 7-2: Details of Self Check rules
Submit Request
Requester
1
Auto-Approval? Yes
No
Get authority
Next Approver
Get authority self Parameterized Get Next Approver
Approval Cycle
Selfapproval?
No
Process Done
Yes
Auto approval check

Self Check first tests for an auto approval condition. Auto approval occurs when any user has authority to approve a given request, independent of identity or role within the AR System.
Auto approval example
If a rule says everyone in your company can be reimbursed for a business lunch up to $40, and Frank requests approval for a $25 lunch, this scenario would trigger an auto approval condition. Since it does not matter who is asking as long as the amount is less than $40, this companys auto approval rule automatically approves Franks request for his $25 lunch. When auto approval occurs, the request is done, and routed back to the requester.
Self approval check

When a request fails auto approval, the Self Check then looks for a self approval condition. Self approval rules are executed only when the current user is the owner of the original request. Self approval has two types of rules, Get Authority information and Self Approval rules.
Get authority rules

Get Authority rules collect data, such as a dollar amount, or other information that determines the boundaries of this approvers authority. These rules do not use this information yet. Get Authority just lets you set up a process to collect information used for later decision making. There are two types of authority rules: Get Authority and Get Authority Self. They perform identical operations and might be treated the same. The difference between these two types is that Get Authority Self rules are performed only in the Self Approval Check portion of the approval process, allowing data gathering unique to Self Approval rules. Alternately, the Get Authority rule is performed both at the self check as well as later in the process during Completion rule processing, allowing a common data gathering mechanism.
Note: There is a third type of Get Authority rule, called Get Authority Regular, which is performed only during Completion processing. See Get authority regular rules on page 104 for a discussion of Get Authority Regular rules.
The information collected by your Get Authority rules is used by Self Approval rules in the next operation of the Self Check.
91
Self approval rules

The Self Approval check is completed when it executes Self Approval rules. Data collected earlier under the Get Authority rules are tested under Self Approval rules. The result of this test determines whether the requester has sufficient authority to complete the request. When Self Approval occurs, the request is done, and routed back to the requester. Example of self approval If Frank requests approval for a $50 business lunch, a $40 auto approval rule does not occur. After failing the auto approval test, the Self Check continues with a Get Authority or Get Authority Self rule to collect Franks employee status, as a permanent employee who has authority to approve lunches up to $100. The Self Approval rule then tests whether Frank-the-permanentemployee has authority to approve his own $50 lunch. To summarize, the Self Check tests a request using Auto Approval and Self Approval rules. If the rules test successfully, the request is done, and the approved workflow is returned to the requester.
Approver roles
If the Self Check cannot approve a request, then the request is routed to an approver with more authority than the requester. Authority for this approver can be established by a relationship with the requester, or by a role within your company. Consider the authority behind individuals in your organization. Generally authority is based on the persons relationship with the requester, or based on the role that this approver has within the organization. A relationship could be direct supervisor. A role could be marketing managers or company director. Think of a role as membership in a group, or a characteristic shared among many individuals. Role versus relationship Imagine your company allows any manager to approve a business lunch for up to $100. As Process Administrator, you would set up a manager role within the Approval Server and attach the names of all your managers to that role. Then when Frank requests approval for a $75 lunch, the request can be approved by any individual assigned to the manager role. Franks actual manager Jack can approve the request, or any of Jacks peers can do so, as long as they have the role of manager assigned within the Approval Server.
Alternately, if your company requires a lunch request above $100 to be approved by only the individual who supervises the requester, you can set up the process so only Jack, Franks direct supervisor, is allowed to approve Franks $150 request. In this case, the individual Jack has a specific relationship with Frank, and this relationship is set up within the Approval Server. The relationships and roles held by individuals determine the valid Approver List for any given process. With a valid Approver List, you can set up rules to find them. These rules, called Get Next Approver rules, are discussed in the next section.
Next approver rulesDetermining who is next

Next Approver Rules determine who must approve next, and also create electronic signature lines for individuals to indicate approval or rejection. Process Administrators can have the approval process automatically determine the next approver, or allow the current approver optionally to select the next. Additionally, if the next approver is a role, more than one individual can be eligible to sign one signature line. In this case only the first individual responding within the role determines the outcome for that signature line.
Get next approver automatically

Prepare (Prep) get next approver rules
These rules gather information to be used by the Get Next Approver rules. These rules are similar to the rules for Get authority rules on page 91, in that they gather information for later use. The approval process is not advanced by the Prepare Get Next Approver rules. It is advanced by the following Get Next Approver rules that use the information.
Note: If you are familiar with AR System workflow, consider that a set field action occurs with Prep Get Next Approver rules. Values are placed in certain fields, but nothing acts upon these values yet.
93
Get next approver rules

These rules route requests to the next valid approver. When the Process Administrator sets up an approval process, he or she determines a list of valid approvers. Get Next Approver rules determine who is next in the Approver List and creates signature lines for the people found.
Get next approver manually

Ad Hoc approvers
In most cases, the Process Administrator sets up a process to route a request automatically to the proper approvers. However, the Process Administrator can allow a person holding the request to circumvent the normal routing with a manual selection of next approver. Manual selection is accomplished with Ad Hoc Override capability. When enabled and selected, the Approval Server checks Ad Hoc approvers against the list of valid approvers for the current process. Once validated, an Ad Hoc approver continues with the approval process exactly as if the approver had been assigned by normal rules.
Note: An Ad Hoc process type, discussed in Approval process types on page 107, should not be confused with the Ad Hoc override described here. Ad Hoc overrides allow specific approvers an option to alter a predetermined routing. In an Ad Hoc process, there is no predetermined routing, and the current approver must always select the next approver.
Validate approver
The Approval Server uses validate approver rules to protect against inappropriate Ad Hoc assignments. These rules allow testing of Ad Hoc approvers to make sure they are authorized within this process. If the test fails, then the user assigning this approver receives an error, and must correct it before the request can proceed. Next Approver rules are presented in the following diagram.
Guide for Users and Administrators Figure 7-3: Get next approver rules
Prep. Get Next Approver
Get Next Approver
Parameterized Get Next Approver
Ad hoc? No Yes
Invalid Submit Request
Validate Approver?
Valid Requester Self Check Not approved Signature line error
Approved Yes
(Wait for) Correction
Approver Response
More approvers?
Approved
Approval Cycle
No Process Done Completion Check Rejected
To summarize, Next Approver Rules determine the next approver or set of approvers for the request and create appropriate signature lines for them. The request is then prepared for the next approvers to respond.
Note: As Process Administrator, you should set up notifications to indicate when a request is waiting for an approver, and when an erroneous Ad Hoc selection is waiting for correction.
95
Approver responseSignature line

An approver has four valid responses to an approval request: hold, request more information, reject, and approve.
Hold
When an approver places a request on hold, the Approval Server identifies the approval request with a Hold status, but no other action occurs within the approval processing. Process Administrators should establish escalations to prevent requests in Hold status from being neglected indefinitely.
More information request

If an approver asks for more information, the approver sends a more information request to another user. The Approval Server identifies the approval request with a More Information status, but no other action occurs within the approval processing.
Figure 7-4: Approvers can pause and ask for more information
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.
Reject
If the approver rejects a request, the request moves to the Process Done stage, as described in Process done rules on page 105, unless you have created statistically-driven rules. No more routing occurs, and it is withdrawn from approvers who have it on hold or requested More Information. For more information, see Get authority on page 104.
Approve
When an approver approves a request, the Approval Server processes the request against the Routing Completion Check, discussed in the next section.
Statistical Decision-Making rulesDo you want to base your decision upon statistical data?
The default behavior of the Approval Server if you do not define any statistical override rules is that one rejected signature by an approver rejects the entire approval process and the process at that point is considered Done. But now you can specify two new rules to change this default behavior to support the following scenarios: Signature Accumulator rules help you collect information about the number of signature records that meet certain criteria that you define. For example, you can simply count the number of approved and rejected signatures. As you count, you can apply weightings or dollar amounts to each signature. After you have collected the information you need, you can use Statistical Override rules to approve or reject the request based on a ratio, or if the signatures have accumulated sufficient support or dollar amounts to warrant an approval or rejection. Weights and signature accumulator rules Imagine a large expense of $10,000 that cannot by approved or rejected by a single individual like Jack, but rather requires the accumulated weight of the signature authority of multiple individuals. If you were applying a weighting to signatures, you would actually use the Signature Accumulator rule as this rule is what collects information about the signatures. Information such as weighting would also be a part of the data-gathering role of the Signature Accumulator rule. The Statistical Override rule is more of a decision-making rule that bases the decision on the data collected by the Signature Accumulator rule.
97
These rules provide additional functionality to the Approval Server, but do not affect any existing functionality. These statistical rules start when the server receives an approval reject or cancel signal. If any Statistical Override rules are defined, then the statistical decision-making approval process begins. However, if no rules implement the Statistical Override rules, the server behavior reverts to its default logic, for example, one rejection and the process is Done. The entire statistical decision-making process is summarized next:
Figure 7-5: Statistical Decision-Making
Approver Response (Approval/ Rejection/ Cancellation)
Stat Override Rules? Yes
No
Default Logic
Signature Accumulator Statistical Override
Statistical Rules
Preempt?
No
More Signatures?
Yes
Yes Cancel Active Signatures
No Wait for more Signatures
Error
Reject
No
Approve?
Yes
Default Logic
Signature accumulator rule

The Signature Accumulator rule gathers data (or accumulates signatures) across the set of current signature records, which might or might not include all signature records associated with an approval process. Its function is to set up the data for the Statistical Override rule to use. To understand the Signature Accumulator rule, these two important terms must be defined: Current signature records. This is the set of signature records that are used during the Signature Accumulator rules. Not all signature records associated with a detail record necessarily apply. For example, with level approvals, you only want the signatures associated with the current level to be counted. If previous levels were approved, then the signatures for those levels are not included in the statistics. Active signature record. This is the signature record that the Approval Server is processing. This signature record has just been approved, rejected, or cancelled. the Approval Server behavior for this rule is to run all the Signature Accumulator rules per each signature. For example, if there are four signatures to check, the server looks at the first signature and runs all the Signature Accumulator rules you defined. The server then looks at the second signature and again runs all the Signature Accumulator rules, until all the signatures are finished. The data is typically a count of signature records in each state, for example, the number of current records in a Pending, Rejected, or Approved state. If you are using level approvals, only the signatures associated with the current level are counted. If previous levels were passed, they will not be included in the statistics. Signature records are applicable for the following process types:
Level Parent-Child, Rule based, Ad Hoc All signatures associated with the detail record at the current level are included in the set. All signatures associated with the detail record are included in the set.
Note: The Run If qualification of the Signature Accumulator
rule can be used to include or exclude signatures.
99
For each signature record, each Signature Accumulator rule is applied, provided the Run If qualification passes. 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. The rules are applied according the order of the rule (ascending). The Set Fields operation is used to set up the data. Typically the Set Fields operation in a Signature Accumulator 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 application-detail record that the Approval Server is processing. After all rules have been applied for the given signature, the Approval Server moves to the next signature and applies the rules accordingly. You can also use the Set Fields operation also to look up information from another form and pull values into the calculation. This might be applicable should you want to apply a weight to a particular approver. For example, a list of signatures might include one individual who has ultimate authority along with additional approvers who carry the same weight, when combined, as the one individual. You do not need to count the number of signature records in any given state. the Approval Server counts the number of signature records in Pending, Approved, Rejected, Hold, More Information, Cancelled, Error, and Closed states. These values are available for you to use with the Signature Accumulator and Statistical Override rules and are stored in the following hidden fields in the AP:Detail join form: Total Pending Total Approved Total Rejected Total Hold Total More Information Total Cancelled Total Error Total Closed
As a result, if you create an Statistical Override rule, you do not have to create a temporary field to store the value of the number of signatures. The totals are created and stored in the fields listed. For information about creating Signature Accumulator rules, see Working with Signature Accumulator rules on page 189.
Statistical override rule

The Statistical Override rule preempts (or overrides) the normal decisionmaking process on a request in the Approval Server. This rule evaluates the results of the data gathering of the active signature record in the Signature Accumulator rule. It determines whether the process should continue as approved, stop with a rejection, or do nothing, that is, rely upon the default behavior of waiting for all pending necessary signatures. In Statistical Override rules, the Run If condition specifies the rule to be evaluated, for example, check if 50% or more of the signatures have been approved:
$Total Signatures$ / $Total Approved$ >= .5
The Set Fields function then sets the result into the Statistical Override Field. The only valid Statistical Override values are either Approved or Rejected. When the Statistical Override rule approves or rejects the approval, the approval process is preempted by performing these actions:
Process type Level Signatures considered Only open signatures for the current level. All the signatures are considered at all times. All the signatures are considered at all times. All the signatures are considered at all times. Approving requests Preempts the Approval Server to proceed to the next level. Preempts the Approval Server to proceed to proceed to next parent. Preempts the Approval Server to approve the request. Preempts the Approval Server to proceed to the next set of approvers. Rejecting requests Preempts the Approval Server to reject the request and stop the processing. Preempts the Approval Server to reject the request and stop the processing. Preempts the Approval Server to reject the request and stop the processing. Preempts the Approval Server to reject the request and stop the processing.
Parent-Child
Ad Hoc
Rule-Based
101
If there are no Statistical Override rules defined for a process, then the default logic applies and Get Next Approver handling begins. This is very different from the situation where there are override rules defined, but they did not preempt the process.
Note: Each Statistical Override rule can perform one of three actions: Approve, Reject, or do nothing. If you Approve or Reject in an override rule, no further Statistical Override rules are considered. Processing of the override rules stops in the Approval Server at this point.
There also might be additional processing in the Approval Server if there are next approvers. If there are, new signature records might be generated. In most process types, this process is not marking the Detail portion of the approval process as being approved or rejected. Rather, this affects the way that the Approval Server processes the signature record and any other active signature records. It is only with a level-based process that you see the behavior where the detail record is not what is going to be updated immediately. For example, preempting other signatures with an approval decision in a level-based approval process will approve the request for the current level only; the Approval Server then seeks out further levels if they exist.
WARNING: If you define Statistical Override rules, you must define one rule to approve or reject the process if no pending signatures exist. If there are no more signatures to process, then the rules must either arrive at an Approve or Reject decision. If a rule is not defined to handle this condition, the Approval Server will consider this an error condition.
For information about creating Statistical Override rules, see Working with Statistical Override rules on page 193.
Routing completion checkWho is left?

The Completion Check determines whether conditions exist to stop routing a request to approvers who have not yet seen it. If a Completion check is successful, then routing stops, and no additional approvers will see the request. The request might not be ready for Process Done rules, but a completed request has been routed to everyone who must respond.
Completion rules overview
When Jack approves a business expense for $100, a Completion Check determines whether Jack has sufficient authority for that amount, for $100. If Jack can authorize that amount, the process passes the Completion Check. If Jack does not have such authority, then the Completion Check fails, and the routing of this request continues to another approver. Routing Completion check rules are shown in the following diagram.
Figure 7-6: Details of completion check rules
Submit Request
Requester Self Check
Requester not approved
Requester approved Yes No
Next Approver
Approver Response
More approvers? No
Signature Accumulator
Approval Cycle
Rejected Statistical Override? Completion Approved
Process Done
Yes No Outstanding signatures?
Yes Get Authority
Get Authority Regular
It is important to construct your processes such that the Approval Server does not run out of approvers before the Completion Check has routed the request to a person with sufficient authority. For example, if you have a process to handle expenses up to $1000, it is important that the Approver List includes an individual or role with sufficient authority to sign for that amount. Otherwise your process will generate an error when it runs out of approvers without finding someone who can authorize a $1000 expense.
103
However, some processes are designed to run out of approvers. 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.
Get authority
The Completion Check has Get Authority rules to collect information as discussed in Self Check rulesPreventing unnecessary routing on page 90.
Get authority regular rules

The Completion Check introduces Get Authority Regular rules. Get Authority Regular rules collect data only during the Completion check. Get Authority Regular 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. Routing Completion rules test whether a specific condition has been fulfilled. When the condition has been fulfilled, the Approval Server stops routing the request to new people. No CompletionIf Completion rules are not fulfilled, 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, then the process is done with a status of approved. If the Approval Success field is set to Completion Rule, then the process is done with an error state, because there are no more approvers and no Completion rule has succeeded. Successful CompletionIf Completion rules are fulfilled, the request is routed to no additional approvers. If there are outstanding signatures active when Completion rules are fulfilled, the request remains active until either all approvers approve or one rejects the request.
Example of routing completion check
Previously, authorizing a business lunch required a person with authority to approve a dollar amount. When Franks $150 lunch request arrives at Jacks desk, if Jack has authority for $150 then the process is complete. If Jack has authority for a lesser dollar amount, then the approval process does not pass the Completion Check until someone approves with authority for at least $150. This Get Authority rule tests completion against a specific condition of a dollar amount. Imagine a different process that ignores dollar amounts, and instead requires the sign off from two steps up the chain of command, so Frank needs both his manager Jack, plus Jacks manager Larry to approve Franks business lunch request. When Frank gets his two signatures, no more approvers are required, so the process is complete.
Process done rules

A process is done when a request has generated a final result, usually approved or rejected, but possibly a process error. Process Done rules allow a process to provide action on the original request when the Approval Server is done handling the request. For example, when a process is done you might want an operation to occur within the application that triggered the approval process, or you might want to have the AR System send a notification to the requester.
Chained processes
By chaining processes, you can initiate a new approval process automatically when the first is done. For example, if a manager approves a new computer purchase, the MIS department can start another chained approval process that determines the exact model of computer to buy.
Note: Process Administrators should make sure a chained process starts only when the first process returns an appropriate result.
105
Summary of common process elements

This completes the discussion of common elements of any approval process: Self Check Next Approver and Approver Response Statistical Decision-Making Completion Check Process Done You also learned about individuals versus roles and Ad Hoc routing. The following diagram displays all elements together.
Guide for Users and Administrators Figure 7-7: Common process elements
2
Prep. Get Next Approver
Get Next Approver
Parameterized Get Next Approver
Ad hoc? No Yes
Invalid Requester
Validate Approver?
Valid Submit Request Signature line error
1
Auto-Approval?
Approver Response No Get authority Yes Yes Get authority self Signature Accumulator No More approvers? (Wait for) Correction
Approval Cycle
Selfapproval? Statistical Override No No Yes
Rejected
5
Process Done
Yes
Approved Outstanding signatures? Get Authority
Yes
4
No Completion
Get Authority Regular
The next section shows how the Approval Server assembles these concepts into four process types, useful for various business practices.
Approval process types

The previous sections discuss the rules that determine specific decisions for routing an approval request. The following sections describe the types of approval processes that use these rules.
107
As you set up an approval process, you need a routing methodology that models your specific organization or processes. The situations in your organization are not all identical, and one process cannot cover all circumstances. Therefore the Approval Server offers three generic process types to model most circumstances, and a fourth process type lets you create custom rules for modeling scenarios outside the generic process types. The process type defines the model used to determine who gets the request after each person approves it. The four process types are Parent-Child, Level, Ad Hoc, and Rule-Based.
Parent-ChildProcess based on relationship

Do your approval requests travel a straight line, where each approver has a defined relationship to the next? This process is best implemented as ParentChild. An example of a Parent-Child process is a traditional management sign-off hierarchy, in which managers must approve workflow of the workers who report to them. Each manager (parent) has a direct fixed relationship to the worker (child) making a request. When multiple signatures are required, the managers become the child as they pass the approval to their managers. A Parent-Child process requires an approver to have a fixed relationship with the previous approver, and the next, if present. While not required, a manager-employee relationship is often the hierarchy represented with a Parent-Child approval process. A Parent-Child process Imagine that both marketing and engineering need to approve each product change. Using Parent-Child processes, there would be two parallel approval hierarchies, in which marketing approvers send the request to their marketing managers, and the engineering approvers send the request up the engineering chain of command.
Guide for Users and Administrators Figure 7-8: Parallel Parent-Child hierarchies
The important factor to notice is the hierarchical relationship between approvers. The Parent-Child process makes sure that persons X will never see this approval request. Persons X do not have parent relationships with anyone on the departmental hierarchies. This approval process consists of two Parent-Child hierarchies to illustrate flexibility. As a secondary benefit, the Approval Server can route a request simultaneously within both departmental hierarchies. Neither department has to delay until the other has finished routing the request. Whether in a single or parallel Parent-Child process, a rejection from any given approver could reject the request for everyone. Process Administrators should set up notifications to inform each hierarchy when a parallel hierarchy has rejected a request.
109
When you use a Parent-Child process for approval requests, be aware of the following considerations: A Parent-Child process expects a rule defining how to find the next approver. This rule must include the name of the field containing the identity of the parent record and return the Approver List, a string of individuals/roles. Working with Get Next Approver rules on page 168 provides more information about this type of rule and includes specific procedures. When an approver marks an approval request as approved, the Approval Server routes the request to the parent of that approver. There is no waiting for all approvals to be completed before forwarding the requisition to the next approver (based on the Get Next Approver rule). In generating the first Approver List for a Parent-Child process, the Approval Server assumes that the previous approver is the originator of the approval request. This means that the parent of the approval request originator becomes the first approver.
Level processRouting without approver relationships

Do your requests pass through individuals, committees, or departments that have no fixed relationship between themselves? The level type process works best for this kind of situation. Level process examples Imagine Frank wants to announce a new product at a New England trade show, and to do this he needs approval from any project manager and at least one division manager. Although Frank is in the West Coast Division, a Level process would permit any one project manager to approve, Wester, Central or Eastern. Likewise a Level process would pass the request to all three division managers for one to sign off. The order in which the approvers see the request is defined by level, and there is no requirement that Frank has a relationship with any approver.
Figure 7-9: Level process with two levels
In the second illustration, imagine that a request for a soft drink machine in a company courtyard must be approved by the refreshment committee, the landscape committee, and finally the maintenance committee.
Figure 7-10: Level process with three levels
None of the committees reports to another, nor are there any fixed relationships, but the order in which the committees see the request is defined by the Level process. A Level process does not dictate the number of approvers on each level, nor how many signatures must be gathered within a given level. You could set up a level consisting of one person, or many. The approvers for a given level can be made up of individuals or roles. You can set up routing to the next level to require only one approval, to require signatures from any number of individuals on a given level. Unlike Parent-Child, Level processes are not concerned with relationships. A Level process is concerned only with the order in which the approvals are generated. In a Level process, a request must be approved within each level before it passes to the next level, in order. A Level process uses a level value to indicate the position of individuals or roles. The value in the level field is used by the Approval Server to determine an approval sequence, starting with Level 0, with 1000 as the highest level. The Approval Server skips over any unused levels when it proceeds to a new level value.
111
When you use a Level process for approval requests, be aware of the following considerations: A Level process requires a rule defining how to find the next approver. This rule must return two values: a level indicator, and a string of individuals or roles. Working with Get Next Approver rules on page 168 provides additional information and specific procedures for defining this type of rule. The Process Administrator needs to set up rules to determine whether a request should appear to more than one person on a given level. For example, should the process ask all committee members to approve a request, or should the process route requests only to the executive council, or only to the chairperson alone?
Ad HocApprovers choose who is next

Are your approval demands so unpredictable that only the current approver can determine the correct routing path? In this case, use the Ad Hoc process instead of Ad Hoc override capability.
Guide for Users and Administrators Figure 7-11: Routing two requests in the same Ad Hoc process
An Ad Hoc process gives routing authority to each approver without requiring the Process Administrator to set permissions for every individual or role. Ad Hoc overrides are appropriate when specific people should have the option to route a request, overriding an otherwise fixed process. When you set up Ad Hoc processes, consider that Get Next Approver rules are not used by an Ad Hoc process. Individual approvers must enter the name of the next approver, if any. If you need to add another approver to any level, you can use the Parameterized Get Next Approver rule.
Note: Each approver in an Ad Hoc process must enter the exact AR System login ID of the next approver. Process Administrators can prevent errors due to typos if your BMC Remedy Administrator constructs menu lists containing the appropriate Ad Hoc approvers.
113
Custom Rule-BasedYour own routing

The first three process types, Parent-Child, Level, and Ad Hoc, are preconfigured process types. As such, they are relatively simple to implement. With the fourth type, called Rule-based process type, the process relies on your rules as the only method to determine where to start and how to move the approval request from one state to the next. When you use a Rule-based process for Approval Server, you need to define a complete set of rules to direct the actions of the Approval Server. A Rule-based process is similar to a Parent-Child process, except that a Rulebased process relies on rules to define the relationships between approvers, instead of an organizational hierarchy. This option is powerful and allows you to define a routing method of any type you would like. However, a Rule-based process requires more thought and work to implement and manage.
Summary of process types

The Approval Server handles approval requests with one of four processes, each with its own rules. The processes and rules are set up by you or someone you, the Process Administrator, designate.
Routing relationship between approvers? Parent-Child Yes. Fixed hierarchy. Used when routing up a management chain. No fixed relationship between approvers. Used when routing between committees or departments. How is next approver determined? Get Next Approver rule determines relationship of next approver to current owner. Get Next Approver rule determines the level of next approver. Approver Ad Hoc overrides available? Optional.
Level
Optional.
Ad Hoc
No. All routing determined by the current approver. Custom, as determined by the Process Administrator.
Parameterized Get Next Approver rule determines the level of next approver. Custom, as determined by the Process Administrator.
Not applicable.
Rule-based
Optional.
Notifications
Like other parts of the AR System, the Approval Server can use notifications to keep people informed when they need to respond to an approval request. Process Administrators can set up notifications to be sent at any step of an approval process, and to any individual or role. The following examples can help you identify notifications that are needed within your processes. When an approver needs to respond to a request. When an approver responds with an approval or rejection. When an approver has not responded to a request for a duration. When a requester needs to supply more information to an approver. When an error occurs. When an approval request is rejected after it has been approved by at least one person. When an approval request passes a certain step in the approval cycle. When an approver puts the request on hold. When the normal approval cycle has been overridden by an approver or the Process Administrator. When no action occurs for a certain duration. When a no action notification is ignored.
Notifications
115
AR System Approval Server offers the flexibility to notify people in the manner that suits your workflow. As Process Administrator you can configure Approval Server notifications to be delivered by email, by the AR System Alert client, or by the method set as the users default notification mechanism. Review these procedures for setting up approval notifications: Enable the events for which the Approval Server sends notifications using the form described in AP:Admin-ServerSettings on page 272. You must enable notifications on this form, or notifications are not sent regardless of the other Approval Server settings. Configure the Approval Server to send approver notifications using the procedure Using approval notifications on page 127. Configure the delay before escalations when no activity occurs using the procedure Use the Signature Escalations tabs to configure settings for actions and notifications when a signature line has been waiting too long without response. For example, you can set up a notification to be sent when a request has been outstanding for two days. on page 146. Configure notifications for More Information Requests using the procedure Entering more information escalations on page 148.
Chapter
Working with the Approval Server

This chapter describes the procedures that guide Process Administrators in setting up the Approval Server. The following topics are provided: Using the Approval Server Administration form (page 118) Setting up administrator capabilities (page 125) Using approval notifications (page 127) Configuring business times (page 136) Where to go next (page 138)
Working with the Approval Server
117
Using the Approval Server Administration form

The Administration form is the main form for managing and configuring the Approval Server. With this form, Process Administrators create or configure processes, rules, notifications, roles, forms, Process Administrators, or alternates. You can also configure the server settings and rename forms and processes from the Approval menu when the Administration form is displayed.
Note: To access the Administration form, you must be an Approval Server Process Administrator, or an AR System administrator. See Setting up administrator capabilities on page 125 for information about creating the first Process Administrator.
The following procedures demonstrate using the Approval Server Administration form for both BMC Remedy User and the browser. For the 7.0 release, the web view of the Administration application differs slightly in appearance from the BMC Remedy User view, but their functionality is identical. Nearly all the examples in this chapter show the Approval Server displayed in a browser.
To use BMC Remedy User

1 Log on to the appropriate AR System server. 2 Choose File > Open. 3 From the list of forms, select AP:Administration, and click New or Search.
The Administration form appears.
118 Chapter 8Working with the Approval Server
Guide for Users and Administrators Figure 8-1: Administration form (Remedy User)
4 Go to Using the Administration form on page 120.
To use a browser
1 Launch your browser and type in the administration URL for your Approval
Server. See your AR System Administrator for the exact administration URL of your Approval Server. For example, with a web server named acme that is accessing an AR System server named apex, the administration URL might appear as follows:
http://acme/arsys/apps/apex/ApprovalAdminWeb
2 Log in to the Approval Server.
The Administration application appears.
119
BMC Remedy Approval Server Figure 8-2: Administration form (browser)
3 Go to the next procedure, Using the Administration form.
Using the Administration form

The Administration form is the launch pad to create and modify the records that make up approval processes. The active tab determines the kind of information you manipulate when you click the buttons along the bottom of the form. Each tab controls a different Approval Server component.
To use the Administration form

1 To create a new Approval Server component, click the appropriate tab and
click Create. A blank version of the selected form appears.

2 To view or modify existing components, select a category tab. A list of the
selected components appears. Double-click one of the items on the list to display the form for that record.
3 To delete an existing component, click the appropriate tab and select the
record you want to delete. Click Delete and confirm your intention in the subsequent dialog box.
Note: For components other than Role and Form, you can first select a value in the Show For Process field. This limits the list of items displayed to those associated with the selected process.
Renaming a process or form

The Approval Server provides you with the ability to easily rename an existing process or form and all references to it within the Approval Server. This eliminates the need to manually track and update references when you change the name of a process or form.
To rename a process or form

1 Log on to the appropriate AR System server and open the Administration
form.
2 Click Rename in the navigation pane.
The AP:Admin-Rename dialog box appears.

Figure 8-3: Renaming a process and all attached workflow
3 From the Rename menu list, select Process to change a process name, or
Form to change a form name. Form renames only the form. Process renames the process, forms, and cross references.
4 Select an item to rename from the From Old Name menu list.
121
5 Enter a new name for the process or form in the To New Name field. Or select
a name from the menu list.

WARNING: If you renamed a process manually instead of using the Rename dialog box, the Rename command won't change names of attached rules. You must restore the process name manually and then rename the process to rename the attached rules.
6 From the Update menu list, select an update action for existing detail entries:
Selecting All updates both currently active and completed detail records. This option takes more time but will make sure that all detail records reference the new name. Selecting Only Active Objects updates only the currently active detail records. This setting applies to existing detail entries in the system. All structured definitions are changed for either setting.
7 Select the Including Object Itself check box to change the name of the object
as the first step of the rename action. By default, this check box is selected.
Note: If you have already manually changed the process or form name, you can clear this check box and only the Approval Server references are updated. Type the original name in the From Old Name field, and in the To New Name field, type the one you have already manually changed. However, this workaround does not update the attached rules.
8 Click Rename to execute the rename action.
Configuring the server settings

The Server Settings form lets you configure the Approval Server to generate a log file for debugging purposes, and lets you customize other settings of the Approval Server. See Defining an approval notification on page 129 for a description of the other tabs of the Server Settings form.
To configure the server settings

1 To configure server settings, display the Administration form and click
Server Settings in the navigation pane. The Server Settings form appears.
Figure 8-4: Server Settings form
2 Select the Approval Debug Mode check box if you want the Approval Server
to generate a log of approval activity. By default, this check box is selected. The log is a text file. For more information, see Approval server debug log on page 124.
3 If needed, enter a name or system path for the debug log file.
The Log File Name field contains the default file location and name. If needed, specify an alternate log file or location.
4 Type a number in the Definition Check Interval field.
This is the number of seconds before the Approval Server checks for changes to process definitions. The system default is 300 seconds. A larger number increases 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.
5 Type a number in the Private AR Server RPC Socket field.
123
This is the port of a dedicated private server to use when accessing the AR System server. Leave this field empty if you do not have a dedicated private server.
6 Type the path for the directory where web forms are stored in the Virtual
Web Document Directory field. Leave this field empty if you do not have the AR System mid tier installed for web-based approvals.
Approval server debug log

If you select the Approval Debug Mode check box, a log of approval activity is generated. A sample of the type of approval information gathered is shown next:
<APPR> Approval Server Trace Log -- ON (Fri Mar 17 2006 10:39:00.9700) <APPR> Configuration tag Approval-Log-File: updated successfully <APPR> Delete pending item -- 000000000000134 <APPR> Processing item number 1 (Fri Mar 17 2006 10:39:00.9860) <APPR> Initiated by -- Demo <APPR> Category -- Approval <APPR> Command -- Update-Config <APPR> Source Form -<APPR> Entry ID -<APPR> Tag -- Debug-mode: <APPR> Field ID 1 -- 0 <APPR> Field ID 2 -- 0 <APPR> Field ID 3 -- 0 <APPR> Other Short -<APPR> 65536 <APPR> Process an 'Update-Config' command <APPR> Configuration tag Debug-mode: updated successfully <APPR> Delete pending item -- 000000000000135 <APPR> Processing item number 2 (Fri Mar 17 2006 10:39:01.0170) <APPR> Initiated by -- Demo <APPR> Category -- Approval <APPR> Command -- Update-Config <APPR> Source Form -<APPR> Entry ID -<APPR> Tag -- Approval-Defn-Check-Interval: <APPR> Field ID 1 -- 0 <APPR> Field ID 2 -- 0 <APPR> Field ID 3 -- 0 <APPR> Other Short -<APPR>
Once the log is activated, logging starts immediately. By default, the log file is emptied and restarted when you restart the Approval Server or when you reactivate logging after it has been deactivated. Be aware that debugging can generate a large amount of information quickly.
Setting up administrator capabilities

Before you configure for approvals, you must use the approval Process Administrator form to identify the individuals who need administrator capabilities. Two types of Process Administrators are available: Full Admin has the ability to configure and modify processes, as well as the ability to approve or reject a request regardless of the normal process. Override Only Admin has the ability to approve or reject a request regardless of the normal process.
Note: The first Process Administrator must be set up with Full Admin capabilities by an AR System Administrator. Subsequent Process Administrators can be set up by this Process Administrator or by any subsequently defined full admin capable Process Administrator.
To set up administrator capabilities

1 Open the Administration form. See Using the Approval Server
Administration form on page 118 for the procedure.

2 Select the Administrator tab and click the Create button.
The Process Administrator Privileges form opens.
Setting up administrator capabilities
125
BMC Remedy Approval Server Figure 8-5: Creating a process administrator
3 Enter a valid user name in the Individual field.
Note: This user must be defined as a member of the group Approval Admin, ID 402, in the User form for this AR System server before the settings you make here will take effect.
4 Select Full Admin or Override Only Admin from the Authority menu list.
Full Admingrants this user the ability to modify processes as well as the ability to approve or reject a request regardless of the normal process. Override Only Admingrants this user the ability to approve or reject a request regardless of the normal process.
5 Select one of the four following options from the Notify Method menu list.
No MessageNo message is sent. AlertUsers are notified when they run BMC Remedy Alert. For more information about BMC Remedy Alert, see the Configuring guide.
EmailUsers are notified through 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, it is possible to send notifications to users not using the AR System, an alias for a group, or an email address representing a program. User DefaultUsers are notified using the default notification method defined in their User record. If the User record does not contain a default notification method, BMC Remedy Alert is used.
6 Select a Covering option.
Selecting All gives the individual administrative capabilities for all processes defined in the Process Definition form. If this is not what you want, select Specific Process and then select a process from the Process Name menu list.
7 Select Active from the Status field menu list.
The Status field allows you to disable administrator capabilities for a specific individual without the need to delete and re-enter information for the same individual should it be needed later. The ability to easily turn administrator capabilities on or off allows you to set up entries for individuals who might need administrator capabilities only on a temporary basis. For example, you can store information for an individual who periodically covers for an administrator.
8 Click Save.
Using approval notifications

Configuring the Approval Server to send notifications requires two steps. You must define which approval events can trigger notifications, and then define the notifications sent when an event occurs.
Defining the events to trigger notifications

Use the Notifications and Escalations tabs in the Server Settings form to determine which Approval Server activities are capable of triggering notifications and escalations. This form enables the notification and escalation settings for all other Approval Server forms.
127
WARNING: 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 to trigger notifications

1 Open the Administration form in either BMC Remedy User or a web client
as shown in Using the Approval Server Administration form on page 118.

2 Click Server Settings in the navigation tab.
The Server Settings form appears.

3 Click the Notifications tab.
Figure 8-6: Defining approval events that trigger notifications
4 Select the appropriate option button for each event.
Select Disabled if you never want the event to trigger a notification. Select Enabled for each event that needs to send a notification. Select Enabled Including Alternate if the event needs to trigger a notification for both the intended approver and any designated alternates.
5 Click the Escalations tab.
Guide for Users and Administrators Figure 8-7: Determine events that trigger escalations
Select the appropriate option buttons to determine which events trigger no escalation, an escalation for approvers, or an escalation for both approvers and alternates.
The events determined here are now able to trigger notifications and escalations using the Notification form.
Defining an approval notification

The form AP:Notification allows you to define who receives a notification, the notification message text, when the message is sent, and by what method. The Approval Notification form has four tabs: BasicFor basic descriptive information about the notification. EmailFor defining notifications that use email as their delivery mechanism. DetailsFor notification parameters, such as the method and priority of delivery, who receives the notification, and the text message. Administrative InformationFor displaying assignment, help text, and change history. Fields with bold headings on the Notification form are the required fields, others are optional.
Using approval notifications 129
To define an approval notification

1 Open the Administration form. 2 Click the Notification tab and click the Create button.
The Notification form appears.

Figure 8-8: Define the Basic tab of the notification
3 Enter a name in the Notification Name field.
Use a name that indicates the type of notification, such as New-Signature Notification.
4 Select the appropriate process from the Process Name menu list.
See Creating a process on page 140 if you have not set up any processes to select.
5 Click the appropriate notification Status.
The Status option allows you to temporarily enable or disable this notification without having to delete or reenter notification entries. See Defining the events to trigger notifications on page 127 to enable and disable which events trigger notifications for the entire process.
6 Select one of the following Notify On options from the menu list.
This option specifies the approval cycle event that triggers the notification.
Notify on event New signature Approve Reject Alternate approve Alternate reject Override approve Event that triggers Default notify list
When a new signature line is Approver list. added to the approval request. When the approval request is approved. When the approval request is rejected. When an alternate approves the approval request. When an alternate rejects the approval request. When a user with override capability approves the approval request. When a user with override capability rejects the approval request. When an administrator performs a global approve, terminating a process for a request. When an administrator performs a global reject, terminating a process for a request. Approver list minus current approver. Approver list minus current approver. Individual Approved for. Individual Approved for. Approver list.
Override reject
Approver list.
Global approve
Approver list.
Global reject
Approver list.
Reassign Error Cancel More info return
When an approval is reassigned Approver list. to a different approver. When there is an error in the approval signature. When an approval request is cancelled. When a request for more information is fulfilled. Individual who approved or rejected. Approver list. Individual who requested more information.
131
Notify on event
Event that triggers
Default notify list
Reject by later level When the approval request is Approver list. rejected after this signature has approved. Cancel at later level When the approval request is cancelled after this signature has approved. Reject by another approver Hold More info When the approval request is rejected by another signature record. When an approval request is put on hold. When more information is requested by an approver. Approver list.
Approver list.
Approver list minus current approver. Approver list minus current approver. Does not include requester.
Still active
When an approval request is in Approver list. an approval pending state and there has been no action. When a Still Active notification Approver list. has been sent and there is still no action. When an approval request is on Approver list. hold in the approval cycle and there has been no action. When a Still Pending notification has been sent and there is still no action. When a Hold notification has been sent, but there is still no action. Approver list.
Still active (repeat)
Still pending
Still pending (repeat) Still hold
Approver list.
Still hold (repeat)
When a Still Hold notification Approver list. has been sent, but there is still no action. When more information has been requested for a approval request and there has been no action. Approver list.
Still more info
Notify on event Still more info (repeat) Still error
Event that triggers
Default notify list
When a Still More Info Approver list. notification has been sent, but there is still no action. When an error in the approval Approver list. cycle has occurred, but there has been no action to correct the error. When a Still Error notification Approver list. has been sent, but there is still no action. When a change occurs that all past approvers should know about. Approver list.
Still error (repeat)
Change after approved
7 If applicable, enter an additional Qualification statement that will trigger the
notification. This allows you to define a trigger that is in addition to the Notify On condition.
8 Click the Details tab.
Figure 8-9: Determine the method and content of the notification
133
9 Select one of the following notification options for the Method field: None Alert Send no notification. Users are notified when they run BMC Remedy Alert. For more information about BMC Remedy Alert, see the BMC Remedy User online help. Users 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 MSExchange (Windows). When you use this option, it is possible to send notifications to users not using the AR System, an alias for a group, or an email address representing a program. Triggers a filter guide that fires on the required event and sends the notification.
Note: This functionality does not work out of the box. You must
Email
Workflow
add it to your application. For more information, see Enabling workflow-based notifications on page 235. User default Users are notified by the default notification method defined in their User record. If the User record does not contain a default notification method, BMC Remedy Alert is used.
10 Select a Priority for the notification from 0 to 10. This allows users to sort
their notifications in order of importance.

11 Select an option for the Send To field, which will indicate where the
notification is to be sent. Notifications are sent to users or roles, or the Approval Server can write to a form field.
Notify List Other Send to the default notify list for the selected Notify On option. Specify an individual, a group, a list of individuals, or groups, or a field reference to a field containing individuals or groups.
12 Enter a subject line for the notification message.
You can use the field list button to include field values in the subject line.
13 To attach additional field information to the notification, enter or select the
field names in the Additional Fields text box.

14 Enter a text message in the Message field.
You can use the field list button to include field values in the Message field.
15 For email or User Default notifications, click the Email tab.
You can use the Fields or Keywords menu list to enter a field or keyword. The fields in the Email tab are the same as those used when you create an Email or User Default mechanism in a Notify filter action. For further detailed information about these fields and using email notifications in general, see the information about messages and notifications in the BMC Remedy Email Engine Guide.
Figure 8-10: Defining email notifications
16 Enter the name of the mailbox that you want to handle the notifications if
you do not want to use the default mailbox. You can use a field or a keyword to substitute a mailbox name. This mailbox name should correspond to a valid mailbox configured in the AR System Email Mailbox Configuration form, or at the initial installation of the email engine.
17 Enter information in the From, Reply To, CC and BCC fields.
If you make multiple entries in these fields, separate the entries by hard returns. You can use the following entries in the fields: AR System user logins AR System groups
135
Direct email addresses Include the email domain name if you are entering a users name (for example, Joe.User@acme.com) or a keyword (for example, $USER$@acme.com). A field A keyword The order in which the entries appeared previously is the order in which the email engine does the search for addresses.
18 In the From field, enter the name to be displayed to indicate where the mail
is from.
19 In the Reply To field, if you enter a group name, a reply will be sent to all the
names in the group.

20 In the CC field, enter the names of people you want to receive copies of this
email notification.
21 In the BCC field, enter the names of people you want to receive copies of this
email notification but whose names you want hidden from the other recipients.
22 In the Organization field, enter a company name, an organization, a
keyword, or a field reference to a name that you would like to appear on the email.
23 In the Header, Content, and Footer fields, specify the names of the templates
to use for a header, footer, or content of the email notification.

24 Enter administrative information as needed. 25 Click Save to save your changes.
Configuring business times

The Approval Server uses the data in the business time forms for scheduling approval notifications. The following procedures demonstrate using these forms. For detailed information about using business time in the AR System, see the Configuring guide.
To configure business time workdays

1 Log on to the appropriate AR System server. 2 Choose File > Open.
3 Select Business Time Workdays and click New.
The Business Time Workdays form appears.

Figure 8-11: Business time workdays form
4 In the Schedule Name field, type in a new name. 5 (Optional) In the Offset Hours field, enter the amount of time to offset the
start time by. This field allows you to calculate business hours into the single 024 hour range that is required by the AR System server.
6 Click the Time Schedules tab. 7 Modify the start and end times, as appropriate for your company. 8 Click Save to save your changes.
To configure business time holidays

1 Log on to the appropriate AR System server. 2 Choose File > Open. 3 Select Business Time Holidays and click New.
The Business Time Holidays form appears.
Configuring business times
137
BMC Remedy Approval Server Figure 8-12: Business time holidays form
4 In the Schedule Name field, type in a new name. 5 In the Holidays field, enter the dates of the holidays observed by your
company. A date format is specified for your AR System server. Be certain to specify the date in the server format or the system might interpret the dates incorrectly.
Where to go next
Setting up Processes, Rules, and Roles are covered in separate chapters: Chapter 9, Defining an approval process Chapter 10, Defining approval rules Chapter 11, Managing users and roles
Chapter
Defining an approval process
This chapter describes the procedures to create and modify approval processes. The following topics are provided: Using the Process Definition form (page 140) Creating a process (page 140) Working with existing processes (page 149)
Defining an approval process
139
Using the Process Definition form

From the Administration form, you access the Process Definition form used to create and modify approval processes. This form contains multiple sections for defining the process: Process DefinitionFor basic information about the process, such as process name, application, type, and approval success criteria. Signature EscalationsFor scheduling notifications when approval requests are awaiting action. This section includes the following subsections: Normal Priority Notification, Urgent Priority Notification, and Low Priority Notification. More Information EscalationsFor scheduling notifications when an approval request is in the More Information state. Administrative InformationFor displaying assignment, help text, and change history.
Creating a process
This section describes how to create a process using the Process Definition form. 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 216. Use the following procedures to create an approval process. Each of the tabs on the Process Definition form is described in a separate procedure. You might not need to follow all of the procedures, depending on how you decide to define your approval process.
To create a process
1 Open the Administration form.
See Using the Approval Server Administration form on page 118 for the procedure.
2 Click the Process tab and click the Create button.
The Process Definition form appears.
140 Chapter 9Defining an approval process
Guide for Users and Administrators Figure 9-1: Process Definition formBasic tab
3 In the Process field, enter a name for the new process.
Process names must be unique and have no more than 254 characters (including spaces). It is helpful to make the name descriptive and indicative of the process function.
4 From the Form field menu list, select the AR System application workflow
that you are connecting to the Approval Server.

Note: Applications must be entered in the Form tab of AP:Form to be available in the Application list.
5 From the Type menu list, select a process type:
Parent-Child Level Ad Hoc Rule-Based For a description of the different types of processes, see Approval process types on page 107.
Creating a process 141
6 Select a process status from the Status menu list.
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.
7 From the Approval Success menu list, select a value.
The value in this field indicates how you want the Approval Server to determine the successful completion of the approval process. The options are:
No more approvers Use this value to indicate that the Approval Server should consider the approval process finished when all signature lines are complete. (A completion rule can also be used to end the process.) As a result, if the option is set to No More Approvers and if you cancel the signature line and there is no other signature, then the request is marked as Approved, not cancelled. Completion rule Use this value to indicate that the Approval Server should expect 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 will never complete.
8 Select a value for the If Multiple Approvers menu list.
This field applies only if you are defining an Ad Hoc process or are going to allow Ad Hoc overrides (see step 5 of this procedure for the process type selection). The value you select determines how many signature line records the Approval Server creates when building an approver list.
The options are:

One must sign Use this value to create a single signature-line record for a list of potential approvers. The signature-line is complete when one of the approvers acts on the requisition. The field for approver names on a signature-line record is limited to 255 characters. If you select this option, the list of approver names must fit within this limit. Using roles might help you to work around this limitation, if applicable. This option overrides the If Multiple Approver setting on any roles selected as an approver. All must sign Use this value to create a separate signature line for each approver on the approver list. If an approver list includes roles, the If Multiple Approver setting for the specific role determines whether the role is expanded into individual signature-line records for each member of the role or a single signature-line record is created for the entire role. See Defining roles on page 208 for more information about the If Multiple Approver setting for roles. Allow only one approver Use this value to create a single signature line for one individual. If you specify multiple names the Approval Server returns an error. 9 If you are using a parent-child, level, or rule-based type process, specify
whether to allow Ad Hoc additions to an approver list by selecting an option from the Allow Ad Hoc Next Approver list. The options are:
Anyone Approver No one Allows anyone to specify the next approver. This includes the requester and approver. Allows only the approver and not the submitter to specify the next approver. Prevents anyone from specifying an Ad Hoc approver.
Note: If you are creating an Ad Hoc process, the Allow Ad Hoc Next Approver field does not apply.
Creating a process
143
10 From the For Self Assignment field, specify 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 for someone else. The options are:
Use get next approver rules To use a Get Next Approver rule to determine the first approver.
Assign to owner if To use the requester as the first approver if the requester is approver defined as a valid approver within 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 owner To use the requester as the first approver in all cases.
11 From the Request Owner Field menu list, select the field identifying the
owner of the approval request.

12 From the First Approver field menu list, select the field identifying the first
approver. If the process is an Ad Hoc process or if you specified Anyone for the Allow Ad Hoc Next Approver, then you must specify a field to contain an initial approver value.
13 From the Validate Approvers menu list, choose Yes if an entry in your Next
Approver List field on the approval request must be verified at the time of entry with a Validate Approver rule.
14 From the Require Password list, choose Yes if approvers must enter their
password to save changes to an approval request.

15 From the Generate Preview list, choose if you want to see a preview list of all
approvers working on this request. For an example of generating a preview list of approvers with the Lunch Scheduler sample application, see Previewing approvers on page 218.
The options for previewing a list of approvers are:

None On Request Only No preview information is generated in the Preview Signatures form. Preview information is generated only when a GeneratePreview signal is received by the Approval Server. With this option, the application controls the load on the Approval Server. However, the preview displayed might not be the most current information. On Start of Process Preview information is generated under the following conditions: When a Generate-Preview signal is received by the Approval Server. When a new approval request is received, for example, a details request is created, or an existing request that has been closed is reopened. The preview displayed might not be the most current information. On Generation or Preview information is generated under the following Change to a conditions: Signature When a Generate-Preview signal is received by the Approval Server. When a new approval request is received, for example, a details request is created, or an existing request that has been closed is reopened. When a new signature is created, or when the status of an existing signature changes. The preview displayed might not be the most current information. Real-Time Only Preview information is generated on request but not stored when a preview is requested. This option displays the most current information; but you should be careful using this option since it puts the highest load on the Approval Server.
After you create your process, it automatically appears in the defined processes listed in the Administration form. For more information, see Using the Approval Server Administration form on page 118.
Creating a process
145
Use the Signature Escalations tabs to configure settings for actions and notifications when a signature line has been waiting too long without 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 levels (Normal, Urgent, or Low) of the Process Definition form.
To enter signature escalations

1 Open the Process Definition form if it is not already open.
See Creating a process on page 140 for the procedure to open this form.
2 Click the tab for the notification priority level on the Process Definition
form: Normal, Urgent, or Low.

Figure 9-2: Configure what happens when a request is not acted on
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.
3 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. See Configuring business times on page 136 for information about setting up business times.
4 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 Day from the Unit list.
b From the Changed State field, use the menu list to select the state that you
want to apply to the approval request. The options are Pending, Approved, or Rejected.
5 If you want 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.
6 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.
Creating a process
147
Entering 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 140 for the procedure to open this form.
2 Click the More Info Escalations tab of the Process Definition form.
Figure 9-3: More information escalations
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. See Configuring business times on page 136 for information about setting up business times.
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 Day 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 to save your process.
Working with existing processes

The following sections describe how to modify, delete or rename an existing process. See Creating a process on page 140 for information about specific field requirements.
Modifying processes
Follow these steps to modify an existing process.
To modify processes
2 Select the Process tab. 3 Double-click the process you want to modify or select the process and click
the View button. The Process Definition form appears (Figure 9-4 on page 150).
149
BMC Remedy Approval Server Figure 9-4: Modify individualProcess definition
4 Modify the appropriate process fields using field requirements described in
Creating a process on page 140.

5 Click Save to save your process.
Deleting processes
Follow these steps to delete an existing process.
Note: The delete operation is permanent and cannot be undone. When you delete a process, all of the associated rules are deactivated.
To delete processes
2 Select the Process tab.
3 Select the process you want to delete. 4 Click Delete.
A confirmation dialog box appears.

Figure 9-5: Confirm process deletion
5 Verify the name of the process and click Yes to delete this approval process.
The process is deleted and longer appears in the list of processes.
Renaming processes
Follow these steps to rename a process.
To rename processes
2 Click Rename in the navigation pane.
The Rename dialog box appears.

Figure 9-6: Renaming a process
151
3 From the Rename menu list, select Process to change a process name.
Renaming a process renames the process, forms, and cross-references.

4 Select the old process name from the menu list in the From Old Name field. 5 Enter a new process name or select one from the menu list in the To New
Name field.
6 From the Update menu list, select an update action for existing detail entries:
Selecting All updates both currently active and completed detail records. This option takes more time but will make sure that all detail records reference the new name. Selecting Only Active Objects updates only the currently active detail records. This setting applies to existing detail entries in the system. All structured definitions are changed for either setting.
7 Select the Including Object Itself check box to change the name of the object
as the first step of the rename action. By default, this check box is selected.
Note: If you have already manually changed the process or form name, you can clear this check box and only the Approval Server references are updated. Type the original name in the From Old Name field, and in the To New Name field, type the one you have already manually changed.
8 Click Rename to complete the action.
Chapter
10
Defining approval rules
This chapter describes how to create and modify approval rules. The following topics are provided: Using the Rule Definition form (page 154) Working with Auto-Approval rules (page 159) Working with Self-Approval rules (page 162) Working with Prep Get Next Approver rules (page 165) Working with Get Next Approver rules (page 168) Working with Parameterized Get Next Approver rules (page 174) Working with Get Authority rules (page 181) The value in this persons Signature Dollar Limit field from the Signature Authority form will be written to a temporary field named Temp Decimal 1. The value in the temporary field is then available for use by any SelfApproval or Completion rules. (page 183) Working with Get Authority Self rules (page 185) Working with Completion rules (page 187) Working with Signature Accumulator rules (page 189) Working with Statistical Override rules (page 193) Statistical Decision-Making approvals in a sample application (page 196) Working with Approval Process Done rules (page 201) Working with existing rules (page 203)
Defining approval rules
153
Using the Rule Definition form

The AP:Rule Definition form consists of three tabbed views (depending on the type of rule): BasicFor identifying information about the rule and, depending on the rule type, a qualification statement. Set FieldsFor specifying the action to be executed by the rule if a transaction passes the qualification statement. Administrative InformationFor reviewing assignment, help text, and change history.
Creating a rule
To create a new rule you need to open the Rule Definition form from the Administration form. Use the following procedure for opening the form.
To create a rule
2 Click the Rule tab and click the Create button.
The AP:Rule Definition form appears.
154 Chapter 10Defining approval rules
Guide for Users and Administrators Figure 10-1: New rule definition
3 Read the following sections covering the tabs found on this form, or proceed
directly to the appropriate procedure for the type of rule you want to define. Working with Auto-Approval rules on page 159 Working with Self-Approval rules on page 162 Working with Prep Get Next Approver rules on page 165 Working with Get Next Approver rules on page 168 Working with Parameterized Get Next Approver rules on page 174 Working with Get Authority rules on page 181 Working with Get Authority Regular rules on page 183 Working with Get Authority Self rules on page 185 Working with Completion rules on page 187 Working with Signature Accumulator rules on page 189 Working with Statistical Override rules on page 193 Working with Approval Process Done rules on page 201 Working with existing rules on page 203
155
Using the Basic tab on the Rule Definition form

The Basic tab on the Rule Definition form is for entering descriptive information about the rule, such as rule name, associated process name, and rule type. Depending on the rule type, you might use the Run If or Rule fields for entering a condition statement. In addition, you can use currency, date, and time fields in Run If and Rule qualifications. An example of the Basic tab for a Self Approval rule appears in Figure 10-2.
Figure 10-2: AP:Rule Definition formBasic tab
Using the Set Fields tab on the rule definition form

The Set Fields tab applies only to the following rule types: Get Authority Get Authority Self Get Authority Regular Prep Get Next Approver Get Next Approver Parameterized Get Next Approver Approval Process Done Validate Approver Signature Accumulator Rule Statistical Override Rule Use these rule types to evaluate field values from AR System forms. The Set Fields tab enables you to set field values on forms. In addition, assignments can also use: Currency, date, and time fields Currency functions like CURRCONVERT, CURRSETDATE, CURRSETTYPE, or CURRESETVAL Date functions like DATEDIFF, DATENAME, DATENUM, or DATEADD. The fields on this tab enable you to define the actions for the specific rule. For example, with a Get Authority rule, you can define a query to retrieve a signature authority amount from the AP-Sample:Signature Authority form and put it on another form.
157
Depending on the specific rule type, the Set Fields tab provides the following action assignment types:
Value Query Allows you to assign a value to a particular field. Allows the specification of a form (from the current or another server) and a qualification. You can assign the value of any field from the form. If there is no match for the qualification, a NULL value is assigned. If there are multiple matches, the value assigned depends on the If Multiple Rows setting on the Basic tab. Allows the specification of 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. Allows the specification of 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. Allows you to specify an AR System filter. See the Workflow Objects guide for more information about filters.
SQL
Process
Other
Example of the Set Fields tab

Figure 10-3 illustrates a query to the AP-Sample:Signature Authority form.
Figure 10-3: Set Fields with a query
This example illustrates the Query assignment type allowing you to define a query to another form to retrieve additional data.
Working with Auto-Approval rules

To allow for an auto-approval function within the approval request process, you must define one or more auto-approval rules. Auto-approval occurs when an approval request transaction passes any of the auto-approval rules. Creating auto-approval rules is optional. If you do not define any rules, no auto-approval occurs.
Note: Auto-Approval rules cannot use values retrieved from other forms, such as a persons authorization limit or job title. See Working with SelfApproval rules on page 162 for information about defining another type of rule that creates an automatic approval function. Self-Approval rules, in conjunction with Get Authority or Get Authority Self rules, can base approval on a value retrieved from another form.
159
Defining Auto-Approval rules

To create an auto-approval rule, use the following procedures. AutoApproval rule example on page 161 provides an example of a typical AutoApproval rule.
To define auto-approval rules

1 Open the Rule Definition form.
See Creating a rule on page 154 for the procedure.

2 Enter a name for the rule (or update the existing name if necessary) in the
Rule Name field.

3 Select a process name from the For Process field menu list.
This is the name of the process defined for your approval request workflow. All rules must be attached to a process to be active.
4 (Optional) Select a process instance ID.
A process instance ID is a unique GUID that identifies each process. This is especially useful if processes use the same name. All workflow that needs to see this process can now see the GUID and not just the name. You can now change process names as needed, without affecting underlying workflow.
5 Select Auto-Approval from the Rule Type field menu list.
As soon as you select a rule type, the Rule Definition form changes to display the fields appropriate for the specific type of rule. Fields that apply to the rule have a white field box. Fields that do not apply are gray.
6 Select a rule status from the Status field menu list.
Select either Active or Inactive in this field to indicate the status of the rule. While you are developing a set of rules for a process, it might be helpful to use the Inactive status and then later activate the rules when you have completed all the necessary rules.
7 Enter an execution order number in the Order field.
This number determines the sequence if you have two or more AutoApproval rules for a specific process.
8 Enter the rule condition in the Rule field text box.
You can type the condition statement or you can build it by using the qualification bar and list. For more information, see the Workflow Objects guide. When the qualification is met, the rule actions execute. The rule condition should test for a specific field value; for example, checking if the value for an Estimated Total field is less than $50.00. See the AutoApproval rule example that follows for a typical auto-approval rule.
9 Enter an Audit Text message, if applicable.
This is the message written to the audit diary field if the rule passes. If you do not enter a message, a default message is written to the audit log.
Auto-Approval rule example

Figure 10-4 illustrates a typical Auto-Approval rule.
Figure 10-4: Auto-Approval rule
In this example, the value in the approval request Total field is tested to see if it is less than $15. In addition, if this rule passes, the customized audit trail message, as shown in the Audit Text box, is written to the audit log.
161
Working with Self-Approval rules

The purpose of a Self-Approval rule is to define the criteria under which an approval request is approved, based on an attribute of the requester, such as signature authority. Self-approval is immediate and does not require any kind of authorization or validation function. It simply tests whether a designated approval request field meets specific criteria. A Self-Approval rule is different from an Auto-Approval rule in that SelfApproval rules can use values retrieved from another form. Self-Approval rules are generally designed to 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 be designed to retrieve the signature authority level for the requester and write that value to a temporary field on the approval request. This makes the signature authority value available for use by a SelfApproval rule. When an approval request meets the criteria in a Self-Approval rule, the Approval Server marks the transaction as approved. This action can then activate an Approval Process Done rule designed to change the status of the transaction to approved. To enable self-approval within your approval request process, you must define one or more Self-Approval rules. Self-approval occurs when an approval request transaction passes any of the Self-Approval rules. SelfApproval rules are optional, so if you do not define any rules, no selfapproval occurs.
Defining Self-Approval rules

To create a self-approval rule, use the following procedures. Self-Approval rule example on page 164 provides an example of a typical Self-Approval rule.
To define Self-Approval rules


Rule name field.
3 Select a process from the For Process field menu list.
This is the name of the process defined for your approval request workflow. All rules must be attached to a process to be active.
4 (Optional) Select a process instance ID. 5 Select Self-Approval from the Rule Type field menu list. 6 Select a rule status from the Status field menu list.
Select either Active or Inactive to indicate the status of the rule. While you are developing a set of rules for a process, it might be helpful to use the Inactive status and then later activate the rules when you have completed all the necessary rules.
7 Type an execution order number in the Order field.
This number determines the sequence if you have two or more Self-Approval rules for a specific process.
8 Type the rule condition in the Rule field text box.
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. The rule condition defines the criteria under which self-approval is allowed. Build a condition statement that tests for a specific field value. 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. The condition can reference any value of the current approval request record, including any values retrieved by the operations of a Get Authority Self rule. Self-Approval rule example on page 164 provides a look at a typical Self-Approval rule.
9 Enter an Audit Text message, if applicable.
Enter a message to be written to the audit trail log when this rule is used. This message 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 trail log.
Working with Self-Approval rules
163
Self-Approval rule example

An example of a Self-Approval rule is shown in Figure 10-5 on page 164. In this example, the rule condition is a statement comparing the value in the Estimated Total field with the value in a temporary field (Temp Decimal 1) and the value 200. The Estimated Total field is one of the fields on the sample approval request record. The value in the temporary field was retrieved from another form. For this Self-Approval rule to work, there must also be either a Get Authority Self or a Get Authority rule to retrieve the value for the temporary field. The temporary field value could be any appropriate comparative value. In the case of this example, the temporary field value is a signature authority value pulled from the AP:SignatureAuthority form.
Note: See Working with Get Authority rules on page 181 or Working with Get Authority Self rules on page 185 for the procedures on creating rules to retrieve values for temporary fields.
In addition to the rule condition action, this sample rule includes a customized audit trail message to be written to the audit log in the event that the rule passes.
Figure 10-5: Self-Approval rule
Working with Prep Get Next Approver rules

Before a process gets the next approver, it must prepare the next approver. Prep Get Next Approver rules gather information to be used in the Get Next Approver rules.
Defining Prep Get Next Approve rules

To create a Prep Get Next Approve rule, use the following procedures. Example of a Prep Get Next Approve rule on page 167 provides a look at a typical Prep Next Approve Rule.
To define Prep Get Next Approver rules


Rule Name field. Rule names must be unique. There is no enforced convention for specifying rule names, but it is helpful to make the name descriptive and indicative of the rule function. Names can be as many as 30 characters, including spaces.
3 Select the process name from the For Process menu list.
All rules must be attached to a process to be active.

4 (Optional) Select a process instance ID. 5 Select Prep Get Next Approver in the Rule Type field. 6 Select a rule status from the Status field menu list.
Select either Active or Inactive to indicate the status of the rule. While you are developing a set of rules for a process, it might be helpful to use the Inactive status and then later activate the rules when you have completed all the necessary rules.
7 Type an execution order number in the Order field.
This number determines the sequence if you have two or more Prep Next Approver rules.
165
8 Enter the rule condition in the Run If text box.
This is an optional step. Use this field for defining a conditional statement for the execution of the rule. You can type the conditional statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
9 Click the Set Fields tab. 10 Select a value from the Set Fields Type field menu list to indicate the Set Field
action assignment. See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
11 If appropriate, select a form name from the From Form field menu list.
This value indicates where the rule should search for a matching approver name to validate the user entry.
12 If appropriate, select a value from the On Server field menu list to indicate
the form resides on a different server.

Current Alternate Select to indicate the form resides on the current server. Select to indicate the form resides on a different server. You must indicate the server by typing its name in the Server field.
13 If appropriate, type the server name in the Server field. 14 Enter a qualification statement to test for a valid approver. 15 Click Save to save your changes.
Example of a Prep Get Next Approve rule

Figure 10-6 illustrates an example of a Prep Get Next Approver rule that gathers information used by a Rule-Based process. On the Basic tab for this example rule, there is no Run If statement. This means that the rule always runs; there is no condition that must be triggered. On the Set Fields tab for this rule, the Level field is incremented with the value of $Level$+1.
Figure 10-6: Example of a Prep Get Next Approver rule
167
Working with Get Next Approver rules

The purpose of the Get Next Approver rule is to obtain a list of approvers for an approval request. The number of signature-line records created for a specific approver list depends on the definition of the Get Next Approver rule: You can define the rule to create a single signature-line record for a list of one or more approvers. To complete the signature-line record, it only requires one of the approvers to act upon the approval request. You can define the rule to create a separate signature-line record for each individual in the list of approvers. This includes breaking down roles into individual users and creating separate signature-line records for these users, as well. A signature-line is considered complete when any approver on the signatureline record approves, rejects, or cancels the approval request. The four approval process typesParent-Child, Level, Ad Hoc, and RuleBasedhave slightly different requirements for Get Next Approver rules. Review the appropriate Working with topic that follows before continuing to Defining Get Next Approver rules on page 170.
Working with a Parent-Child process

With a Parent-Child process type, you must set up definitions for individuals or roles to include a field identifying the parent record. During the approval process, when an approver marks a request Approved, the Approval Server then automatically routes the approval request to the parent of the approver (usually the approvers manager). In this type of process, there is no waiting for all signature-line records to be completed before forwarding the approval request to the next approver (based on the Get Next Approver rule). When defining Get Next Approver rules for a Parent-Child process, be aware of the following considerations: While there are no special requirements for the qualification statement, it is assumed that the current approver is the key component of the qualification. The first approver list is built by assuming that the previous approver was the originator of the approval request.
For more information, see Parent-ChildProcess based on relationship on page 108.
Working with a Level process

In a Level-type approval process, individuals and roles are tied to the process with an additional level field. The level field 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.
Note: When the Approval Server creates a first approver list, it is assuming that the previous level was -1. Therefore, finding the first level means finding the level with the lowest number.
The Approval Server keeps track of the current approver level of each approval request as it goes through the approval cycle. When defining a Get Next Approver rule for a level process, be aware of the following considerations: 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. For more information, see Level processRouting without approver relationships on page 110.
Working with an Ad Hoc process

You cannot use an Ad Hoc process with the Get Next Approver rule type. An Ad Hoc process does not require any rules for creating an approver list because it is expected that users fill in the next level of approver at each case. If you want to define a process with rules that can be overridden on an Ad Hoc basis, the 7.0 release introduced the Parameterized Get Next Approver rule type that allows you to add another approver on any level, not only the current level.
169
For more information, see the following sections: Working with Parameterized Get Next Approver rules on page 174. Ad HocApprovers choose who is next on page 112.
Working with a Rule-Based process

In a Rule-Based process, rules define the relationships between individuals/ roles and the approval process. The Approval Server makes no assumptions regarding these relationships. It is up to you to design the appropriate rules to determine where to start and how to move from one phase of the approval process to the next. This requires solid familiarity with the Approval Server. Use the Next Approver Rule Is field, on the Rule Definition form, to define a set of rules that look at several different conditions, where each condition could add an approver to the current list of approvers. For more information, see Custom Rule-BasedYour own routing on page 114.
Defining Get Next Approver rules

To create a Get Next Approver rule, use the following procedures. Example of Get Next Approver rule on page 172 provides a look at a typical Get Next Approver rule.
To define Get Next Approver rules


Rule Name field.

3 Select the process name from the For Process menu list. 4 (Optional) Select a process instance ID. 5 Select Get Next Approver in the Rule Type field. 6 Select a rule status from the Status field menu list. 7 Type an execution order number in the Order field.
8 Select a value from the If Multiple Rows field menu list.
The following choices are available:

Value from first Values from all Return Error Clear Uses the value from the first record retrieved. Uses all of the values retrieved. Returns an error message if more than one record is retrieved. Leaves this field blank.
9 Select a value from the If Multiple Approvers field menu list.
This field value determines what occurs when more than one approver is returned by the Get Next Approver rule. The following choices are available:
One Must Sign A single signature-line 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. A separate signature-line record is created for each individual in the approver list, including individuals within a role. These require all of the approvers retrieved by the Get Next Approver rule to act upon the approval request. Leaves this field blank.
All Must Sign
Clear
10 Select a value from the Next Approver Rule Is field menu list.
The value in this field determines how retrieved data is treated, with regards to the current approver list, when there are multiple Get Next Approver rules. This field is generally used for a rule-based process that has a set of Get Next Approver rules for building an approver list. The following choices are available:
Additive Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, and further rules are to be processed. Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, but no further rules are to be processed. Select to indicate 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. Leaves this field blank.
Ending
Exclusive
Clear
171
This is an optional step. Use this field for defining a conditional statement for the execution of the rule. You can type the conditional statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. See Example of Get Next Approver rule on page 172 for an example of a rule condition.
12 Click the Set Fields tab on the Rules Definition form. 13 Select a value from the Set Fields Type field menu list to indicate the Set Field
14 Select a form name from the From Form field menu list.
15 Select a value from the On Server field menu list to indicate the form
location.
16 Enter a qualification statement to test for a valid approver. 17 Click Save to save the rule.
Example of Get Next Approver rule

Figure 10-7 on page 173 illustrates an example of a Get Next Approver rule for a Parent-Child process. On the Basic tab for this example rule, you can see that there is no Run If statement. This means that the rule always runs; there is no condition that must be triggered. The example rule instructs the Approval Server to take the approver records it finds and create a single signature-line record for the list of approvers. Only one approver action is required to consider the approval request complete. (See the settings for the If Multiple Rows and If Multiple Approvers fields.)
In addition, the Next Approver Rule Is field is set to Ending, meaning that no other Get Next Approver rules will be processed after this one. On the Set Fields tab for this rule, the current approver ($Approver$) has been defined as the person logged in and acting upon the requisition at the time this rule is evaluated (see the statement in the Qualification field). This person could be the approval request submitter or it could be an approver. Once this rule has identified the current approver, it determines that persons manager by locating a value in $Manager Login Name$ from the APSample:Signature Authority form and setting the value in the Next Approver field on the approval request record.
Figure 10-7: Example of a Get Next Approver rule
Determines number of signature lines records
173
Working with Parameterized Get Next Approver rules

The Parameterized Get Next Approver rule gives you the capability to add one more approver in an Ad Hoc manner at any stage in an approval process. For example, in a Parent-Child process, you might have the following chain of approvers:
1 Allan 2 Barbara 3 Chad 4 Debbie 5 Edward
At Stage 2, the Parameterized Get Next Approver rule lets approver Barbara decide Ad Hoc that approver Frieda needs to be included along with Debbie. You use the Parameterized Get Next Approver rule in combination with the Add-PGNA-Values command. This command is used by the application to provide the variable values for the Parameterized Get Next Approver rule type. (For more information, see Add-PGNA-Values on page 259.) The Parameterized Get Next Approver rule works exactly like 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. After the Get Next Approvers rules are executed, the server executes all Parameterized Get Next Approvers rules. If there are rules, but the current record does not have any parameters, then the rules will be skipped. For more information about different approval types, for example, ParentChild, Level, or Rule-Based processes, see Working with Get Next Approver rules on page 168.
Defining Parameterized Get Next Approver rules

To create a Parameterized Get Next Approver rule, use the following procedures. Defining Parameterized Get Next Approver rules on page 174 provides a look at a typical Parameterized Get Next Approver rule.
To define Parameterized Get Next Approver rules


Rule Name field.

3 Select the process name from the For Process menu list. 4 (Optional) Select a process instance ID. 5 Select Parameterized Get Next Approver in the Rule Type field. 6 Select a rule status from the Status field menu list. 7 Type an execution order number in the Order field. 8 Select a value from the If Multiple Results field menu list.
The following choices are available:

Value from first Values from all Return Error Clear Uses the value from the first record retrieved. Uses all of the values retrieved. Returns an error message if more than one record is retrieved. Leaves this field blank.
9 Select a value from the If Multiple Approvers field menu list.
This field value determines what occurs when more than one approver is returned by the Parameterized Get Next Approver rule. The following choices are available:
One Must Sign A single signature-line 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. A separate signature-line record is created for each individual in the approver list, including individuals within a role. These require all of the approvers retrieved by the Get Next Approver rule to act upon the approval request. Leaves this field blank.
All Must Sign
Clear
175
10 Select a value from the Next Approver Rule Is field menu list.
The value in this field determines how retrieved data is treated, with regards to the current approver list, when there are multiple Get Next Approver rules. This field is generally used for a rule-based process that has a set of Get Next Approver rules for building an approver list. The following choices are available:
Additive Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, and further rules are to be processed. Select to indicate that anything this rule assigns to the approver list is added to the existing approver list, but no further rules are to be processed. Select to indicate 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. Leaves this field blank.
Ending
Exclusive
Clear
11 Select Yes or No from the Guaranteed Add menu list.
This setting allows run-time variables to be part of the Run If qualification and Set Fields operations.
This is an optional step. Use this field for defining a conditional statement for the execution of the rule. You can type the conditional statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. See Defining Parameterized Get Next Approver rules on page 174 for an example of a rule condition.
13 Click the Set Fields tab on the Rules Definition form. 14 Select a value from the Set Fields Type field menu list to indicate the Set Field
location.
17 Enter a qualification statement to test for a valid approver. 18 Click Save to save the rule.
Example of Parameterized Get Next Approver rule

Figure 10-8 on page 178 illustrates an example of what happens at run time in the Approval Server when a Parameterized Get Next Approver rule is executed.
Step 1 The rule is defined with the following settings: Run If qualification Guaranteed Add Set Fields
$Level$ = %1 Yes $Next Approver$ = %2
Step 2 When user A creates an approval request, an entry is generated in the
AP:Details form (for example, 000000000000001). User A decides to add Frank Williams as an approver at a future level, for example, level 4.
Step 3 User A uses the Add-PGNA-Values command to send a signal to the
Approval Server, for example:

Add-PGNA-Values -t "00000000000001" -o "My Param Rule" -l "4/Frank Williams"
Step 4 The Approval Server receives this signal, and stores the data in the Param
Data field on the AP:Detail record.
177
Step 5 The next time the Approval Server executes the Get Next Approvers rules, it
also executes the Parameterized rules. While executing the parameterized rules, it retrieves the rules values from the Param Data field. It retrieves 4/ Frank? Williams and parses this into %1=4 and %2="Frank Williams.
Step 6 The Approval Server substitutes these values into the parameterized rules. Run If qualification Set Fields
$Level$ = 4 $Next Approver$ = Frank Williams
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, then the engine checks for the Guaranteed Add flag. If this is set to yes, then these rules will be executed now, even though the Run If condition is not satisfied. Since this is a standard rule type, it will also be executed when a preview is being generated, and so these Ad Hoc additions will be visible in previews as well.
Figure 10-8: Example of a Parameterized Get Next Approver rule
Working with Validate Approver rules

The 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, the APSample:Signature Authority form with 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.
Defining validate approver rules

To create a Validate Approver rule, use the procedures that follow. Example of a validate approver rule on page 180 provides a look at a typical Validate Approver rule.
WARNING: Approver names in Validate User rules are case sensitive. Make sure approver names are entered correctly or your users will be unable to approve requests that are assigned to them.
To define validate approver rules

1 Open the Rule Definitions form.

2 Enter a name for the rule in the Rule Name field. 3 Select the associated approval request process name from the For Process
field menu list.

4 (Optional) Select a process instance ID. 5 Select Validate Approver from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field. 8 Enter the rule condition in the Run If text box. 9 Click the Set Fields tab on the Rules Definition form.
Working with Validate Approver rules
179
10 Select a value in the Set Fields Type field to indicate the action assignment.
See Using the Set Fields tab on the rule definition form on page 157 for a description of the available choices.
11 Select a form name in the From Form field.
12 Select a value for the On Server field to indicate the form location. 13 Enter a qualification statement to test for a valid approver. 14 Click Save to save the rule.
Example of a validate approver rule

Figure 10-9 illustrates an example of a Validate Approver rule. On the Basic tab in this example, you can see that there is no Run If statement. This means that the rule always runs; there is no condition that must be triggered. On the Set Fields tab for this rule, a match for a name entered in the approver field ($Approver$) must be found in the Login Name field on the User form.
Figure 10-9: Validate Approver rule
Working with Get Authority rules

The Get Authority rule gathers information about the current approver or environment that is used by subsequent self-approval or completion rule tests.
Defining Get Authority rules

To create a Get Authority rule, use the following procedures. Example of a Get Authority rule on page 182 provides a look at a typical Get Authority rule.
To define Get Authority rules


Rule Name field.

3 Select the associated approval request process from the For Process field
menu list.
4 (Optional) Select a process instance ID. 5 Select Get Authority from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field. 8 Enter the rule condition in the Run If text box, if applicable.
Example of a Get Authority rule on page 182 provides an example.

9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type menu list.
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 157 for a description of the available choices.
This value indicates where the rule should search for the requested data; for example, the Signature Authority form.
Working with Get Authority rules
181
location.
13 Enter a qualification statement to define the parameters for retrieving the
authority data. For example, if you want to retrieve the current approvers signature authority limit, you would define a qualification statement that sets $Approver$ (current approver) to equal the Login Name (name of the person currently acting upon the approval request).
14 Enter the names of the fields to receive the data and the names of the fields
where the data is located. You can use the field list button to the right of each of these fields to select the appropriate field names.
Example of a Get Authority rule

Figure 10-10 on page 182 illustrates a typical Get Authority rule. In this example, the rule is defined to retrieve data about the person currently logged in and acting upon the requisition ('Login Name' = $Approver$).
Figure 10-10: Get Authority Rule example
The value in this persons Signature Dollar Limit field from the Signature Authority form will be written to a temporary field named Temp Decimal 1. The value in the temporary field is then available for use by any Self-Approval or Completion rules.
Working with Get Authority Regular rules

The Get Authority Regular rule gathers information about the current approver or environment that is used by subsequent completion rule tests.
Note: These rules are not run before self approval tests.
Defining Get Authority Regular rules

To create a Get Authority Regular rule, use the procedure that follows. Example of a Get Authority Regular rule on page 184 provides a look at a typical Get Authority Regular rule.
To define Get Authority Regular rules


Rule Name field.

3 Select the appropriate approval request process from the For Process field
menu list.
4 (Optional) Select a process instance ID. 5 Select Get Authority Regular from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable. 8 Enter the rule condition in the Run If text box, if applicable.
Working with Get Authority Regular rules
183
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute. The section Example of a Get Authority Regular rule on page 184 provides a look at a typical Get Authority Regular rule.
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type field menu list.
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 157 for a description of choices available.
This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form.
location.
Example of a Get Authority Regular rule

Figure 10-11 on page 185 illustrates a typical Get Authority Regular rule. In this example, the rule is defined to retrieve data for the person currently logged in and acting upon the requisition (LoginName = $Approver$). The value in this persons DollarSigningAmount field from the APSample:Signature Authority form will be placed in a temporary field named Temp Decimal 1.
The value in the temporary field is then available for use by Completion rules.
Figure 10-11: Get Authority Regular rule example
Working with Get Authority Self rules

The Get Authority Self rule gathers information about the current approver or environment that is used by subsequent self approval rule tests. Note that these rules are not run before completion tests.
Defining get authority self rules

To create a Get Authority Self rule, use the following procedures. Example of a Get Authority Self rule on page 187 provides a look at a typical Get Authority Self rule.

Rule Name field.
Working with Get Authority Self rules
185
menu list.
4 (Optional) Select a process instance ID. 5 Select Get Authority Self from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable. 8 Enter the rule condition in the Run If text box, if applicable.
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
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 157 for a description of available choices.
This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form.
location.
Example of a Get Authority Self rule

The following figure illustrates a typical Get Authority Self rule. In this example, the rule is defined to retrieve data for the person currently logged in and acting upon the approval request (LoginName = $Approver$). The value in this persons Signature Dollar Limit field will be placed in a temporary field. The value in the temporary field is then available for use by Self-Approval rules.
Figure 10-12: Get Authority Self rule example
Working with Completion rules

The purpose of a Completion rule is to determine when the approval process can be considered complete. For example, a Completion rule could be defined to compare the current approvers signature authority against the estimated total on the approval request.
Working with Completion rules
187
Completion rules usually are teamed with Get Authority or Get Authority Regular rules. The authority rules are used to retrieve information about an individuals or roles authority from other forms, such as signature limits, and to make it available for use by Completion rules.
Defining Completion rules

To create a Completion rule, use the following procedures. Example of a completion rule on page 188 provides a look at a typical Completion rule.
To define Completion rules


Rule Name field.

menu list.
4 (Optional) Select a process instance ID. 5 Select Completion Rule from the Rule Type field menu list.
As soon as you select a rule type, the Rule Definition form changes to display the fields appropriate for a Completion rule.
6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable.
Execution order applies to a set of Completion rules for a given process. If you are only defining a single Completion rule, the Order field might be left at zero.
8 Enter the rule condition in the Rule text box. 9 Click the Save button to save the basic information for the rule.
Example of a completion rule

The following figure illustrates a typical Completion rule. In this example, the condition statement compares the value in a temporary field with the values in the EstimatedTotal field on the approval request. If the condition passes, the approval process is considered complete.
In this instance, the temporary field (Temp Decimal 1) contains the current approvers signature limit, as retrieved by a Get Authority or Get Authority Regular rule. The estimated total of the approval request is being compared to this signature limit. You must define a Get Authority or a Get Authority Regular rule for the Completion rule to work correctly in this example.
Figure 10-13: Completion rule
Working with Signature Accumulator rules

The Signature Accumulator rule gathers data across the set of current signature records. The information, in this case, is typically a count of signature records in each state (for example, count the number of records in a Pending, Rejected, or Approved state). The rules run when a signature record is approved, rejected, or cancelled. This occurs when a user approves or rejects a signature; when an Application Command is used in a filter to cancel, reject or approve a signature; and when an Automatic Action is prescribed by the approval process definition. the Approval Server collects a set of current signature records and applies the Signature Accumulator Rules for the approval process to each record.
189
Note: The server automatically populates the Total fields with the number of signature records in Pending, Approved, Rejected, Hold, More Information, Cancelled, Error, and Closed states. These totals should covers the majority of the cases of administrators who want to implement statistical rules. However, you can define Signature Accumulator rules in those cases where a simple count does not suffice. Signature Accumulator rules are directly tied to the Statistical Override rules in that the override rules use the results of the accumulator rules. For more information, see Get authority on page 104.
Defining Signature Accumulator rules

To create a Signature Accumulator rule, use the following procedures. Example of a Signature Accumulator rule on page 191 provides a look at a typical Signature Accumulator rule. An integrated example of an Ad Hoc approval process using both statistical decision making rules with the Get Agreement form is found in Statistical Decision-Making approvals in a sample application on page 196.
To define Signature Accumulator rules


Rule Name field.

menu list.
4 (Optional) Select a process instance ID. 5 Select Signature Accumulator from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable. 8 Enter the rule condition in the Run If text box, if applicable.
The values used in the assignment might include static values, arithmetic operations, keywords, the results from functions, and values from the signature record, using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
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 157 for a description of available choices. If you select a Query type, select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form. If you select a Query or SQL type, select a value from the On Server field menu list to indicate the form location.
Example of a Signature Accumulator rule

In this example, there are five approvers. If three people approve the request, it is approved, but if two reject the request, it is rejected. Figure 10-12 on page 187 illustrates a typical Signature Accumulator rule. Here a Run If qualification is defined:
$Approval Status$ = Rejected
Here the server might be processing something that had already been changed. For example, if an approver has rejected the request, the Approval Server would apply the Set Fields operation. In this case, when one approver rejects the approval, it runs the rule for each signature line. If the server finds another rejection, the approval is rejected.
191
BMC Remedy Approval Server Figure 10-14: Signature Accumulator rule example
For each signature record, each Signature Accumulator rule is applied (provided the Run If qualification passes). After all rules have been applied for the given signature, the Approval Server moves to the next signature and applies the rules accordingly. Again, it is important to know that the Approval Server automatically provides counts for the current signatures in each state (for example, Total Pending, Total Approved, and so on). For this reason, you as the process author might be able to skip defining the Signature Accumulator rules altogether. You can use the Set Fields operation to also look up information from another form and pull values into the calculation. This might be applicable if you want to apply a weighting to a particular approver. For example, a list of signatures might include one individual who has ultimate authority along with additional approvers who carry the same weight, when combined, as the one individual.
Working with Statistical Override rules

The Statistical Override rule evaluates the results of the data gathering with the Signature Accumulator rule, and then it determines whether the process should continue as approved, stop with a rejection, or do nothing (that is, rely upon the default behavior of waiting for all needed signatures being approved).
Note: Although the Signature Accumulator and Statistical Override rules work in concert, the process author might be able to get by with just override rules. For more information, see Get authority on page 104.
Defining Statistical Override rules

To create a Statistical Override rule, use the following procedures. Example of a Statistical Override rule on page 195 provides a look at a typical Statistical Override rule. An integrated example of an Ad Hoc approval process using both statistical decision making rules with the Get Agreement form is found in Statistical Decision-Making approvals in a sample application on page 196.
To define Statistical Override rules


Rule Name field.

menu list.
4 (Optional) Select a process instance ID. 5 Select Statistical Override from the Rule Type field menu list. 6 Select a rule status from the Status field menu list. 7 Enter an execution order number in the Order field, if applicable.
The execution orders of the rules determine the order in which they are applied.
193
8 Enter the rule condition in the Run If text box, if applicable.
You can type the condition statement or you can build it by using the qualification bar and list, as described in the Workflow Objects guide. When the qualification is met, the rule actions execute.
When you select a Set Fields Type, Field Name becomes automatically filled in with Statistical Override. See Using the Set Fields tab on the rule definition form on page 157 for a description of available choices. If you select a Query type, select a form name from the From Form field menu list. This value indicates where the rule should search for the requested data; for example, the AP-Sample:Signature Authority form. If you select a Query or SQL type, select a value from the On Server field menu list to indicate the form location.
12 Type one of the following values into the Value field:
Approved Rejected You could also enter the corresponding integer index. If you enter any string value other than Approved or Rejected, you will not be able to save the rule. How the Statistical Override value for a particular request is derived might include static values, arithmetic operations, keywords, the results from functions, and values from the detail-signature record the Approval Server is processing from the AP:Detail-Signature form.
Example of a Statistical Override rule

In this example (created in tandem with the Signature Accumulator rule on page 191), there are five approvers. If two people reject the request, it is rejected. Otherwise, it is approved. Figure 10-12 on page 187 illustrates a typical Statistical Override rule. Here a Run If qualification is defined:
$Temp Integer 2$ > 1
The Run If qualification determines if a rule for a process applies. This means if more than one person rejects the request (every person rejecting the request increments $Temp Integer 2$ by one), the rule can now run the Set Fields operation. In our example, the Set Fields then sets a hidden display-only field (Statistical Override) on the AP:Detail form with a Rejected value. Here you could also set the Statistical Override field with field selection values like Approved. If more than two people reject the request, the approval is automatically rejected and the rest of the approval process is not run.
Figure 10-15: Statistical Override rule example
195
In our example, after the Statistical Override rule sets the Statistical Override field to Rejected, the following occurs: All applicable, pending signature records are cancelled. No further Statistical Override rules are processed.
Statistical Decision-Making approvals in a sample application

This section provides a sample of how statistical decision-making rules operate. It is a continuation of the Ad Hoc example approval process found in Chapter 6, Using a sample application. The statistical override rules have been set to inactive status, so by default they will not run. This is so that the original functionality being displayed by the sample does not change. If the user wants to see the statistical override rules work, you should change the state of these rules to Active, and then stop and restart the Approval Server.
1 From BMC Remedy User, log in to the appropriate AR System server as
sample user Frank Williams.

2 In BMC Remedy User, choose File > Open > All tab. 3 From the list of forms, choose Get Agreement, and click New. 4 In the The Get Agreement form, type I want to purchase a new laser
printer in the Summary field.
5 Type a longer description in the Details field.
For example, type A really nice new laser printer at Fry's costs
$600.
6 Type the names of three sample users in the Initial Approvers field.
Since this is an Ad Hoc process, every approver must be chosen manually. Use Jack Miller, Larry Goldstein, and Violet Anderson. Type a semicolon between each approvers name.
7 Click Save to save your request for a new computer.
With statistically-driven approvals, how an approver responds to a request enters a new phase in the approval process.
The signature accumulator rules have been designed to generate the total signature authority for all the approvals. One statistical override rule (Issue Statistical Approval) preempts the approval process to approve if it finds that the total signature authority is more than $500. The other statistical override rule (Issue Statistical Boundary Condition) checks to see if there are any more signatures open. If there are no more signatures open and the $500 signature authority was not reached, then this rule preempts the approval process to reject the request. This example shows in a very simple way how process administrators need to cover all possibilities while designing statistical override rules. In this example, the Approval Server behaves in the following manner: If the signature authority => $500, approve the request. If there are no more signatures open, reject the request. As shown in Figure 10-16, approvals are variously weighted in the APSample:Signature Authority form with the following Signature Dollar Limit values:
Figure 10-16: Dollar signature weights
197
For example, these users have the following signature authority: Jack Miller can approve requests for up to $100.00. Larry Goldstein can approve requests for up to $500.00. Violet Anderson can approve requests for up to $2000.00. The quickest way to understand how statistically-driven approvals work is to see Franks request in the AP:Detail-Signature form. (However, you could also individually approve Franks request in Approval Central as, respectively, Jack Miller, Larry Goldstein, and Violet Anderson to see the effects of the statistical rules.)
8 From BMC Remedy User, log in to the appropriate AR System server as
sample user Demo.

9 In BMC Remedy User, choose File > Open > All tab. 10 From the list of forms, choose AP:Detail-Signature, and click Search. 11 Click Search to see the list of pending approver signatures.
The approval is pending for Jack Miller, Larry Goldstein, and Violet Anderson.
12 To see how these signatures are weighted, approve the signature for Jack
Miller, save the request, then press F5 to refresh the query. Because Jacks signature authority is weighted at $100, the approval is still pending for either Larry and Violets signatures to meet the $500 qualification, as shown next. As a result, if either Larry or Violet approve the request, Franks approval is done.
Guide for Users and Administrators Figure 10-17: Dollar signature weights
On the other hand, Violets signature authority was weighted so that she could have simply approved Franks request outright without needing either Larry or Jacks approval.
Statistical decision making rules in the Get Agreement sample

This section describes the underlying workflow used in Statistical DecisionMaking approvals in a sample application on page 196. For the 5.1 release, two signature accumulator rules and two statistical override rules were added to demonstrate statistical decision making in the Approval Server, in addition to the implicit rules. Issue Retrieve Signature Limit (Signature Accumulator rule). The rules run in the following order:
Step 1 Issue Retrieve Signature Limit (Signature Accumulator rule) Step 2 Issue Increment Signature Limit (Signature Accumulator rule) Step 3 Issue Statistical Approval (Statistical Override rule) Step 4 Issue Statistical Boundary Condition (Statistical Override rule)
199
Signature accumulator rules

In the sample application, the two signature accumulator rules are used to accumulate information regarding the currently open signatures: The Issue Retrieve Signature Limit rule picks up the Signature Authority ($Signature Dollar Limit$) and places it in a temporary field (Temp Decimal 1). For this rule, the Set Fields qualification used is:
'Login Name' = $Approvers$
This qualification has to be chosen carefully because the selection list contains fields from multiple forms. The $Approvers$ field must be from the AP:Signature form. The Issue Increment Signature Limit rule maintains a total of all the signature authorities. The Run If condition runs these rules if a user approves a request:
$Approval Status$ = "Approved"
This condition is qualified against all the open signatures. (By running it on the three-way application - detail - signature join form). You should verify that this condition works on the fields from the AP:Signature form. The example uses a process to approve a request after the weight of the approvals exceeds $500. This weight can be picked up from another form (in this case AP:Signature Authority).
Statistical Override rules

In the sample application, the Statistical Override rules are used to make a preemptive decision regarding a request. Statistical Override rules can use the data set up by the Signature Accumulator rules to reach this decision. The Run If condition runs the Issue Statistical Approval rule if the request exceeds $500. Because the request must be greater than and not simply equal $500, Larry Goldsteins signature amount is not enough for him to approve the request by himself. Another example of a Run If condition that might be helpful to many customers would be to check if 50% 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. The only field that can be set in a Statistical Accumulator rule is the Statistical Override field. The only values for this field are Approved or Rejected. You can provide these values directly or use an expression that evaluates to these values. Any value other than these Approved or Rejected results in an error state indicated on the Detail request. The sample also includes the Issue Statistical Boundary Condition rule which checks for any pending signatures. The Run If condition checks if the server needs to wait for any more responses. If the state is anything other than Pending, More Information, or Hold, the request is considered Done. If the Approval Server is not waiting for any responses, the Statistical Override field is set to Rejected.
Working with Approval Process Done rules

Approval Process Done rules define the actions taken when the approval process is finished. The approval process is considered finished when an approval request is approved and passes a Completion rule or if it is rejected, cancelled, or has an approval error. Often, the Approval Process Done rules are used to change the state of the approval request. For example, one Approval Process Done rule is defined to change the state of the approval request to Approved and another Approval Process Done rule is defined to change the state of the approval request to Rejected. When an approver marks an approval request detail record as either approved or rejected, the approval request state does not change until an Approval Process Done rule is executed. This also applies to approval requests that are cancelled or end in an error.
Defining Approval Process Done rules

To create an Approval Process Done rule, use the following procedure. Example of an Approval Process Done rule on page 202 provides a look at a typical Approval Process Done rule.
To define Approval Process Done rules

Working with Approval Process Done rules
201
Rule Name field.

menu list.
4 (Optional) Select a process instance ID. 5 Select Approval Process Done from the Rule Type field menu list. 6 Select a rule status in the Status field. 7 Type an execution order number in the Order field. 8 Select one or more rule conditions from among the radio buttons: Approved,
Rejected, Cancelled, or Error. The rule executes when the approval detail record is put in the selected state.
9 Click the Set Fields tab on the AP:Rules Definition form. 10 Select a value from the Set Field Type menu list.
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 157 for a description of the available values.
11 Type the appropriate Field Name and Value to change the status of the
approval request.
12 Click Save to save the rule.
Example of an Approval Process Done rule

Figure 10-18 on page 203 illustrates a typical Approval Process Done rule. In this example, the Approval Process Done rule activates when an approver marks the approval request detail record Approved. The resulting action for this rule is that the StateValue is changed to 40 (Approved).
Guide for Users and Administrators Figure 10-18: Approval process done
Rule trigger
Rule assignment action
Working with existing rules

The following sections describe how to view, modify, and delete existing approval rules. See the sections on specific rule types for detailed information about the field requirements for specific rules.
Viewing rule stages

The Rules tab in the Administration form includes a process diagram of the approval process that shows you how the approval process is performed, and at each stage which rules are executed. With this diagram, users can see which rules execute at each stage by clicking the rule buttons. For example, if you click on Get Authority button in the process diagram, all the other rules are filtered out so that only the Get Authority rules will be shown in the Rule tab. But if you click any other part of the diagram that is not a rule button, then all the rules for the process reappear.
203
To view rule stages.

1 Click the Rule tab on the Administration form. 2 In the Show For Process, select a process or leave the field blank.
If you leave the field blank, all the rules for all processes will be displayed when you click the Rule tab.
3 Scroll down the page to view the process diagram.
Figure 10-19: Approval process diagramRules tab
4 Click a rule link in the process diagram to view the rules that execute in the
process. In this example, the Show For Process field was left blank, so that all the processes defined in the system appear in the Rules tab. If you clicked the Next Approver rule link, the Rules tab in the Administration window redisplays so that only the Get Next Approver rules appear, as shown in Figure 10-20. You can now easily modify only the Get Next Approver rules.
Guide for Users and Administrators Figure 10-20: Rules redisplayed after clicking Rule button
5 Click Show All to redisplay all the available rules. You can also click an empty
space in the process diagram. All the rules for the selected process (or processes) will reappear in the Rules tab.
Modifying rules
Follow these steps to modify an existing rule.
To modify rules
1 Select the Rule tab on the Administration form and click the Refresh button. 2 If needed, filter the rules displayed by clicking a rule button in the process
diagram.
3 Double-click a rule or select a rule and click the View button.
The rule appears in a Rule Definition window and the current values for the rule are shown.
205
4 Modify the appropriate rule fields by using the procedures described under
the specific rule type topics.

Deleting rules
Follow these steps to delete an existing rule.
Note: The delete operation is permanent and cannot be undone.
Be aware of any rule dependencies before deleting a rule. For example, SelfApproval and Completion rules might depend on a Get Authority, Get Authority Regular, or Get Authority Self rule. If the Get Authority (Self and Regular) rule is deleted, the dependent rule will no longer function as designed. To delete rules
1 Follow steps 1, 2, and 3 of Modifying rules on page 205 to display a list of
rules.
2 Click the rule you want to delete. 3 Click the Delete button.
The rule is deleted and will no longer appear in the list of rules.
Chapter
11
Managing users and roles
This chapter describes how to define user capabilities and roles for use by the Approval Server in the approval process. The following topics are provided: Defining roles (page 208) Defining alternate approvers (page 209) Assigning process override capability (page 211)
Managing users and roles
207
Defining roles
The following procedure takes you step by step through the fields on the AP:Role form.
To define roles
1 Click the Role tab on the Administration form and click Create.
Note: See Using the Approval Server Administration form on page 118 to learn how to use the Administration form.
The AP:Role form appears.

Figure 11-1: AP:Role form
2 Enter a Role Name in the Role Name field.
The name should be descriptive of a job or a responsibility. For example, MIS Management would be more descriptive than just Managers (unless you wanted to create a role that was inclusive of all managers in your company).
3 Select an option from the If Multiple Approvers field menu list.
208 Chapter 11Managing users and roles
The option you select determines how many signature line records the Approval Server creates for the role when building an Approver List. The options follow.
One must sign Use 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. 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 action. See Creating a process on page 140 for more information about the If Multiple Approver setting for processes.
All must sign
Note: If you include a role on the member list of another role, the If Multiple Approvers option of the parent role, in some cases, takes precedence. For example, if 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, which is defined with If Multiple Approvers set to One must sign, the settings for Role B are the ones used by the Approval Server.
4 Select a value from the Status field menu list.
Select either Active or Inactive.

5 Type the names of individuals or roles to the Member List.
Type valid user names or roles in the Member List box, separating 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.
6 Click the Save button to save the record.
Defining alternate approvers

Use the procedure that follows to define an alternate using the Alternate Approver form.
Note: Alternates must be licensed with change permissions. You should not make an alternate of an individual who does not have this capability.
Defining alternate approvers
209
To define alternate approvers

1 Click the Alternate tab on the Administration form and then click Create.
The Alternate Approver form appears.

Figure 11-2: Defining an alternate
2 Enter this alternates name in the Alternate field.
The name must be a valid user name.

3 Verify the user name in the For field.
This name defaults to the name of the current user, but it can be changed to another name if you have the appropriate system capabilities, such as full process administrator or AR System administrator.
4 Type a date in the Start Date field.
Type a valid date or select a date from the date/time button.

5 Type an End Date.
Type a valid date or select a date from the date/time button.

6 Select a value from the Notify Alternate field menu list.
Select either Yes or No. If you select Yes, a notification is sent to both the person identified and to anyone designated as an alternate for that person.
7 Select one of the Covering option buttons. All Specific Process Use this option to authorize a user as alternate for all the processes of the person indicated in the For field. Use this option to authorize a user as alternate for one specific process. The Process field becomes enabled so you can specify which process this alternate is authorized for. If this person is to be alternate for more than one process, you must create a separate alternate record to authorize each process. 8 Click Save to save the Alternate information.
Assigning process override capability

Use the procedure that follows to assign process administrator override capabilities using the Process Administrator Privileges form.
To assign process override capability

1 Open the Administration form and click the Administrator tab. 2 Click Create.
The Process Administrator Privileges form appears.

Figure 11-3: Assigning override authority
Assigning process override capability
211
3 Enter a valid user name in the Individual field. 4 Select Override Only Admin from the Authority field menu list. 5 Select an option from the Notify Method field menu list.
This selection indicates how messages are to be sent to the designated person. Select one of the following options:
None Alert No message is sent. Specified users are notified when they run AR System Alert. For more information about the AR System Alert, see the BMC Remedy User online help. Specified users are notified using email. The specified users are notified using the default notification method defined in the User record. If the User record does not contain a default notification method, the Notification Tool is used.
Email User default
6 Click one of the Covering option buttons. All Specific process Use this option button to authorize a user as alternate for all the processes of the person indicated in the For field. Use this option button to authorize a user as alternate for one specific process. The Process field becomes enabled so you can specify which process this alternate is authorized for. If this person is to be alternate for more than one process, you must create a separate alternate record to authorize each process. 7 Select a value from the Status field menu list.
Select either Active or Inactive.

8 Click the Save button to save the record.
Chapter
12
Implementing sample application features

This chapter highlights features, in the sample application Lunch Scheduler, that you can use in your own approval processes. The following topics are provided: Overview of the Lunch Scheduler application (page 214) Key forms (page 215) Sample process descriptions (page 216) Chaining approval processes (page 221) Restarting an approval process (page 222) Special techniques (page 223) Sample users (page 226)
Implementing sample application features
213
Overview of the Lunch Scheduler application

The Lunch Scheduler application is designed to schedule customer lunches for employees of an imaginary company.
Figure 12-1: Lunch Scheduler application
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 some information about the customer and the customers current state with the company. When a request is entered, it is routed for approval. Lunch Scheduler includes three different approval processes chained together and uses three different filters with Run Process commands to start the processes: Management Cost Authorization is a managerial approval based on the total cost of the lunch. The request is routed along the management chain until a manager with sufficient dollar authority approves. The APSample:Start Cost Approval filter uses the following Run Process command: Application-Command Approval New-Details -t "Management Cost Authorization".
214 Chapter 12Implementing sample application features
Major Account Level Approval is a review by the major and enterprise account teams if the account is a major or enterprise account. The APSample:Start Level Approval filter uses the following Run Process command: Application-Command Approval New-Details -s "$SCHEMA$" -e "$Request ID$" -t "Major Account Level Approval". Special Overdue Approval is a special review if the account is currently overdue. The company has decided that taking a customer to lunch who is currently overdue needs special permission. The AP-Sample:Start Overdue Approv filter uses the following Run Process command:
Application-Command Approval New-Details -t "Special Overdue Approval".
Requests are submitted, go through the appropriate approval processes enforcing the business rules of the companyand when approved, provide a record of the business lunch activity at the company.
Key forms
This section lists the major forms associated with the Lunch Scheduler application.
Note: You must run arjoinfix (UNIX) or ARJOINFIX.EXE (Windows) on all forms you create for use with the Approval Server. This executable modifies the join qualifications to make sure your applications communicate properly with the Approval Server when you have more than one application requiring approvals.
AP-Sample:Lunch Scheduler This is the base form of the application. It is the form that the lunch requests are entered into and the form that approvals are tied to. AP-Sample:Lunch-Detail This is the inner join between the AP-Sample:Lunch Scheduler and the AP:Detail forms. This inner join is used for internal processing within the Approval Server and for Global Override operations. The join criteria is Request ID to Request.
Key forms
215
AP-Sample:Lunch-Detail-Signatu This is the inner join between the AP-Sample:Lunch Scheduler and the AP:Detail-Signature forms. This is the main working form for approvers who are approving lunch requests. The join criteria is Request ID to Request. AP-Sample:Company This is a supporting form where companies and information about them is entered. The data here drives menus and settings about the companies. AP-Sample:Restaurant This is a supporting form where restaurants and information about them is entered. The data here drives menus and settings about the restaurants. AP-Sample:Signature Authority This is a supporting form where approvers and information about them is entered. Information about managers is used to drive advancement along the management chain. Information about their signature authority determines when someone has sufficient authority to be the last person needing to sign. Account Approval Level indicates whether someone is on the major or enterprise account team and involved in the second stage approval process.
Sample process descriptions

Approving Lunch Scheduler requests requires three separate approval processes. They are designed to run serially, and the latter two run conditionally, only if required for a particular request. This section discusses each processes as a stand-alone approval process. The next section presents how to initiate the processes and how the application has been set up to allow the processes to communicate among themselves.
Management cost authorization

This approval process runs first and acts on every request. This process is an example of the Parent-Child process type, with Auto Approval and Self Approval rules. If requesters do not have authority, then the approval process routes requests to their managers as identified in the Sample Signature Authority form. The system continues to route 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 Management Cost Authorization process is launched by the filter APSample:Start Cost Approval. The command within the filter is shown here:
Application-Command Approval New-Details -t "Management Cost Authorization"
The tag argument identifies the process to run. See New-Details on page 261 for more information about this Approval Server command.
Major account level approval

This approval process runs if the company lunch is with a major or enterprise account. This is an example of the level type of approval process. A Completion rule is used to stop lunch requests for major accounts from advancing beyond the first level. Only enterprise accounts need to go to both the major account and enterprise account levels. The Account Type menu list identifies the account as a major or enterprise account. The Major Account Level Approval process is launched by the filter APSample:Start Level Approval. The Run If filter criteria must be met for this filter to execute.
Special overdue approval

This approval process runs only if the company currently has an overdue account. This is an example of a rule-based process type. This process does not have a standard style, instead it enforces the way in which approval is performed with a custom style and criteria. This process includes an example of Prep Get Next Approver rules used to set up the Get Next Approver processing.
217
The Account Overdue check box on the AP-Sample:Company form determines if the account is overdue. The Special Overdue Approval process is launched by the filter APSample:Start Overdue Approv. The Run If filter criteria must be met for this filter to execute.
Previewing approvers
You can use the AP:PreviewInfo vendor form to view the completed and remaining approvals. The AP:PreviewInfo form takes the Process Name, Request ID, and Retrieval Type as input values. There are three retrieval types: FullShows completed and future approvals. RemainingShows only pending approvals. CompletedShows only approval requests which are already approved. As shown in Figure 12-2, the preview list includes the status of the signatures. Finally, you can configure the approval process to view past, current, and future approvals.
Figure 12-2: Preview information list
You can also create a display-only form that displays the preview information and executes the parameterized rules. The following example gives you a glimpse of the parameterized rules and approval preview in use.
To preview a list of approval processes

1 In BMC Remedy Administrator, open the Server Information window and
then click the Server Ports and Queues tab.

2 Create a private type server queue and save your changes.
Note: You cannot create a private server queue unless your server is licensed.
Remember the RPC program number you entered. You use it in the ar.cfg or ar.conf file.
3 Open the ar.cfg or ar.conf file in a text editor. 4 Add the following line to the file and save your changes.
Plugin-Loopback-RPC-Socket: <RPC_program_number> Approval-RPC-Socket: <RPC_program_number>
5 Stop and then restart the AR System server. 6 In BMC Remedy User, open the AP:Administration form. 7 Refresh the Process table field to see all available processes, as shown in
Figure 12-3.
Figure 12-3: Available processes
8 Click View to open one of the processes that are attached to the AP-
Sample:Lunch Scheduler form, for example, Major Account Level Approval. The Process Definition form opens.
9 In the Generate Preview field, select one of the options, for example, On
Generation or Change to a Signature.
For more information, see Creating a process on page 140.
219
10 Save your changes. 11 On a front-end form that you want to use to view approvers, create a table
field that queries the AP:PreviewInfo form. For example, Figure 12-4 illustrates a form that queries entries that require approvals in the AP-Sample:Lunch Scheduler form.
Figure 12-4: Parameterized Rule Test form
If you click an entry that is pending approval, the entry is opened in the AP:Signature form. Approvers can accept or reject the approval as needed.
12 (Optional) You can create filter workflow which fires the following
Add-PGNA-Values command:
Application-Command Approval Add-PGNA-Values -t "$Signature ID add$" -o $Rule Name$ -l "$Short Description$"
This command executes the Parameterized Get Next Approver rule type so that you can add additional approvers ad hoc as needed.
13 Open the AP-Sample:Lunch Scheduler form in New mode and create a
ticket. Make sure you remember the entry ID.

14 Open the front-end form in Search mode.
The list of approvers required is displayed in the table form.
15 Double-click an entry that requires approval.
The entry appears in the AP:Signature form.
Chaining approval processes

Lunch Scheduler demonstrates the technique of chaining three different approval processes together to form the approval environment for Lunch requests. Neither the requester nor the approvers need to be concerned with the details of the processes being followed. The Lunch Scheduler application has set up workflow to start the initial process and then chain to the others if and as needed.
Using a status field in chained processes

The key to this workflow is an extra field that holds the current stage of the approval process. This status field holds a value determined by the stage of the process the request currently is in. Workflow tests the value set by each stage of each process to determine where to go next. Approval workspace field In Lunch Scheduler, the status field is a character field named Approval Workspace, ID 536870920. This field is loaded with a string to represent the current state of the flow through the three chained approval processes.
Flow between chained processes

The three processes in the sample Lunch Scheduler execute in this order:
Step 1 The Management Cost Authorization process runs first. Step 2 When successful, it writes a note into the Approval Workspace field. Writing
this note launches the testing for the second process, Major Account Level Approval. Approval Process Done rules are used to populate this Approval Workspace field.
Step 3 If the customer is a major or enterprise account, the Major Account Level
Approval process runs.

Step 4 When that process is successful, it writes a note into the Approval Workspace
field. Writing this note launches the testing for the third process, Special Overdue Approval. Approval Process Done rules are used to populate this Approval Workspace field.
Chaining approval processes
221
Step 5 If the account is overdue, the Special Overdue Approval process runs.
Using the Approval Workspace field, the system knows which process is active and in progress, and can monitor the flow across three approval processes.
Note: The Approval Workspace field is updated with a setting to indicate success of the Major Account Level Approval process even when there is no action to be taken on the level process. It is important that the process be marked successful in this case, so that the test for the next process can simply be for approved or not approved, without having to worry about how it got to the approved state.
Restarting an approval process

Occasionally, after an approval process has been started, it becomes inappropriate to proceed. Situations and peoples minds often change, negating the needs of yesterday. What if a request becomes unnecessary and you need to stop an approval process? This example has an automatic restart if there is a significant change to the request. If anyone changes the restaurant, company, or number of attendees, the automatic restart cancels the current process and routes it from the beginning. This makes sure that someone doesn't make a change after the record has already been approved. The way the example actually accomplishes this operation is to issue a cancel to the approval subsystem. At this time, no further action is taken. The Done processing of the processes will return Cancelled to the Approval Workspace field discussed in Using a status field in chained processes on page 221 The application watches for the Cancellation string and if that is set, will restart the approval process from the beginning.
Special techniques
This section introduces techniques that you might want to use in your own approval processes. These techniques include: More information on page 223 Show summary and signatures on page 224 Show password field if required on page 225 They detail how you can add a little more than the minimum needed to link your application to the Approval Server, and get a richer integration with additional capabilities for your users.
More information
It is useful to review all information for a request from one place. The APSample:Lunch-Detail-Signatu form has a button named Manage More Information. This button takes you to a dialog box that allows you to review and respond to (if appropriate) the More Information Requests on the current record. This button links to a dialog box that provides a list of all More Information records for the current request. You can review all requests and their current state. Use BMC Remedy Administrator to review the button Manage More Information about the AP-Sample:Lunch-Detail-Signatu form. Also review the active links AP-Sample-Dtl-Sig:MoreInfo01 through AP-Sample-DtlSig:MoreInfo06. To take advantage of this extension in your own approval forms, follow this procedure.
To add a More Information button

1 Create a button on your xxx-DetailSignature form, where xxx is your own
application. The name of this button is not critical.

2 Give the button an ID of 13198 and Public permission. 3 Make a copy of the six active links named AP-Sample-Dtl-Sig:MoreInfo01
through AP-Sample-Dtl-Sig:MoreInfo06.
4 For each copy, change the attached form to your xxx-DetailSignature join
form.
Special techniques 223
BMC Remedy Approval Server Figure 12-5: Copy AP-Sample-Dtl-Sig: MoreInfo01 through MoreInfo06
Rename active link. Attach to your form xxx.
Show summary and signatures

Some approvers want to see who has approved and who currently has the item awaiting approval. The AP-Sample:Lunch Scheduler form has a pair of buttons that allow someone approving a lunch request to get a list of signatures. This extension is a relatively simple macro that receives parameters from the current record. Copy the sample macros or create your own.
To create and activate Show Summary and Signatures

1 Create two buttons on your application form called Show Approval
Summary and Show Signature. Give these buttons Public permission.

2 Make copies of the following three active links:
AP-Sample:DisableShowOnCreate AP-Sample:Show App Signatures AP-Sample:Show App Summary For each copy, change the attached form to your xxx-join form.
3 Export the three active links and edit them to match your application: a Substitute your database IDs for the two buttons. b Substitute the names of your Detail and Detail Signature forms for the Set-
Schema action of the macros.

c Substitute your application name in the macro name. 4 Import the edited active links into your application.
Show password field if required

On the AP-Sample:Lunch-Detail-Signatu form, a pair of active links retrieves information about the process this signature is attached to and, if that process requires a password to approve, activates the password field. If your approval environment includes only one process, one form determines whether passwords are needed. This technique is useful when you have multiple processes only some of which require approver passwords. For more information, see the Required Password field described in Chapter 9, Creating a process. The following procedure shows how to copy sample active links allowing the password field to be active.
Copying active links for the password field

1 Use BMC Remedy Administrator to position the Password field ID 102 in an
obvious location on your xxx-Detail Signature join form.

2 Make copies of the following two active links:
AP-Sample:ShowPwdIfRequired1 AP-Sample:ShowPwdIfRequired2
3 For each copy, change the form to which they are attached to your xxx-Detail
Signature join form.
Recommended technique: menu of valid names

Although this example application does not demonstrate this technique, consider the practice of providing your users with menu lists when entering user names. A menu list helps prevent typographical errors that can produce approval process errors. Here are three examples of fields for which a menu list could provide names: Alternate Approver form, Alternate field AP:More Information form, To field AP:Detail Signature form, Reassign To field See the menus chapter of the Form and Application Objects guide for more information about creating menus from AR System searches.
Special techniques
225
Sample users
The Approval Server samples include records for a number of imaginary users preconfigured for testing the Lunch Scheduler application.
Note: The procedures in Chapter 6, Using a sample application, require sample users Frank Williams, Jack Miller, Larry Goldstein, Violet Anderson, and Sue Smith to be licensed AR System login names.
Licensing sample users

To log in with the sample login names, they must first be entered as valid AR System users. Check with your AR System Administrator to determine if you have purchased sufficient write licenses to create the sample users as actual accounts in your AR System database. If you see use existing licenses with the sample applications, use the Sample Signature Authority form to change the sample users to login names that are already present within your AR System server User form.
Figure 12-6: Use AP-Sample:Signature authority to change sample users
Change sample names to licensed users.
Sample user approval authority

The sample application users are set up in a parent-child hierarchy with dollar value spending authority shown in Figure 12-7:
Figure 12-7: Hierarchy and spending authority of sample users
Sample users
227
Chapter
13
Adding approvals to your application

This chapter describes how AR System administrators can connect AR System applications to the Approval Server. This discussion assumes you have an existing application, and have previously installed the Approval Server. The following topics are provided: Connecting an application to the Approval Server (page 230) Enabling workflow-based notifications (page 235) Preparing your application to interact with Approval Central (page 237)
Note: Although you do not have to be an AR System administrator to set up and manage approval processes, you must be an AR System administrator to connect your application to the Approval Server.
Adding approvals to your application
229
Connecting an application to the Approval Server

Follow these steps to link your applications form to the Approval Server. The examples in this chapter use xxx for the name of the application connected to the Approval Server. This section also includes suggestions for implementing a chained approval process. Usually you will link only the main form of your application to the Approval Server. If your application has more than one form that needs to start an approval process, you will need to join each form, as shown in steps 1 and 2.
Note: Part of building the approval process is making a three-way join using the base form and AP:Signature and AP:Detail forms. If you make a mistake in entering the approval tag and later need to edit it after you import the form, you will need to recreate the joins.
To connect an application to the Approval Server

1 Log in to BMC Remedy Administrator with administrator permissions. 2 Create an inner join with xxx as the Primary form and AP:Detail as the
secondary form.
Important: New functionality was added to the AP:Detail form to enable workflow-based notifications. For more information, see Enabling workflow-based notifications on page 235.
This join form is used only for internal processing so the appearance of the form is not critical.
a Join Request ID (field ID 1) of your form xxx to the Request field (field ID
8) of form AP:Detail.
b Include all fields from xxx form and all fields from AP:Detail. c Keep the default views with the join.
Before you save your join form, you must manually specify a reserved ID for two fields, as described in step a and step b. Use the Find Field feature in BMC Remedy Administrator to more easily locate and open these fields.
230 Chapter 13Adding approvals to your application
a Open the Status-Dtl field ID 7 from AP:Detail. On the Display tab, change
the field access to Read/Write to enable global overrides. Click the Database tab. Type the number 13191 in the empty ID field.
b Open the Request field ID 8 from AP:Detail. Click the Database tab. Type
the number 10051 in the empty ID field.

c Choose Form Menu > Form Properties > Permissions tab.
Make sure Public appears in the Permissions field. Assign Public the Hidden characteristic. Without this step, the approvers cannot use APW:Approval Central properly. Before you save your join form, you must manually specify a reserved ID for two fields, as described in step a and step b.
a Save your join form. b Click OK both times when the AR System asks you to confirm your
intention to use reserved IDs. You can also ignore any subsequent warnings.
3 In BMC Remedy Administrator, verify xxx (your primary application form)
has permissions set as shown in the following table. This allows approvers to change the fields. Otherwise, the fields listed in the table can be modified only by the AR System administrator.
DB ID 1 2 3 4 5 6 Default label Request ID Submitter Create Date Assigned To Last Modified By Permissions Assignee (view) Public (view) Assignee (view) Public (view) Assignee (view) Public (view) Assignee (change) Public (view) Assignee (view) N/A N/A Yes $USER$ N/A Yes $USER$ Allow any user Default value to submit N/A No
Modified Date Assignee (view)
231
DB ID 7
Default label Status
Permissions Assignee (change) Public (view) Submitter (change)
Allow any user Default value to submit Yes New
Short Description
Assignee (change) Public (view) Submitter (change)
Yes
4 Create an inner join between xxx and AP:Detail-Signature, with xxx as the
Primary form and AP:Detail-Signature as the secondary form.

a Join Request ID field (ID 1) of your form xxx to the Request field (ID
10051) of form AP:Detail-Signature.

b Include all fields from xxx form and all fields from AP:Detail-Signature. c Arrange the fields of this form with care.
This form is where your users will spend much of their time when reviewing approvals, so attention to the layout and appearance of the form is important. You might hide or remove from view most of the fields of the AP:Detail-Signature form. Use tabs in a page field to display only those fields that are significant or that you want your users to have access to.
Tip: When selecting a field, use the Find Field feature in BMC Remedy Administrator to more easily locate it. Then choose Layout > Bring to Front to select the field.
Move the Approval Status field (ID 13191) from the AP:DetailSignature form to a prominent location, because this is the field approvers use to approve or reject a request. Move the Status field ID 7 from your form xxx to a subordinate position, because within the approval environment the Status of your application xxx is not as important as the Status of the approval request.
d Choose Form Menu > Form Properties > Permissions tab.
Make sure Public appears in the Permissions field. Assign Public the Hidden characteristic. Without this step, the approvers cannot use APW:Approval Central properly.
e Save your join form.
While creating the join, you might receive several notes about a field being accessible only to the Administrator. Click OK to continue. This message is a warning that there are no extra permissions on several fields. These fields are used strictly by workflow and are related to the security of the approval process. They do not indicate that something is wrong. You will not receive these messages if you have configured AR System Administrator to suppress this warning.
5 Once the joins are created, run the program arjoinfix (UNIX) or
arjoinfix.exe (Windows) for the Primary form:

arjoinfix -i <install_dir>
Find this program in the same directory as the BMC Remedy Approval Server program.
Note: You must run arjoinfix (UNIX) or arjoinfix.exe (Windows) on all forms you create for use with the Approval Server. This executable modifies the join qualifications to make sure your applications communicate properly with the Approval Server when you have more than one application requiring approvals.
This program prompts you for the name of the form that you are linking to the Approval Server, xxx in this example. It will then find the two joins that you have created and update the join criteria to include the form name. If you do not have Registered with Port Mapper enabled in their environment or you do not even want to temporarily enable this option on your AR System server, you can use the following option that can be passed to the arjoinfix utility from the command or shell line:
arjoinfix -portnum <number>
Finally, UNIX/Solaris users must use the following command option to avoid password problems: arjoinfix -i <install_dir>
233
6 Launch BMC Remedy User. On form AP:Administration, click the Form tab
and create an entry for xxx, the form in your application that launches the approval process. This registers and connects your application with the Approval Server so that the AR System can process approvals appropriately with your applications workflow. To perform this step, you must be a Process Administrator with Full Admin authority for all processes (or an AR System Administrator). Enter a keyword in the Lookup Keyword field to enable easy identification when searching for this form.
7 Design your approval process. This is a paper and pencil stage, not to be
confused with implementation using the AR System. This stage is vital to the success of your approval-based application. If you have a thorough understanding of your approval process, you will be rewarded with a smooth implementation.
8 Implement your definitions within the AR System. Here you create the
Notifications, Processes, Rules, and Roles to handle all approval processes you planned in the previous step. For more information, see the following sections: See Using approval notifications on page 127 for creating notifications. See Defining an approval process on page 139 for creating processes. See Defining approval rules on page 153 for creating rules. See Managing users and roles on page 207 for creating roles.
9 Connect your application form xxx to the Approval Server with at least one
filter to start the approval process. The filter should run the Approval Server New-Details command to initiate the approval process. You might find that you go back and forth between this step and the previous before your workflow is smooth and presentable. For example, to start the approval process, you would create a filter that has a Run Process action. This action would issue the command to the Approval Server to initiate approval processing for the current entry. Here is an example command starting a process named ABC:
Application-Command Approval New-Details -s $SCHEMA$ -e $Request ID$ -t ABC
See Appendix B, Application commands, for details on Approval Server commands and Overview of the Lunch Scheduler application on page 214 for the filters used to create a chained approval process.
10 Create a Process Done rule, or your approved/rejected results will never be
reported to form xxx. This is very important. For more information, see Working with Approval Process Done rules on page 201. Optionally, you can add links to stop a pending process or to provide more information.
11 To chain approvals together, repeat step 8 through step 10 as many times as
needed.
a Define the workflow needed to start an approval process using the
Application-Command in Run Process filter actions.

b Define the workflow needed to react to the approval processes using the
Process Done rules. For more information, including examples, see Chaining approval processes on page 221.
12 If you chain together more than one process, add a field to your form xxx to
display its status. For example, an application can display where a request is within three chained processes in which management approves the need, then MIS approves a model, and finally the corporate buyer must approve a vendor.
Enabling workflow-based notifications

The Approval Server has a complete notification system which can fire on many approval events, and can use all the AR System server notification methods, such as email. The 7.0 release now provides a mechanism for application designers to use workflow-based notifications with the Approval Server. This feature lets applications use their customized notification systems for approval events.
Enabling workflow-based notifications
235
To enable workflow-based notifications

1 Follow the steps to add an application to the Approval Server, as described in
Connecting an application to the Approval Server on page 230.

2 Add the following fields from the AP:Detail-Signature form in the three-way
join: Notification Message (field ID 12303) Subject (field ID 12305) Additional Fields (field ID 12340) Process Instance ID (field ID 13201)
3 In the AP:Notification form, follow the steps to create a notification for your
process, as described in Defining an approval notification on page 129.

4 Click the Details tab. 5 From the Method field, select Workflow as the notification option. 6 Create a filter in BMC Remedy Administrator with the following workflow
actions:
a Create a Set Fields action that pushes the values from the AP:Notification
form used for message details to the display-only fields that you added to the AP:Details form. For example, define the Set Fields action to push the value from the Subject field on AP:Notification to the Subject display-only field on AP:Details.
b Create a Call Guide action that selects the AP:Workflow Notifications
Guide. The Approval Server installation program adds this filter to the server.
7 Add your filter to the AP:Workflow Notifications Guide filter guide.
This filter guide was created in the 7.0 release for use with workflow-based notifications. This filter guide provides application designers a mechanism to write your own workflow-based notifications which retrieve your notification events from the Approval Server. When the approval cycle event triggers the notification, the Approval Server fires a filter that sends the notification.
Preparing your application to interact with Approval Central

This section discusses how to prepare an application you previously linked to the Approval Server for use within the Approval Central interface. This section includes three topics: Adding your form to the Approval Central application on page 237 Integrating your form with Approval Central workflow on page 238 Adding optional navigational aids on page 239 For detailed instructions on how to perform any of the steps in this section, see the Form and Application Objects and Workflow Objects guides.
Adding your form to the Approval Central application

This procedure enables your form to be viewed as part of Approval Central. Use the existing fields on the APW:Approval Central form as your guide. Use the appropriate form view for your environment.
To add forms to the Approval Central application

1 In AR System Administrator, add your three-way join form to the
ApprovalCentral application object.
2 Create the appropriate views of your join form.
For example, if you are creating a web view, arrange the fields the way you like them.
3 For web views, create a results list field and make it hidden.
This field is needed so that users can drill down to look at individual approval records from the Approval Central view. Users will not interact with it, so it should be hidden.
4 Create a Save Changes button and an active link that pushes the values to
your join form. The easiest way to do this is to copy the button from the AP-Sample:Lunch-Detail-Signatu form, then copy the AP-Lunch-Dtl-Sig:SaveChanges active link and modify its actions to operate against your application.
237
5 Open the appropriate view of the APW:Approval Central form and create a
table field that displays records from your join form. The table should have the same features as those that already exist for the two sample applications, so the best way to do this is to copy and paste one of those tables and then modify it.
a Make sure that a column in the table points to the request ID field
(field ID 1) of your form, and that the column gives View permission to the Public group. You can hide this column.
b For web views, make sure that the Web Drill Down Column is not one of
the first three columns, which display as radio buttons. A column pointing to a request ID field is a good choice.
c Use the field name of your request ID column in the HTML radio button
code in the Default Value of the first three columns in the table.
Integrating your form with Approval Central workflow

This makes your table field in APW:Approval Central behave like those for the sample applications, refreshing its contents and submitting changes at the appropriate times.
1 In the APW:Central_Init02 active link, add a Change Field action that
refreshes your table field in Approval Central.

2 Copy the APW:Central_LSSubmit01 and APW:Central_LSSubmit02 active
links and replace the LS in their names to something denoting your application. Change their actions to operate against your application instead of the Lunch Scheduler sample application.
3 Create an active link guide that loops these two active links in numerical
order, such as the APW:Central_LSTableLoopGuide does.

4 In the APW:Central_TableLoopSubmit active link, add one action to call this
guide and another action to refresh the table field for your application in
APW:Approval Central.
Adding optional navigational aids

These optional steps give your application the same navigational aids as the sample applications, making it easier to use.
To add navigation links

1 Copy the left-side controls (including those displayed as URLs and as
buttons) from the web view of a sample application form to your join form. Be sure to keep the same names and field IDs.
2 Add your form to the list of forms for the APW:GoAccessPriv,
APW:GoMoreInfo, and APW:logout active links.
To add online help

1 Create an HTML file that contains help on the web view of your join form. 2 Add the file to the Approval Central application as a resource. 3 Create a button on your form that users will click to open the help. 4 Create an active link triggered by the button to open the help. An easy way to
do this is to copy and modify the AP-Sample-Dtl-Sig:Help active link.
Further enhancing your application

You can add tables to put more information in one place, editable columns in your table on Approval Central so that approvers can make changes without having to open a detail view, and other enhancements. Explore the sample application forms and workflow to find the parts that are useful to you.
239
Appendix
Worksheets
The worksheets in this appendix are intended to assist you in designing the various components of the 7.0 Approval Server. Reproduce the worksheets as needed. The following topics are provided: Process worksheets (page 242) Rule worksheets (page 245)
Worksheets
241
Process worksheets
The following process worksheets help you set up your process and escalations. Defining a process on page 242 More information escalations on page 242 Signature escalations on page 243
Defining a process
Use this worksheet to help you design a process.
Process Name Form Process Type Request Owner Field First Approver Field Approval Success If Multiple Approvers Allow Ad Hoc Next Approver? For Self Assignment Validate Approvers? Require Password? No more approvals One Must Sign Anyone Use Get Next Approver Rules Yes Yes Completion rule All Must Sign Approver Assign to Owner If Approver No No Allow Only One Approver No one Always Assign to Owner
More information escalations

Use this worksheet to help you set the More Information state escalations parameters on the Process form.
Business Calendar Holiday Calendar Notification: Still Outstanding First Interval Repeat Interval Unit Unit
242 Appendix AWorksheets
Signature escalations
Use the following worksheets to help you set the Notification parameters on the Process form.
Normal priority notifications

Use Schedules Business Calendar Holiday Calendar Automatic Action After Interval Change State First Interval Repeat Interval Notification: Still in StatePending First Interval Repeat Interval Notification: Still in StateError First Interval Repeat Interval Notification: Still in StateHold First Interval Repeat Interval Notification: Still in StateMore Information First Interval Repeat Interval Unit Unit Unit Unit Unit Unit Unit Unit o Pending Notification: Still Outstanding Unit Unit Unit o Approved o Rejected
Urgent priority notifications

Use Schedules Business Calendar Holiday Calendar Automatic Action After Interval Change State o Pending Unit o Approved o Rejected
Process worksheets
243
Notification: Still Outstanding First Interval Repeat Interval Notification: Still in StatePending First Interval Repeat Interval Notification: Still in StateError First Interval Repeat Interval Notification: Still in StateHold First Interval Repeat Interval Notification: Still in StateMore Information First Interval Repeat Interval Unit Unit Unit Unit Unit Unit Unit Unit Unit Unit
Low priority notifications

Use Schedules Business Calendar Holiday Calendar Automatic Action After Interval Change State First Interval Repeat Interval Notification: Still in StatePending First Interval Repeat Interval Notification: Still in StateError First Interval Repeat Interval Notification: Still in StateHold First Interval Repeat Interval Unit Unit Unit Unit Unit Unit o Pending Notification: Still Outstanding Unit Unit Unit o Approved o Rejected
Notification: Still in StateMore Information First Interval Repeat Interval Unit Unit
Rule worksheets
Use the following worksheets to help set up your rules. Auto-Approval rules on page 245 Get Authority Self rules on page 246 Get Authority rules on page 246 Self-Approval rules on page 247 Validate Approver rules on page 247 Prep Get Next Approver rules on page 248 Get Next Approver rules on page 249 Get Authority Regular rules on page 250 Completion rules on page 250 Parameterized Get Next Approver rules on page 251 Signature Accumulator Done rules on page 252 Statistical Override Done rules on page 252 Approval Process Done rules on page 253
Auto-Approval rules
Rule Name Purpose For Process Rule Audit Text
Rule worksheets
245
Get Authority Self rules

Rule Name Purpose For Process Run If Qualification Set Fields Type From Form On Server Qualification Set Field Value Server o Value o Query o SQL o Process o Other
Get Authority rules

Self-Approval rules
Rule Name Purpose For Process Rule Audit Text
Validate Approver rules

Rule Name Purpose For Process Run If Qualification Set Fields Type From Form On Server Qualification Server o Value o Query o SQL o Process o Other
Rule worksheets
247
Prep Get Next Approver rules

Rule Name Purpose Rule Type Run If Statement Set Fields Type From Form On Server Qualification Set Field Value Server o Value o Query o SQL o Process o Other
Get Next Approver rules

Rule Name Purpose Rule Type If Multiple Results o Value from First o Return Error If Multiple Approvers Next Approver Rule Is Run If Statement Set Fields Type From Form On Server Qualification Set Field Value Server o Value o Query o SQL o Process o Other o One Must Sign o Additive o Values from All o clear o All Must Sign o Exclusive o clear o clear
o Ending
Rule worksheets
249
Get Authority Regular rules

Completion rules
Rule Name Purpose For Process Rule
Parameterized Get Next Approver rules

Rule Name Purpose Rule Type If Multiple Results o Value from First o Return Error If Multiple Approvers Next Approver Rule Is Guaranteed Add Run If Statement Set Fields Type From Form On Server Qualification Set Field Value Server o Value o Query o SQL o Process o Other o One Must Sign o Additive o No o Values from All o clear o All Must Sign o Exclusive o Yes o clear o clear
o Ending
Rule worksheets
251
Signature Accumulator Done rules

Rule Name Purpose For Process Run If Qualification Set Fields Type From Form On Server Set Field Server Value o Value o Query o SQL o Process o Other
Statistical Override Done rules

Rule Name Purpose For Process Run If Qualification Set Fields Type From Form On Server Set Field Server Value o Value o Query o SQL o Process o Other
Approval Process Done rules

Rule Name Purpose For Process Rule State Set Fields Type From Form On Server Set Field Server Value o Approved o Value o Rejected o Cancelled o Process o Error o Other
o Query
o SQL
Rule worksheets
253
Appendix
Application commands
To support close interaction between the AR System server and the Approval Server, you use a special process, Application-Command. This process can be run from filters, escalations, and active links using the Run Process action. The following topics are provided: Basic information (page 256) Specific Approval Server commands (page 258)
Application commands
255
Basic information
The Application-Command process allows the specification of commands to be executed by an application. A special form named Application Pending is automatically created and managed by the AR System server. Whenever the Application-Command process is run, a request is created in this form with details about the command issued. the Approval Server process retrieves commands from this form for processing. This process uses the Run Process action. Although no actual process is run, it follows all the rules and restrictions of a process. This means that you must be sure to quote parameters with spaces just like you would for a traditional process. In addition, it is a process that exists on the server. So, if you are performing an operation from an active link, you must be sure to use the syntax that indicates that the process should be run as a remote process on the server (versus on the client). The basic command format is:
Application-Command category command [-s form] [-e request-id] [-t tag] [-1 field-1] [-2 field-2] [-3 field-3] [-o other-string-<-255] [-l other-string-unlimited]
The category and command parameters are positional. The other parameters are optional and can appear in any order after the two positional parameters. This list describes the parameters in greater detail: categoryA character string with a maximum of 30 characters that identifies which application the command is for. For the Approval Server, this value is always Approval. commandA character string with a maximum of 30 characters that indicates a specific operation to be performed within the category. Commands for the Approval Server are defined in the next section. formThe name of a form that the command is related to. If no form is specified, this value defaults to the form the filter or active link is attached to. request-idThe ID of the request that the command is related to. If the request is 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.
256 Appendix BApplication commands
tagA tag that is specific to the category and command. This might be a further identifier for the operation. For example, for many approval commands, the tag is the name of the approval process. field-1The ID of a field or an integer code associated with the category or command. field-2The ID of a field or an integer code associated with the category or command. field-3The ID of a field or an integer code associated with the category or command. other-string-<-255A string with a maximum of 255 characters. other-string-unlimitedA string with no maximum. For the form and request-id arguments, the -s and -e parameters default to the current form and current request ID if the operation is performed from a filter or escalation. Therefore, if the default values are sufficient, the -s and -e parameters can be omitted. 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. As a general rule, any parameter you supply that is not defined for the command is ignored. Extra parameters will not cause a failure, but they will also not affect the running of the command. Avoid supplying extra parameters. Example command This command would start the approval process named MyProcess against the current entry:
Application-Command Approval New-Details -s $SCHEMA$ -e $Request-ID -t MyProcess
Notice the quotes around the arguments. You should always use quotes around arguments to insure that they are processed correctly when they contain spaces.
Basic information
257
Specific Approval Server commands

Note: All commands defined for the Approval Server appear in this section. However, most of the commands are only useful, internally, to the Approval Server and its workflow.
The following Approval Server commands must all be preceded by

Application-Command Approval, according to the format described in Basic
information.
Add-Sig
Add-Sig [-s form] [-e request-id] [-t process-name] {-o approverlist} [-1 {0|1}] [-2 {0|1|2|999}] [-l Assignee Group ID]
This command adds an additional signature line to an existing approval request (or creates a new approval request if there is not one) for the specified request. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, the specified approval process is activated. If it is not supplied, the system searches for a process against the specified form. If there is only one process specified, that process is used. If several processes are specified, an error is reported, and no approval process starts. The approver-list argument contains the approvers to add. If omitted, this command performs no work. Multiple approvers are separated by a semicolon. The 1 option indicates whether the new signature line is identified as independent Yes or independent No, based on whether the value is set to 1 (no) or some other value (yes). 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. The -l optional parameter was added to allow you to pass in a value for field 112 (Assignee Group Permissions) for the multitenancy feature.
The operation of this command generally links to an existing approval details record, although it creates one if none exists. It then adds one or more signature lines for the value specified in the other option.
Add-PGNA-Values
Add-PGNA-Values [-t detail-id] [-o rule-name] [-l values-list]
This command is used by the application to provide the variable values for the Parameterized Get Next Approver rule type. The following format for this signal will is used: The detail-id parameter is the request ID of the AP:Detail record. The rule-name parameter is the name of the Get Next Approver rule these values are meant for. The values-list parameter is the list of values. The following example provides a sample signal you can create:
Add-PGNA-GNA-values -t "00000000000012" -o "Sample Param GNA Rule" -l "4/Frank Williams"
You separate values with a slash (/).
Det-Approved
Det-Approved [-s form] [-e request-id] [-t process-name]
This command marks the approval detail item 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. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
Det-Cancelled
Det-Cancelled [-s form] [-e request-id] [-t process-name]
259
This command stops an approval process that is in progress, marking the approval detail item Cancelled. Any outstanding signature lines or More Information records are marked Cancelled. The Process Done phase notifies the associated request of the cancellation. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
Det-Error
Det-Error [-s form] [-e request-id] [-t process-name]
This command marks the approval detail item to be in 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 Approval Server. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
Det-Rejected
Det-Rejected [-s form] [-e request-id] [-t process-name]
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. The form and request that are being approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, only the detail record tied to the associated process is updated. If it is not supplied, all detail records from all processes associated with the record are updated.
MoreInfo-Return
MoreInfo-Return [-s form] [-e request-id]
This command takes data from the specified More Information request and copies the response back to the associated signature request. The More Information request identified must be marked Completed. The form parameter is optional. If it is supplied, it must be the More Information form. The request-id parameter is optional. The request-id parameter is the ID of the More Information record.
New-Details
New-Details [-s form] [-e request-id] [-t process-name] [-1 priority] [-l Assignee Group ID]
This command starts the Approval Server process for the specified request. The form and request to be approved are optional. If they are supplied, they identify the request that is being processed. The process-name parameter is optional. If it is supplied, the specified approval process is activated. If it is not supplied, the system searches for a process against the specified form. If there is only one process specified, that process is used. If several processes are specified, an error is reported, and no approval process starts. The priority parameter is also optional. If they are supplied, it sets the priority to Urgent (1), Normal (2), or Low (3). Any other setting is ignored, and the defaultNormal (2)is applied. The -l optional parameter was added to allow you to pass in a value for field 112 (Assignee Group Permissions) for the multitenancy feature. The operation of this command creates an approval details record. It then searches for auto- and self-approval rules; if one of them passes, it marks the record Approved and continues with the Process Done phase to update the associated request. If no auto- 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 system.
261
Rename-Form
Rename-Form {-t old-name} {-o new-name} [-1 only-active] [-2 dorename]
This command changes the name of a form. All references in the definition forms are updated. If the only-active parameter is set to 1, only active entries are updated. Any other setting causes all entries to be updated. This setting controls which AP:Detail records are updated. All definition records are always updated. If the do-rename parameter is set to 1, the form itself is renamed. Any other setting assumes the form has already been renamed by using the AR System Administrator tool and you are simply updating cross-references.
Rename-Process
Rename-Process {-t old-name} {-o new-name} [-1 only-active] [-2 do-rename]
This command changes the name of a process. All references in 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. If the only-active parameter is set to 1, only active entries are updated. Any other setting causes all entries to be updated. This setting controls which AP:Detail records are updated. All definition records are always updated. If the do-rename parameter is set to 1, the process itself is renamed. Any other setting assumes the process has already been renamed by using the AP:Process form and you are simply updating cross-references.
Sig-Approved
Sig-Approved [-s form] [-e request-id] [-t process-name]
This command performs approval processing on a signature line that has been marked Approved. The rule process continues to the next approvers. This command is issued when a signature line is changed to Approved. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of the signature entry and is also optional.
The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Sig-Cancelled
Sig-Cancelled [-s form] [-e request-id] [-t process-name]
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) for this operation to be performed. The signature line is cancelled and appropriate moves within the process are performed, depending on whether other signature lines are active. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of the signature entry and is also optional. The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Sig-Notify
Sig-Notify [-s form] [-e request-id] [-1 num-notifies]
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 formAP:Detail-Signature join. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of an AP:Signature form request and is also optional. The num-notifies parameter indicates that this is the initial notification for a value of 0 (the default) or that this is a repeat notification for any other value. This triggers delivery of the notification or repeat notification message.
263
Sig-Notify-Change
Sig-Notify-Change [-s form] [-e request-id]
This command causes a notification message to be sent, indicating that the specified entry has been changed. The notification is sent to any approvers who have previously approved the process that is indicated. The notification is informational, to let previous approvers know of a change. The notification message is sent to the corresponding form-AP:Detail-Signature join. The form and request-id parameters in this command are optional. If supplied, they identify the entry that is to be notified, for example, if you want to create an approval notification from a form in the Change Management application. The process-name parameter is optional. If supplied, only the approved signatures tied to the process specified are notified. If not supplied, all approved signatures for all processes associated with the record are notified.
Sig-Notify-State
Sig-Notify-State [-s form] [-e request-id] [-1 num-notifies] {-2 state} [-3 0|1]
This command causes a notification message to be sent, indicating that the specified AP:Signature record has exceeded its defined time limit for a given state without being resolved. The notification message is sent to the corresponding form-AP:Detail-Signature join. The form parameter is optional. If supplied, it must be the AP:Signature form. The num-notifies parameter indicates that this is the initial notification for a value of 0 (the default) or that this is a repeat notification for any other value. This triggers delivery of the notification or repeat notification message. The state parameter is the numeric value for the state the notification is for. It can be set to 0 (Pending), 3 (Hold), 4 (More Information), or 6 (Error). Any other setting will default to 0 (Pending). Set the 3 parameter to 0 (the default) to indicate the notification is for an escalation or 1 to indicate that the notification is simply a direct notification. Any other value assumes the default.
Sig-Reassign
Sig-Reassign [-s form] [-e request-id] [-t process-name] {-o short-list | -l long-list}
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, or More Information) for this operation to be performed. The form parameter is optional. If supplied, it must be the AP:Signature form. The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Sig-Rejected
Sig-Rejected [-s form] [-e request-id] [-t process-name]
This command performs the rejection processing on a signature line that has been marked Rejected. The process of marking the associated detail line Rejected is performed. This command is issued when a signature line is changed to Rejected. The form parameter is optional. If supplied, it must be the AP:Signature form. The request-id parameter is the ID of the signature entry and is also optional. The process-name parameter is optional. If supplied, it must match the process specified by the detail record that is associated with the specified signature line.
Update-Config
Update-Config {-t label} [-o value]
This command updates the administrative configuration settings for the application. The specific setting being updated is identified by the label parameter. This label is defined in arstruct.h and is placed in the ar.cfg (ar.conf) file.
265
The value parameter can be omitted to cause the setting to be reset to its default value or to a value in the appropriate format for the ar.cfg (ar.conf) file. The Approval Server reacts immediately to changes in settings that are not start-up-only. For the approval notification option, no value resets all options to their default value. Otherwise, only the option that is defined in the value parameter is reset. For the debug mode, other debug options can be defined and, if they are, this setting takes effect. However, if only a 0 or 65536 (the setting for approval debugging) are set, only that flag is changed, and other settings remain as they are in the file.
Appendix
Approval forms
This appendix displays all the 7.0 Approval Server forms and provides field descriptions. The 7.0 release made it easier for administrators and users to access the most important approval server functionality in the Approval Central and Administration forms. For example, the best practice now is to use AP:Administration to access the Server Settings and Rename settings and not open the helper forms independently.
Approval forms
267
Approval Central application

Approvers use this view with the User tool as a launch pad to review their approval requests, access privileges, and More Information Requests. All fields are optional except the Application field. For the web view, see APW:Approval Central on page 312. See Chapter 5, Processing approval requests with Approval Central, for a discussion of how to use this form.
Figure C-1: Approval Central form
Approve/Reject Next approver
Use the menu list to select a status for a search. Leave the field empty to view all your approvals. Enter the name of the next approver. This must be an AR System login ID.
268 Appendix CApproval forms
AP:Administration
Process administrators use this form as a launch pad to create and modify records that make up approval processes. For more information, see Using the Approval Server Administration form on page 118.
Figure C-2: Administration form
Show for process Use the menu list to limit the display list to items associated with the selected process. This field is not active for the Role and Form categories. Click a tab to display a list of items of that type. This also selects Process, rule, notification, role, which category of items is involved when you click the buttons on this form. form, administrator, alternate View Search Create Delete Click this button to open the item selected. Click this button to open a search form for items of the category determined by the current tab. Click this button to create a new item of the category determined by the current tab. Click this button to discard the currently selected item. It opens the form that appears in AP:Admin-DeleteVerify on page 270.
AP:Administration
269
Refresh Server settings
Click this button to have the AR System reload the displayed list. Click this link in the navigation pane to open the Server Settings form. For more information, see AP:AdminServerSettings on page 272. Click this link in the navigation pane to open the form that appears in AP:Admin-Rename on page 271 to rename the currently selected item.
Rename
AP:Admin-DeleteVerify
This dialog box appears when a process administrator clicks the Delete button on the AP:Administrator form.
Figure C-3: AP:Admin-DeleteVerify dialog box form
No Yes
Click this button to close the form with no action performed. Click this button to delete the item selected in the previous form.
AP:Admin-Rename
This dialog box appears when a process administrator selects Rename in the navigation pane of the Administration form.
Figure C-4: AP:Admin-Rename dialog box
Rename From old name To new name
Use the menu list to determine whether this rename operation is performed on a form or a process. Type a name or use the menu list to select an item to be renamed. Type the replacement name for the item in the From Old Name field, or use the menu list to select a name. 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.
Update
Select an option from the drop-down menu to determine which of the associated detail records are renamed. All renames detail records for current and past approval requests. Only Active Objects renames detail records only for currently open approval requests.
Including object itself
Select this check box to include the form or process you are renaming. This is useful if you are renaming all references to the name of an item that has been manually renamed previously.
Rename Cancel
Click this button to complete this rename operation. Click this button to close the form with no action performed.
AP:Administration
271
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 then 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 regarding the Approval Server. To open this form, select Server Settings in the navigation pane in the AP:Administrator form.
Basic tab
Figure C-5: AP:Admin-ServerSettings formBasic tab
Approval debug mode Log file name
Select this check box to enable the Debug mode, which creates entries in the log file. Type the directory path and file name in which to store log entries for the Debug mode.
Definition check interval
Type a number of seconds in this field to determine how often Approval Server checks the definitions for changes. A larger number increases AR System performance by checking less often. A smaller number of seconds is useful while creating and testing a process. A zero (0) in this field causes the system to check for definition changes with each operation.
Private AR server Type the RPC socket number of a dedicated private server to RPC socket use when accessing the AR System server. Leave this field empty if you do not have a dedicated private server. Virtual web document directory Save Reset Cancel Type the path for the directory where Approval Web forms are stored. Click this button to apply changes. Click this button to reload the form with previously stored values. Click this button to close the dialog box without saving changes.
AP:Administration
273
Notifications tab
Figure C-6: AP:Admin-ServerSettings formNotifications tab
New signature, approve, reject, alternate approve, alternate reject, override approve, override reject, close approve, close reject, reassign, error, cancel, more info return, reject by later level, cancel at later level, reject by another approver, hold, more info, change after approval
On the Notifications tab, click Enabled next to an event to have the AR System issue a notification when such an event occurs. Disabled means Approval Server disables notifications for this event during an approval process. Enabled means the Approval Server enables notifications for the approver list when this event occurs during an approval process. Enabled Including Alternate (default setting) means the Approval Server enables notifications to the approver list as well as all active alternates when this event occurs during an approval process. These option buttons do not guarantee notifications occur for an enabled event. These settings enable notification as established elsewhere in the process rules.
Escalations tab
Figure C-7: AP:Admin-ServerSettings formEscalations tab
On the Escalation tab, click Enabled next to an event to have Still active, still the AR System issue an escalation when such an event occurs. active (repeat), still pending, still Disabled means Approval Server disables escalations for this pending (repeat), event during an approval process. still hold, still Enabled means the Approval Server enables escalations for hold (repeat), still the approver list when this event occurs during an approval more info, still process. more info Enabled Including Alternate (default setting) means the (repeat), still Approval Server enables escalations to the approver list as error, still error well all active alternates when this event occurs during an (repeat) approval process. These option buttons do not guarantee escalations occur for an enabled event. These settings enable escalations as established elsewhere in the process rules.
AP:Administration
275
AP:Alternate
Approvers use this form to create, delete, and maintain alternate approvers.
Alternate Information tab

Figure C-8: Alternate Approver formAlternate Information tab
Alternate For Start date End date
Type the name of the individual who is to receive the approval privileges. Type the name of the person for whom the Alternate will substitute. Open the calendar control to select the date on which the alternates authority begins. Open the calendar control to select the date on which the alternates authority ends.
Notify alternate
Use the menu list to 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 do the following tasks:
1 Create notifications on the New Signature notify on event. 2 Select Enabled Including Alternative on the Server Settings
form. Covering Select a value from this menu list to determine which processes are included in this alternates authority. All specifies that this alternate has authority to approve all processes where the original approver has authority. Specific Process specifies that this alternate has authority over only processes specifically noted in the Process field following. Process Enter the process for which the alternate has authority. Use the menu list to make sure you select only a process that exists on this server. This field contains the status of the alternate: Future means this alternate is not yet active. Current means the alternate is presently active. Past means the alternate is no longer active. Cancelled means the alternate record has been cancelled and the alternate is not active. Search Save Close In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
Status
AP:Administration
277
Administrative Information tab

Figure C-9: Alternate Approver formAdministrative Information tab
Alternate ID Create date Assigned to Help text Change history
The AR System populates this field with an AR System ID for this record. The AR System populates this field with the date this alternate was created. Type the name of the original approver assigning authority to this alternate. Type information to aid users who are setting up alternates. 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 The AR System populates this field with the name of the person who last modified this alternate. Modified date The AR System populates this field with the date of the last modification to this alternate.
AP:Detail
Process administrators use this form to track and override approval requests. In addition to the fields listed below, the AP:Detail form also includes Currency, Date and Time temporary fields for use in workflow to store intermediate results. For example, Currency Field 1 and Currency Field 2 are temporary fields of the currency type.
Important: New functionality was added to the AP:Detail form to enable workflow-based notifications.
Figure C-10: AP:Detail form
Application Request Process Comments
The AR System populates this field the name of the AR System application to be approved with this request. The AR System populates this field with the AR System ID for the request. The AR System populates this field with the name of the approval process of this request. Type any additional information to be recorded with the alternate assignment. This information becomes part of the permanent record for this request. Use the menu list to select the priority attached to this request. Each process defines the meaning behind Urgent, Normal, and Low. The AR System populates this field with the name of the person who requested the workflow to be approved. The AR System populates this field with the status of the request.
Priority
Submitter Status
AP:Administration
279
Approval audit
This field contains an audit trail of date, time, and approver when approval activity occurs to this request. This information becomes part of the permanent record for this request. Click this button to approve the request, overriding the regular approval process. You must have process administrator override authority to perform this action. Click this button to reject the request, overriding the regular approval process. You must have process administrator override authority to perform this action.
Global approve
Global reject
AP:Detail-Signature
Process Administrators use this form to track the history of responses to an approval request. In addition to the following fields listed, the AP:DetailSignature form also includes Currency, Date and Time temporary fields for you to use in workflow to store intermediate results. For example, Currency Field 1 and Currency Field 2 are temporary fields of the currency type.
Guide for Users and Administrators Figure C-11: AP:Detail-Signature form
Approval status
Use the menu list to select the status of the request. Pending means the Approval Server is waiting for a response to a request in progress. Approved means you approve the workflow associated with this request. Rejected means you do not allow the workflow to be approved, cancelling the request entirely. Hold means you are associated with this request but no Approval Server actions occur. More Information means you are waiting for a response to a More Information Request you submitted to supply you with more information before you can approve or reject this request. Cancelled means this request was withdrawn from the approval process. Error means this request has a problem that needs to be repaired before additional operations can be performed. Closed means this request is ended and operations can no longer be performed on it. Type your password for verification. the Approval Server verifies the contents of this field before a Save operation occurs. This field occurs only during Search and Modify, not when the record is created.
Password
AP:Administration
281
Approval priority Comments
Use the menu list to select the priority attached to this request. Each process defines the meaning behind Urgent, Normal, and Low. Type any additional information to be recorded with the alternate assignment. This information becomes part of the permanent record for this alternate. Type the names of the next approvers to see this request. Select how the approval process operates when many approvers appear in the Next Approver field. One must sign determines that only one signature is required from everyone indicated in the Next Approver field. All must sign determines that everyone indicated in the Next Approver field must approve the request. This option button is valid only if there is more than one entry in the Next Approver field.
Next approvers If multiple approvers
Reassign to Approvers Approval audit For application For request For process Submitter Approver signature Alternate signature
Type the name of an approver to whom you want to reassign this request. The AR System populates this field with the names of persons who have already approved this request. This field contains an audit trail of date, time, and approver when approval activity occurs to this request. This information becomes part of the permanent record for this request. The AR System populates this field with the name of the AR System application workflow to be approved with this request. The AR System populates this field with the AR System ID for the request. The AR System populates this field with the name of the approval process of this request. The AR System populates this field with the name of the person who originated this request. This field contains the name of the approver of this request. The name appears only after an authorized person modifies the Approval Status field. This field contains the name of the alternate approver who modifies the Approval Status field.
More information Show details More information
This field contains any requests for more information and the responses when they occur to this request. This information becomes part of the permanent record for this request. Click this button to open the form for the workflow the requester wants to be approved. Click this button to open the More Information form with which you can request additional information.
AP:Dtl-Sig-MoreInfoDialog
This underlying helper form is used to process the More Information records. You should access this information only through the Approval Central application.
Figure C-12: AP:Dtl-Sig-MoreInfoDialog form
Existing more information records New record Open Cancel
This field displays any More Information records attached to the current approval process. Use this button to open the More Information form and create a new More Information record. Click this button to open the currently selected item in the field preceding. Click this button to close the form.
AP:Administration
283
AP:Form
Process Administrators use this form to attach request forms to an Approval Server process.
Figure C-13: AP:form, Form tab
Form name
Type a form name or use the menu list to select a form on the current server.
Lookup keyword Type a keyword to enable easy identification when searching for this form. Used by Approval reporting Type the name of the AR System application that uses the form. Type the name of a form or use the menu list to select a form that users might search using the Application Approval Search button described on Approval Central application on page 268. Approval Reporting is an optional field. Search Save Close In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
See the description of Figure C-9 on page 278 for field definitions of the Administrative Information tab.
AP:More information
This underlying helper form is used to process the questions about an approval request. You should access this information only through the Approval Central application.
Figure C-14: AP:More information form
To
Name of the person you want the Approval Server to ask for more Information. Unlike some fields, this field can contain only one name. Name of the person who is asking for more information. This field is read-only once the record is saved. Question regarding the information you want. Read-only field for the More Information requester because it is reserved for the response.
From Question Response
AP:Administration
285
AP:Notification
Process administrators use this form to create and modify notifications sent by approval processes.
Basic tab
Figure C-15: Notification formBasic tab
Notification name Process name Status
Type a name for the notification. Type the name of the process. Use the menu list to make sure you select only a process that exists on this server. Use the menu list to select the status of the notification. Active Inactive
Notify on
Use the menu list to select an event in the approval process that triggers this notification.
Qualification
Type additional conditions to the event that triggers this notification. 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"
Search Save Close
In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
AP:Administration
287
Details tab
Figure C-16: Notification formDetails tab
Method
Use the menu list to determine the manner of notification. None sends no notification message. Alert notifies this person with AR System Alert. Email notifies this person through electronic mail. If the Send To field on this persons Notification form does not exactly match the name of an existing user, the system interprets the field as a literal address and sends the notification to that address. User Default notifies this person using the default notification method defined in their User record. If the User record does not contain a default notification method, AR System Alert is used. If you select Email or User Default, the Email tab is activated (see Figure C-17 on page 290).
Send to
Click this option button to determine who receives this notification. Notify List means the Approval Server sends default notifications. Other means you type manual notification recipients in the field to the right. Use the menu list to select a field reference (for example, $<field_name>$ for notification recipients. This field becomes activated when you select Other as the Send To option.
Subject
Type a subject line for the notification message. Use the menu list to select AR System variables to add to the subject.
Additional fields Use the menu list to select AR System variables to add to the additional fields. Message Type additional information to be the main body of the notification. Use the menu list to select AR System variables to add to the message. 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.
Priority
AP:Administration
289
Email tab
Figure C-17: Notification formEmail tab
Mailbox name
Type the name of the mailbox that you want to handle the notifications if you do not want to use the default mailbox. You can also use the Fields or Keywords menu list to substitute a mailbox name. Type the name to be displayed to indicate where the mail is from. You can also use the Fields or Keywords menu lists to substitute a name. Type the name of people you want to receive email replies. if you enter a group name, a reply will be sent to all the names in the group. You can also use the Fields or Keywords menu lists to substitute a name. Type names of people you want to receive copies of this notification. You can also use the Fields or Keywords menu lists to substitute a name. Type names of people you want to receive copies of this notification but whose names you want hidden from the other recipients. You can also use the Fields or Keywords menu lists to substitute a name.
From
Reply to
CC
BCC
Organization Type a company name, an organization, a keyword, or a field reference to a name that you would like to appear on the email. Header Type the names of the templates to use for a header of the email notification. You can enter the name of the template directly, or enter a field reference or keyword that leads indirectly to a template name. Type the names of the templates to use for the content of the email notification. You can enter the name of the template directly, or enter a field reference or keyword that leads indirectly to a template name. Type the names of the templates to use for a footer of the email notification. You can enter the name of the template directly, or enter a field reference or keyword that leads indirectly to a template name.
Content
Footer
AP:Administration
291
AP:PreviewInfo
Process administrators use this form to preview all the approvers assigned to work on an approval request. You must enter data into all these fields to use the AP:PreviewInfo form. See Previewing approvers on page 218 for a discussion of this form.
Figure C-18: AP:PreviewInfo form
Show for Process Request/ Ticket Number Retrieval Type
Selects which process the request belongs to. Entry number that you want previewed.
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 users will view formatted data with this form.
AP:Process administrator
Process administrators use this form to create, delete, and modify the abilities of other process administrators. The AR System administrator uses this form to create the first process administrator after installation. See Setting up administrator capabilities on page 125 for a discussion of this form.
Note: The first process administrator must be created by your AR System Administrator.
Figure C-19: Process Administrator Privileges formProcess Administrator tab
Individual Authority
This field contains the user name of the individual who is to be a process administrator. Use the menu list to select the privileges allocated to the individual in the field preceding. Full Admin grants this person full authority as a process administrator. Override Only Admin grants this person only the authority to override a process.
AP:Administration
293
Notify method
Use the menu list to determine the manner of notification. None sends no notification message. Alert notifies this person with AR System Alert. Email notifies this person through electronic mail. If the Send To field on this persons Notification form does not exactly match the name of an existing user, the system interprets the field as a literal address and sends the notification to that address. User Default notifies this person using the default notification method defined in their User record. If the User record does not contain a default notification method, AR System Alert is used.
Covering
Click this option button to determine the processes for which this person receives process administrator privileges. All Specific Process
Process name Status
Use the menu list to select a process name if you selected Specific Process in the Covering field preceding. Use the menu list to determine the status of this persons process administration privileges. Active Inactive
Search Close
Click this button to perform your search. Click this button to close the window.
AP:Process definition
Process administrators use this form to create and modify approval processes. See Using the Process Definition form on page 140 for a discussion about using this form.
Basic tab
Figure C-20: Process Definition formProcess Definition tab
Process Form
Type the name of this process. Type the name of the AR System form with workflow to be approved by this process, or select a form from the drop-down menu list. Use the menu list to select the process type for this process. See Approval process types on page 107 for a description of approval process types.
Type
AP:Administration
295
Status
Use the menu list to select the status of this process Active means this process currently generates approvals for the application determined in the application field preceding. Inactive means this process is disabled and generates no approvals for any application.
Request owner field First approver field
Type a valid user name or use the menu list to select the owner of a request in this approval process. Type in the name or use the menu list to select the approver to first see a request in this process. This field is required for Ad Hoc process type, optional if you allow Ad Hoc overrides, and otherwise unused.
Approval success Use the menu list to select the manner with which the Approval Server determines a request is complete. No More Approvers means a request is complete when all approvers have approved the request. Completion Rule means the request is complete when defined conditions have occurred. If multiple approvers Use the menu list to select the number of signatures required when multiple approvers appear on a signature line. One Must Sign means there is one signature line and the first approver to approve/reject a request determines the response. The request is withdrawn from the other approvers. All Must Sign means every approver on the signature line must approve the request. Allow Only One Approver means a response from more than one approver generates an error, and stops the approval process. Allow Ad Hoc next approver? Use the menu list to determine who can select an Ad Hoc next approver. Anyone means the requester and any approver can select an Ad Hoc next approver. Approver means any approver can select an Ad Hoc next approver. No one means this process never allows an Ad Hoc next approver.
For self assignment
Use the menu list to select what happens when the person who initiated the approval is not the owner of the request. Use Get Next Approver Rules uses the standard rules of the process. Assign to Owner if Approver assigns the entry to the owner of the request if that person is an approver. The Approval Server checks the Validate User rules to determine if the person is an approver. Always Assign to Owner assigns the entry to the owner for approval if this person did not request this approval.
Validate approvers? Require password? Search Save Close
Use the menu list to select Yes or No, whether Ad Hoc next approvers are validated before they can respond to a request. Use the menu list to select Yes or No, whether the approver must enter a password to save changes to an approval request. In Submit mode, click this button to perform your search. In Search mode, click this button to save your changes. Click this button to close the window.
AP:Administration
297
Signature Escalations tabs

Figure C-21: Process Definition formSignature Escalations tab
The three tabs (Normal, Urgent, and Low) on the Signature Escalation tab contain identical fields.
Use schedules Business calendar Use the menu list to select a workday schedule created on the form Business time workdays on page 315.
Holiday calendar Use the menu list to select a holiday schedule created on the form Business time holidays on page 315. Automatic action After interval Type a numeric value for the amount of time to pass before this notification occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days as the unit for the interval in the previous field.
Unit
Change state
Use the menu list to select the status you want to force on this request if there is no activity 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.
Notification: still outstanding First interval Unit Repeat interval Type a numeric value for the amount of time to pass before this notification first occurs Select the unit of Hours or Days for the interval in the previous field. 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. Select the unit of Hours or Days for the interval in the previous field.
Unit
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. 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. Select the unit of Hours or Days for the interval in the previous field. 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. Select the unit of Hours or Days for the interval in the previous field.
First interval
Unit Repeat interval
Unit
AP:Administration
299
More Information Escalations tab

Figure C-22: Process Definition formMore Information Escalations tab
Use schedules Business calendar Use the menu list to select a schedule created on the form Business time workdays on page 315.
Holiday calendar Use the menu list to select a schedule created on the form Business time holidays on page 315. Notification: still outstanding First interval Type a numeric value for the amount of time to pass before this action first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field. Select the unit of Hours or Days for the interval in the previous field.
Unit
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. Select the unit of Hours or Days for the interval in the previous field.
Unit
AP:Reserved word
Process Administrators use this form to create keywords and functions for approval processes.
Figure C-23: AP:Reserved word form
Name Name type Assignee Group Permissions
Type the name of the word you want to reserve. Click the option button to select whether the word is a keyword or function. Select name of special control group that you want to have access for row-level permissions.
AP:Role
Process administrators use this form to create role definitions within approval processes. See Defining roles on page 208 for a discussion about using this form.
AP:Administration
301
BMC Remedy Approval Server Figure C-24: AP:Role form, Role Information tab
Role name If multiple approvers
Type the name for this role. Use the menu list to select how the approval process operates when many approvers appear in the Member List field. One must sign determines that only one signature is required from everyone indicated in the Member List field. All must sign determines that everyone indicated in the Member List field must approve the request. This field is valid only if there is more than one entry in the Member List field.
Status
Use the menu list to select the status of this role. Active means this role currently can be used by any approval process. Inactive means this role is disabled for all approval processes.
Member list Search Save Close
Type the user name for each person to participate as a member of this role. Use ; as a separator. In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
AP:Rule Definition
Process administrators use this form to create and modify rules for approval processes. See Using the Rule Definition form on page 154 for a discussion about using this form. You can dynamically define the search criteria by using the EXTERNAL keyword.
Basic tab
Figure C-25: Rule Definition formBasic tab
Definition Rule name Type a name for this rule. The name of a rule 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. For process Rule type Use the menu list to select a process for this rule. Use the menu list to select the rule type. See Chapter 10, Defining approval rules, for a discussion of rule types.
AP:Administration
303
Status Order
Use the menu list to select the status of this rule. 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.
If multiple results Use the menu list to select the behavior when there are multiple results. Value from first uses the value from the first record retrieved. Value from all uses all of the values retrieved. Return Error produces an error message if more than one record is retrieved. If multiple approvers Use the menu list to select the behavior when there are multiple approvers. One Must Sign means the Approval Server requires only one signature when there are multiple signature lines. All Must Sign means the Approval Server requires a signature for every signature line when there are multiple signature lines. Next approver rule is Use the menu list to select the behavior when there are multiple Get Next Approver rules. Additive means this rule appends approvers to the existing approver list, and further rules are processed. Ending means this rule appends additional approvers to the existing approver list, but no further rules are processed. Exclusive means this 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 generally used for a rule-based process that has a set of Get Next Approver rules for building an approver list.
Qualification Run if This field label appears by default but also if you select following from Rule Type menu list: Get Next Approver Validate Approver Get Authority Get Authority Regular Get Authority Self Prep Get Next Approver Enter the qualification in the Run If field. Use the buttons and menu list to help. See Using the Rule Definition form on page 154 for a discussion of creating rules. 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"


"John" = "John"
Rule
This field label appears if you select following from Rule Type menu list: Auto Approval Self Approval Completion Rule Enter the qualification in the Rule field. Use the buttons and menu list to help. See Using the Rule Definition form on page 154 for a discussion of creating rules. 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"


"John" = "John"
AP:Administration
305
Audit text
Type any text you want to appear in the permanent record for the request whenever this rule executes. Use the menu list to select keywords to include in your audit trail message.
Rule state Approved, rejected, cancelled, error This field label appears if you select Approval Process Done from Rule Type menu list. Select one or more rule conditions from among the radio buttons. The rule executes when the approval detail record is put in the selected state. Search Save Close In Search mode, click this button to perform your search. In Submit mode, click this button to save your changes. Click this button to close the window.
Set Fields tab

Figure C-26: Rule Definition formSet Fields tab
Set Fields Type From Form
Use the menu list to select how the rule will populate this field type. Type the name of the form that contains the field you want to populate. Leave this field blank to use this rule on more than one form. This field is disabled with some options available in the Set Field Type field. Use the menu list to select the server that contains the form. Current means the form resides on the server with the Approval Server. Alternate means the form resides on another server indicated in the Server field. This field is disabled with some options available in the Set Field Type field.
On 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.
AP:Administration
307
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. Type a qualification or use the menu list to select AR System functions or keywords. Based on the Set Fields Type you choose, the Qualification field enables different query options. For example, choosing SQL causes SELECT, FROM, and WHERE buttons to appear so that you can more easily construct SQL statements. 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"
Qualification

the value from the current transaction will be returned, "John " = "John". Fields data Field name Type a field name or use the menu 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 to use for populating the field. The Value 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.
AP:Signature
Administrators can use this underlying helper form to review the responses to a request. However, you should modify this information only through the Approval Central application.
Figure C-27: AP:Signature form
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 names of persons who have approved this request.
More The AR System populates this field with the questions and answers information to More Information Requests. Approval status Next approver If multiple approvers The AR System populates this field with the status of the request. The AR System populates this field in an Ad Hoc situation with the name of the next approver. This option button is valid only if there is more than one entry in the Next Approver field. One must sign determines that only one signature is required from everyone indicated in the Next Approver field. All must sign determines that everyone indicated in the Next Approver field must approve the request.
AP:Administration
309
Alternate signature Approver signature Signature method
The AR System populates this field with your name if you are acting as alternate for this approval. Type the name of a valid approver to respond to this request. The AR System populates this field with the method by which this request was approved. Alternate means an alternate signed this request instead of a normally scheduled approver. Regular means a normally scheduled approver signed this request. Override means someone with process administration authority signed this request instead of a normally scheduled approver.
APW:Access Privileges
Approvers use this view on the web to create, delete, and maintain alternate approvers, and to log in as someone elses alternate. This form should not be used in BMC Remedy User. See Chapter 5, Processing approval requests with Approval Central, for a discussion of how to use this form.
Guide for Users and Administrators Figure C-28: APW:Access Privileges form
Approver The name of the individual who is to receive the approval (column in table) privileges. Click it to modify the alternate approver record in a separate window. Process name The process for which the alternate has authority. Blank if the (column in table) alternate has authority for all processes. Start date The date on which the alternates authority begins. (column in table) End date The date on which the alternates authority ends. (column in table) Status This field contains the status of the alternate: (column in table) Future means this alternate is not yet active. Current means the alternate is presently active. Add new approver (button) Click to add a new alternate approver.
AP:Administration
311
I would like to From the menu, choose the following: approve request: For Myself to log in as yourself and see your own approvals. For Someone Else and enter a name to log in as that persons alternate and see their approvals. As Override to see a list of the persons pending process records that you can approve or reject as the override approver. As Global Override to see a list of all pending process records that you can approve or reject as the global override approver. Change approver Click to make the new login effective. (button)
APW:Approval Central
Approvers use this view on the web as a launch pad to review their approval requests, access privileges, and More Information Requests. The fields in APW:Approval Central are not listed here because you customize this form as desired to fit your applications. See Chapter 5, Processing approval requests with Approval Central, for a discussion of how to use this form.
Guide for Users and Administrators Figure C-29: APW:Approval Central form
APW:More info requests

Approvers use this view with a browser to ask questions about a request. See Chapter 5, Processing approval requests with Approval Central, for a discussion of how to use this form.
AP:Administration
313
BMC Remedy Approval Server Figure C-30: APW:More info Requests form
More info ID The request ID of this More Information request. Click it to (column in table) view or respond to the request in a separate window. To The name of the person from whom more information is (column in table) being requested. From The name of the person who is asking for more information. (column in table) More info status The status of the More Information request. (column in table)
Business time holidays

Process Administrators use this form to determine the business holidays for use by approval processes and other AR System workflow.
Figure C-31: Business Time Holidays formHoliday Definition tab
Schedule name Holidays
Type a unique name for this holiday period. Type the dates included in this holiday period in the normal AR System format.
Business time workdays

Process Administrators use this form to determine the hours of business for use by approval processes and other AR System workflow.
AP:Administration
315
BMC Remedy Approval Server Figure C-32: Business Time Workdays formWorkdays Definition tab
Schedule name Open time
Type a unique name for this workday period. In the Time Schedules tab, type a numeric time to indicate the hour and minute your company opens for business for each day of the week. If you are not open on a day, for example weekends, leave the Open Time fields for those days blank.
Close time
In the Time Schedules tab, type a numeric time to indicate the hour and minute your company closes for business for each day of the week. If you are not open on a day, for example weekends, leave the Close Time fields for those days blank.
Offset hours Enter amount of time to offset the start time by. If not specified, defaults to 1. This field allows you to calculate business hours into the single 0-24 hour range required by the AR System server. Scheduling diary Type text to document how the offset adjustment was performed.
User form xxx

In general, there are no requirements on the users form for which the approval is requested. However, two temporary fields are required to allow the launching of the approval processing: Added fields: Display-only integer field to hold a status value Display-only character field (255 bytes) to hold a path name to a program You will need a filter or active link to initiate the approval process. If your user form requires multiple approval processes, you should include filters to allow launching and handling of the various processes, as well as additional fields to track status. For example, if you have a Computer Purchase Request, it might need approval by a management group, an MIS group, and a purchasing group. Requesters would find it useful to have status fields that indicate which of these separate approvals have completed.
AP:Administration
317
Appendix
Troubleshooting
This appendix contains troubleshooting information for the AR System Approval Server. The following topics are provided: Installation concerns (page 320) Approval Web concerns (page 322) Sample application concerns (page 322) Miscellaneous runtime concerns (page 323) Error messages (page 324)
Troubleshooting
319
Installation concerns
This section discusses known concerns regarding Approval Server installation.
Previous Approval Server installations

WARNING: Approval Server 7.0 is incompatible with the version of Approval Server bundled with certain Remedy applications. Do not install Approval Server 7.0 on a system with any of these 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.
Public group permissions

If you install the Approval Server without setting the Public Group (0) to Change privilege, approvers cannot change any fields except the Approval Status field and will see an ARERR 330 error when they attempt to approve or reject a request. To fix this problem, you must perform the following procedure and then reinstall the Approval Server. You need not delete Approval Server forms before reinstalling.
320 Appendix DTroubleshooting
To set public group permissions

1 Use BMC Remedy User to open the Group form in Search mode. 2 In the Group ID field, type the number 0. 3 Click Search.
The Public Group appears.

Figure D-1: Verify public group 0
Search for Group ID 0. Verify Group Type Change is set.
4 Verify that the Change option is set for the Group Type field. If this option is
not set, click Change and then click Save.
Application pending form

If the Application Pending form is not already present on your AR System, you must stop and restart the AR System server before you can start using the Approval Server.
Installation concerns
321
Errors not reported

The installer will not report errors encountered while importing forms and data, and it will not report that the Approval Server failed to start. To check for import errors: Examine the installation log located in <install_dir>\logs, where <install_dir> is the directory where the AR System server is installed. To make sure the Approval Server started successfully:
1 On Windows, open the Task Manager and look for the process
serverap.exe.
2 On Windows or UNIX, examine <install_dir>\Arserver\Db\arerror.log,
where <install_dir> is the directory where the AR System server is installed.
Approval Web concerns

This section discusses known concerns regarding Approval Web.
The Approval Central URL

The URL for the Approval Web Approval Central is special. You should not open your regular AR System mid tier login page to use the Approval Central form. See your AR System administrator for the exact URL; however, the default URL for a web server named acme that is accessing an AR System server named apex is:
http://acme/arsys/apps/apex/ApprovalCentral
or
http://acme.remedy.com/arsys/apps/apex/ApprovalCentral/
Sample application concerns

Sample users
You must license the sample users to perform the procedures in Chapter 6, Using a sample application.
Miscellaneous runtime concerns

Approver receives request but cannot respond
There is likely a misspelled approver name in the Validate Approver rule. This causes an approver to receive a request, but be unable to respond without producing the error message: You are not currently defined as an alternate for any user and you are not on the Approvers list for this approval (ARERR 10000).
Deadlocked approval server

The Approval Server offers the preview feature through an ARDBC plug-in interface. When this interface is accessed, the Approval Server makes a call back to the AR System server to retrieve and compile information. Sometimes this action creates a dead lock, and the 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 the Approval Server. If you do not configure this, the preview feature will not work. The RPC number reserved should be specified in the ar.cfg file with the following settings:
Plugin-Loopback-RPC-Socket: <number>
or:
Approval-RPC-Socket: <number>
If both are specified, the Approval Server will use Approval-RPC-Socket: setting.
Miscellaneous runtime concerns
323
Error messages
These error messages are specific to the Approval Server.
4500 AR System Application server terminated when a signal/exception was received by the server. The approval engine was terminated by a signal. The process was terminated either accidentally or intentionally by a user in your environment. The number following this error is the signal that was received. If the signal is 15, you should be able to restart the server and continue to work. 4501 AR System Application server terminated -- fatal error encountered. A fatal error occurred within the approval engine. The details about that error are in an associated message. This message indicates that the error was fatal, and the approval engine is shutting down. 4502 Operation cancelled due to error. The command could not be performed due to an unspecified error. The command that failed is included in this message. 4503 4510 AR System Approval Server restarting. Two or more roles have the same name. The system encountered two or more entries in the Approval Role form for the name specified. The system does not allow this to exist. One name must be deleted or changed. The name is included in this message. 4511 No Approval Administration form was found. The system was unable to locate the Approval Administration form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted. 4512 No Approval Notification form was found. The system was unable to locate the Approval Notification form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted. 4513 No Approval Form form was found. The system was unable to locate the Approval Form form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4549
Confirming password is not valid for the current user. The approval process is configured to require the user to enter their password to approve or reject a request. The password either was not supplied, or the supplied password was not valid for the user performing the operation.
4550
Problem encountered during creation of one of the application forms. During the creation of the Application Pending form, an error occurred. There is an associated error message with the details of the problem. Correct the reason for the failure, and restart the arserverd process (or sent a SIGHUP signal) to recreate the form.
4551
Must be Application Server user to perform this operation. You must be the user (process) AR System Application Service to run the specified delete operation and mapping forms. The forms should be considered part of the system structure and should not be deleted or modified. To delete one or both of these forms, use AR System Administrator to select the forms for deletion, and ignore the system warning related to the forms.
4552
Two forms containing all the reserved application pending fields encountered -- delete one to continue. The System encountered two forms that have all the reserved application pending fields. The system cannot work correctly if there are two forms containing pending information. Delete one of the forms, or change it so that it is not considered an Application Pending form by removing fields in the 250 to 260 range. The two forms are identified in an associated message.
4553
No Application Pending form could be found on the server. An Application Pending form is required for the System to support application operations. No form containing all the special reserved application pending fields could be found. Load the Application Pending form.
4554
Failure during an attempt to perform an application command. The System received a request to record a command or encountered a situation in which it attempted to automatically record one, and a failure was encountered during recording. Thus, the command was not performed. The command that was attempted is displayed with this message, and an associated message contains more information about the failure.
4555
Command requires a form name be specified. The parsing or formatting command requires a form name. None was specified. Check the syntax of the command and enter a form name as required.
4556
Form name specified on command is not valid. The form name specified is not a valid form on the system. The form name specified must be the name of an existing form.
Error messages
325
4557
Parse set fields command requires two forms be specified. The parse set fields command requires that two forms be specified. Either none, or only one, was specified.
4558
Qualification line error. An error was detected in the qualification line. There is additional information indicating the error and the position in the qualification where the error occurred.
4559
Assign line error. An error was detected in an assignment line. There is additional information indicating the error and the position in the assignment where the error occurred.
4560
No Approval Details form could be found on the server. A request was made for finding forms joined to the Approval Details form. However, there is no Approval Details form on the system. Generally, this means that the Approval subsystem is not installed. The command is not valid without the Approval subsystem.
4561
Command requires a field name be specified. The command requires that a field name be specified. Review the syntax and retry the command with the appropriate field name specified.
4562
Field name specified on command is not valid. The field name specified for the command is not a valid field name within the indicated form. The command requires that a valid field name be specified.
4563
Command requires a entry ID be specified. The command requires that a Request ID be specified. Review the syntax of the command, then retry the operation.
4564 4565
Entry ID specified on command is not valid. The Request ID specified for the command is not a valid Request ID. No Approval Signature form could be found on the server. A request was made that requires access to the Approval Signature form. However, there is no Approval Signature form on the system. Generally, this means that the Approval subsystem is not installed. The command is not valid without the Approval subsystem.
4566
No Approval Detail-Signature join form could be found on the server. A request was made that requires access to the Approval Detail-Signature form. However, there is no Approval Detail-Signature form on the system. Generally, this means that the Approval subsystem is not installed. The command is not valid without the Approval subsystem.
4577
No Approval Server licensecannot run the approval engine. The Approval Server checks licensing to determine if a server is licensed for approval functionality. For there to be an approval license, there must be a valid server license. This is because the server license is the base license of the product and the approval license is an option. Check to make sure that the server license is valid and implemented.
4578
There are two forms with the same license tag. Limited licensing for approvals and the system encountered two forms with the same license tag. Only the first form found with the given tag will be loaded.
4579
Limited licensing for Approvals and no form was found linked to any license. Limited licensing is in effect for approvals, and the system was unable to find any form with the tags in the limited license tag list. This is an error condition.
4580
Form is not licensed to work with the approval engine. Limited licensing for approvals and the system was unable to find a license in the limited license tag list for the form specified. The form name is identified in this message.
4581 4582 4583
Malloc failed in Approval Server. Another copy of the Approval Server is already running or the Application Dispatcher is in use. Error while opening the Approval Server lock file. The system encountered an error while attempting to open the Approval Server lock file <arserver_install_dir>\arserver\db\ar.lck.390609.
4584
There are two forms identified as the Approval Detail form. The system encountered two forms designated as the Approval Detail form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4585
There are two forms identified as the Approval Signature Line form. The system encountered two forms designated as the Approval Signature Line form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4586
No Approval Signature Line form was found. The system was unable to locate the Approval Signature Line form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
Error messages
327
4587
There are two forms identified as the Approval Process Definition form. The system encountered two forms designated as the Approval Process Definition form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4588
No Approval Process Definition form was found. The system was unable to locate the Approval Process Definition form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4589
Command requires form and entry ID be specified. Parameters are missing from the command to the Approval Server. An associated message with the actual command has been sent to the Approval Process administrator.
4590
There are two forms identified as the Approval Rule Definition form. The system encountered two forms designated as the Approval Rule Definition form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4591
No Approval Rule Definition form was found. The system was unable to locate the Approval Rule Definition form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4592
There are two forms identified as the Approval Alternate form. The system encountered two forms designated as the Approval Alternate form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4593
No Approval Alternate form was found. The system was unable to locate the Approval Alternate form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4594
There are two forms identified as the Approval More Information form. The system encountered two forms designated as the Approval More Information form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4595
No Approval More Information form was found. The system was unable to locate the Approval More Information form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4596
There are two forms identified as the Approval Process Administrator form. The system encountered two forms designated as the Approval Process Administrator form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4597
No Approval Process Administrator form was found. The system was unable to locate the Approval Process Administrator form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4598
There are two forms identified as the Approval Role form. The system encountered two forms designated as the Approval Role form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4599
No Approval Role form was found. The system was unable to locate the Approval Role form. Generally this means that the Approval subsystem is not installed. The form is found by searching for a form with a specific tag in the Change History field, so it could also be possible that the Change History field has been corrupted.
4600
Cannot create new approval detail as is already an active detail entry. An approval is already in progress for the indicated approval process and entry ID, so a new approval detail entry will not be created.
4601
Multiple rows matched next approver condition and configured to error. More than one Next Approver record was returned for the entry, and a Get Next Approver rule for the approval process is configured to return an error when multiple rows are returned. The operation has stopped. You must either change the rule to allow multiple next approvers, or specify only one next approver for this entry.
4602
AR System server does not support AR System Application Service user. This can occur when using AR System 5.1 with Approval Server 4.x. Either upgrade your Approval Server to 5.1 or remove your AR System Application Service password.
Error messages
329
4603
Field specified for first approver is not defined on the form. The field defined to specify the first approver for the process does not exist on the application form. The field ID is appended to this message. If the process is defined as Ad Hoc, the operation has stopped. If the process is defined so that Anyone can specify the next approver (see Creating a process on page 140), the operation continues after this warning.
4604
Sig-xxx command requires form to be the approval signature line form. The command issued (sig-approved, sig-rejected, sig-cancelled, sigreassign, sig-notify) must come from the AP:Signature form.
4605
Sig-xxx command requires process to match details if process is specified. The process specified in the command issued (sig-approved, sig-rejected, sigcancelled, sig-reassign, sig-notify) does not match the process specified in the details record of this pending approval request.
4606
No process specified but there are two or more for form so cannot continue. Your application has two or more approval processes configured for it, but the command issued (Add-sig or New-details) did not specify which one to use for the new approval.
4607
Process allows only one next approver but two or more were specified. The process was configured to allow only one approver, but more than one approver was entered in the Next Approvers or Reassign To field.
4608
MoreInfo-xxx command requires form to be the More Information form. The MoreInfo-Return command issued must come from the AP:More Information form.
4609
A process was specified but no process by that name exists. The process specified in the AP:Notification entry or in the command issued (Addsig, New-details, sig-approved, sig-rejected, sig-cancelled, sig-reassign, or sig-notify) does not exist.
4610
No active process is associated with this form. No process is associated with your approval application form, so the operation has stopped. You must configure a process for a form before using it for approvals.
4611
No join is defined between the form and the approval detail form. Before you use the Approval Server with your application you must join your application form to the AP:Detail form. Instructions for this are provided in Chapter 13, Adding approvals to your application.
4612
No join is defined between the approval detail and signature line forms. Before you use the Approval Server with your application you must join your application form to the AP:Detail-Signature form. Instructions for this are provided in Chapter 13, Adding approvals to your application.
4613
Update-Config command requires tag. The Update-config command issued did not have any tag for the config parameter. If you are making approval configuration changes in the Server Settings form, try again.
4614
Failure trying to map names to IDs in a string. The field names specified in the Send to Other, Subject and Message fields in the AP:Notification entry could not be converted to their field IDs. The actual error is appended to this message.
4615 4616
Failure trying to retrieve join of a form with Detail-Signature. See error number 4612 on page 331. There are two forms identified as the Approval Administration form. The system encountered two forms designated as the Approval Administration form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4617
There are two forms identified as the Approval Notification form. The system encountered two forms designated as the Approval Notification form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4618
There are two forms identified as the Approval Form form. The system encountered two forms designated as the Approval Form form. The system does not allow this to exist. One of the forms must be deleted for the Approval system to work correctly. The two forms are identified in an associated error message.
4650 4651 4652 4653 4654
The Completion field is required on Detail form but is not present. The field Completed?, ID 13004, is missing from the AP:Detail form. The Form field is required on Detail form but is not present. The field Application, ID 10050, is missing from the AP:Detail form. The Entry ID field is required on Detail form but is not present. The field Entry ID, ID 8, is missing from the AP:Detail form. The Next Approver field is required on Sig Line form but is not present. The field Next Approvers, ID 13205, is missing from the AP:Signature form. The Process field is required on Detail form but is not present. The field Process, ID 10000, is missing from the AP:Detail form.
Error messages
331
Appendix
Installation directory structures
This appendix contains the information about Approval Server installation directories. The following topics are provided: Default installation directories (page 334) Directory structure for Windows installations (page 334) Directory structure for UNIX installations (page 335)
Installation directory structures
333
Default installation directories

Without intervention, the Approval Server installs files into the following default directory, depending on your platform.
Platform Windows UNIX Directory
C:\Program Files\AR System\Approval /usr/ar/<AR_System_server_name>/approval
Directory structure for Windows installations

Approval Server 7.0 files for Windows
AR_Server_Install_Dir (for example, C:\Program Files\AR System) | arapi70.dll | arjoinfix.exe | arrpc70.dll | arutl70.dll | icudt32.dll | icuuc32.dll | arapprove.dll | xerces-c_2_6.dll | xerces-depdom_2_6.dll | Xalan-C_1_9.dll | XalanMessages_1_9.dll | +---Approval | +---templates | | | *.arm | | | *.arx | | | *.def | | | *.imp | | | *.lst | | | *.xml | | | +---Logs | | ApprovalServer.html | | ApprovalServer.log | | ApprovalServer_debug.dbg | | ApprovalServer_error.dbg | | getgroup,result | | getsvrinfo.result
334 Appendix EInstallation directory structures
Directory structure for UNIX installations

Approval server 7.0 files for UNIX
AR_Server_Install_Dir (for example, /usr/ar) | +---approval | | | +---bin | | | ar_apuninstall | | | arapprov | | | arjoinfix | | | arservapd | | | riklite | | | +---Logs | | | ApprovalServer.html | | | ApprovalServer.log | | | ApprovalServer_debug.dbg | | | ApprovalServer_error.log | | | +---templates | | *.arm | | *.arx | | *.def | | *.imp | | *.lst | | *.xml
Directory structure for UNIX installations
335
336 Appendix EInstallation directory structures
Glossary
access control active link
A security feature in which AR System administrators limit the access users have to forms, to specific fields or records within a form, to workflow, and to specific functions within the system. See also group, permission, user.
action request
An ordered sequence of active links that together accomplish a specific operation. Active link s can help lead users through a task (like a wizard) or can be used as subroutines to accomplish common tasks. Compare with filter.
Ad Hoc
A collection of information that describes something, such as a problem or a service request. See also approval request.
Action Request System (AR System)
Adaptable client/server software that provides a foundation for creating applications that can automate, track, and manage a wide variety of business processes.
active link
An approval process type with no predictable routing, in which each approver selects the subsequent approver. See also Parent child, level, and rule-based process types.
administrator
See AR System administrator; process administrator.

administrator default
A workflow component that causes a AR System client to perform specific operations in response to specific user actions. They are generally used to assist users with interactions with the system. Active links run on the client machine.
The value that AR System administrators assign to a field while designing a form. When users set defaults, this value is automatically entered in the field. Users can override the administrator default by assigning their own default or by entering a different value. See also user default.
Glossary
337
Administrator group
application
One of several special access control groups that the AR System provides. Members of this group have full and unlimited access to the AR System including unlimited ability to create definitions and access and modify data. See also Subadministrator group.
advanced search bar
The row of buttons, the Search Criteria field, and the Fields menu list that appear at the bottom of the BMC Remedy User Detail pane when you click the Advanced button in BMC Remedy User. You can use this bar to specify complex search criteria.
alert
A group of forms and the associated workflow collected by an administrator that are related to a business function; for example, Employee Care or Help Desk. An application is also a server object in BMC Remedy Administrator. An application can include one or more AR System forms that contains entries that need to be approved.
application program interface (API)
A notification from an AR System server or other program to the user that certain conditions have occurred, such as a request has been submitted or progress has been made in resolving a request.
alert list
A set of functions that provides application programmers with access to the full functionality of a product. The AR System API is documented in the C API Reference guide.
approval process
A procedure that generates all necessary signatures for authorizing a particular AR System application form.
approval process done
The list of alerts belonging to a user that can be displayed in BMC Remedy User or on a web client.
alternate
A rule type used to update the request when the approval process is done. These rules are used to indicate the result of the approval process to the original request.
approval request
An AR System user with the authority to substitute for an approver within an approval process.
alternate approve
A specific instance of an approval process for authorizing a particular AR System application form.
Approval Server
An indication for notifications when an alternate has responded with an approval.

alternate reject
An indication for notifications when an alternate has responded by rejecting a request.

API
A module within the AR System which routes forms to generate appropriate signoff signatures. The Approval Server also creates an audit trail for authorizing AR System application forms.
approved
See application program interface.
The status of a completed approval request when all approvers have responded with agreement.
338 Glossary
approver
Assignee group
An AR System user with the authority to sign for an approval process.

approver list
The list of approvers eligible to respond on signature lines for an approval process.
ARDBC
See AR System database connectivity.

AREA
One of several special access control groups that the AR System provides. Users automatically belong to this implicit group for requests for which they have been assigned responsibility (that is, their name is in the Assigned To field). See also Assignee Group group, Submitter group.
Assignee Group group
See AR System external authentication.

AR System
See Action Request System.

AR System administrator
An individual responsible for the management of the AR System, including setting up forms, setting access rights for users, and designing the workflow process. See also process administrator.
AR System client
One of several special access control groups that the AR System provides. Users automatically belong to this implicit group for requests for which they are a member of a group assigned responsibility (that is, they are a member of a group whose name is in the Assignee Group field). See also Assignee group, Submitter group.
attachment data type
The subset of AR System software that enables users to access an AR System server.
AR System database connectivity (ARDBC)
The data type used for fields that need to hold files. This type enables you to store text, graphics, audio, or video attachments in the database.
attachment pool field
A mechanism by which the AR System server uses a plug-in to access data stored externally to the AR System database as if it were within the AR System.
AR System external authentication (AREA)
A field that contains a set of one or more related attachment fields to organize attachments associated with an action request.
auto approval
A mechanism by which the AR System server can access and use authentication services from outside the AR System environment. A plug-in is developed to allow access to the external subsystem.
AR System server
A rule type that allows for automatic approval of a request for any submission that meets specified criteria.
The subset of AR System software that provides the data storage and main processing environment for the AR System.
Glossary
339
BMC Remedy Administrator
BMC Remedy User
The AR System client tool used by AR System administrators and subadministrators to set up the system for users. Use AR System Administrator to create and change structure definitions. AR System Administrator is also used to set access permissions that determine which users and groups can view or modify each form or specific parts of a form.
BMC Remedy Alert
The AR System client tool in which users enter and track requests through the resolution process. Users can also search the database, generate reports, and modify existing requests.
button field
A field on a form that a user can click to execute an active link. A button, image, or hyperlink can represent a button field. See also menu item, toolbar button.
cancel at later level
The AR System client tool through which an alert can be sent to a user. See also notification.
BMC Remedy Configuration Tool
An indication for notifications when an approval process is cancelled after it has been approved by a previous approver.
cancelled
The tool used to configure and manage the mid tier portion of the AR System.
BMC Remedy Email Engine
The status of a completed approval request which was withdrawn by the requester.
chained approval process
A server-based application that communicates with both the AR System server and an email server. The BMC Remedy Email Engine receives emails, and can parse and interpret these messages to execute specific instructions on an AR System form. It also sends emails the AR System and directs notifications as a result of filters and escalations.
BMC Remedy Import
A sequence of approval processes which appear to the user as one approval, but in fact are made up of many separate approval processes.
change flag
A status flag set when the contents of a field or form have been altered. A change flag can be polled or disabled by workflow.
character data type
The AR System client tool that enables AR System administrators to transfer data records from an archive file into a form.
BMC Remedy License
The data type used for fields that contain alphanumeric text.
character menu
The AR System client tool used to apply and review software licenses that activate features of the AR System software.
A menu that the AR System administrator can create to provide assistance with filling in values for a field. You can attach a menu to any character field. See also dynamic menu.
client
See AR System client.
340 Glossary
client tier
control panel
The architecture level where AR System clients operate within the multitier system.
close approve
A form used as a centralized entry point from which users choose the business tasks they want to accomplish.
core field
An indication for notification when a request has multiple possible approvers and another of the approvers approves the request.
closed
One of a set of basic fields common to all AR System regular forms. AR System administrators cannot remove these fields from a regular form.
Customize group
The status of an approval request that has been resolved and is no longer waiting for an approver or more information response.
close reject
An indication for notification when a request has multiple possible approvers and another of the approvers rejects the request.
command-line option
One of several special access control groups that the AR System provides. This group grants users the right to customize their form layout in BMC Remedy User.
data field
A parameter used to specify an operation or option to AR System tools when they are run.
completion rule
A field that stores data in the database. Data fields include character, date/time, diary, integer, real, decimal, selection, and attachment.
data tier
A rule type that checks whether conditions exist to stop routing a request. If a completion check is successful, then no new approvers will see the request. The request might not be done, but the request has been routed to everyone who must respond.
container
The architecture level that contains data and communicates with the AR System server. The data can be stored in a text file, spreadsheet, or database internal or external to the AR System.
data type
The underlying data structure for s and applications. A component of the AR System used to store collections of objects. Used as the basic storage structure for applications, active link s, filter s, and packing lists.
control data type
The property of a field that determines the characteristics of the field and what type of information (if any) the field contains.
date/time data type
The data type used for fields containing date/time timestamp values.
decimal data type
The data type for fields that execute active links. These fields do not contain data.
A field that accepts and contains fixed-point numbers. This type of field enables you to store quantitative information in a request.
default
See administrator default, user default.
Glossary
341
Details pane
dynamic data exchange (DDE)
The part of the main window in BMC Remedy User that displays fields for entering or viewing data.
dialog box
An interapplication communication feature used in Windows applications. For more information, see your Windows documentation.
dynamic menu
A message displayed to users that must be responded to before users can continue filling out a form. The administrator creates a dialog box by using an active link action.
diary data type
The data type used for fields that enables you to capture a history of the actions taken for a request. The field stores character data. It is an append-only field, and each addition is stamped with the time, date, and name of the user who entered the item.
display-only field
A menu that causes a search to be performed when a user selects the menu button. The results of the search are used to build the list of items from which the user can choose. See also character menu.
entry
A row in the database that represents a request.

error
A temporary field for which no space is allocated in the database. See also global field.
display-only form
The status of an incomplete approval request in which routing problems have occurred.
escalation
A type of form containing display-only fields. Display-only forms are used to create control panels and dialog boxes.
distributed server
An AR System server that exists within a multiserver, distributed environment. See also Distributed Server Option.
Distributed Server Option (DSO)
A workflow component that searches at specified times or at regular intervals for requests matching a specified condition and performs specified operations on all matching requests. They are generally used to find records that have exceeded desired business rules or processes and take appropriate action. Escalations run on the AR System server.
event
An AR System server option to send and receive data from both similar and dissimilar forms on physically separate servers. DSO requires a separate usage license. See also distributed server.
done
See approval process done.
An occurrence in the AR System that can serve as a trigger for other events or workflow. Examples include user interactions with an AR System form (such as opening windows, tabbing from field to field, switching row focus, and so on), state transitions of requests, or any condition that arises while manipulating a request.
342 Glossary
export
filter API
1. The AR System Administrator command that transfers definitions in a file; for example, forms, filters, active links, and mail templates. 2. The ability to transfer one or more data entries to a file for archive or transfer by using the reporting feature in BMC Remedy User. See also import.
field
An AR System plug-in API that allows inline access during filter and escalation processing to extended servers.
filter
An ordered sequence of filters that together accomplish a specific operation. Filter s can be used as a subroutine to accomplish common tasks. Compare with active link.
fixed license
In the AR System, the main entity of a form. All of the following are AR System fields: data, table, page, active link control (buttons, menu items, and toolbar buttons), and trim.
field ID
A license permanently assigned to a user, enabling access to the licensed features of the AR System at any time. See also floating license, write license.
floating license
A unique numeric identifier that is assigned to each field. Once assigned, it cannot be changed.
field label
A name supplied by the administrator that describes the fields purpose. Intended for display to the user.
field name
A license that is temporarily allocated to a user who requests a license and who is defined as using a floating license. If no floating license is available at the time of the user request, the user must wait until a license becomes available. See also fixed license, write license.
form
A unique character identifier that is assigned to each field. The name can be changed at any time as long as the new name is unique.
file menu
A menu with items retrieved from a file that contains a formatted character menu.
filter
A collection of fields that represents a record of information in the AR System. AR System administrators can define and change the fields and workflow associated with a form. An AR System application can include many forms.
form action field
A workflow component that tests every server transaction for certain conditions and responds to the conditions by taking specific actions. They are generally used to check and enforce business rules and processes. Filters run on the AR System server.
One of a set of special fields that provide the standard functions of the web client interface. Some of these include submit, query, modify, and the advanced search bar.
Glossary
343
form view
global field
The screen layout for a form, which appears in the Details pane of BMC Remedy User. AR System administrators can create and name multiple form views, which can be further modified by users with Customize permission. Administrators can include different fields and can hide fields in various form views.
function
A display-only field used in multiple forms. The value contained in the global field is duplicated across all forms that contain the field.
group
A named procedure that performs a distinct service in the AR System. The AR System API has a set of function calls used to accomplish AR System tasks. Additionally, there are table functions that you can use to perform mathematical operations on table data.
get authority
A category in the AR System used to define user access to form fields and functions. The AR System defines several special groups: Public, Administrator, Subadministrator, Customize, Submitter, Assignee, and Assignee Group. You can define additional groups through the Group form. See also access control, permission, user.
Group form
The form in which you add new groups, delete groups, and modify group permissions.
guest user
A rule type that gathers information about the current approver or environment that is used by subsequent self-approval or completion rule tests.
get authority regular
A rule type that gathers information about the current approver or environment that is used by subsequent completion rule tests. Note that these rules are not run before selfapproval tests.
get authority self
An unregistered user with a limited set of capabilities (submit requests and possibly review those requests). The administrator can specify whether unregistered users are allowed at your site.
See active link
And filter.
hidden field
A rule type that gathers information about the current approver or environment that is used by subsequent self-approval rule tests. Note that these rules are not run before completion tests.
get next approver
A field that exists but is not visible in a users view of the form.
hold
A rule type that finds the next approvers in the current process, including the first approver at the start of processing.
An indication for notifications when a request is changed to the Hold status. This is also a status where an approval request is assigned to an approver but no Approval Server activity occurs.
344 Glossary
import
level
1. The AR System Administrator command that transfers definitions from an export file to the current server. 2. The AR System import command that transfers one or more data entries from an archive file to a form. See also export.
integer data type
The data type used for fields that contain numeric values between 2147483647 and 2147483647. The range for a field can be limited by the AR System administrator.
join form
An approval process type with no fixed relationship between the approvers, but rather some relationship based on their membership in some group. Often used with approval processes requiring consensus from set of committees where the individuals are related only by their membership on the committees. See also Parent child, Ad Hoc, and rulebased process types.
license
A type of form that contains information from two or more AR System forms. Although join forms function similarly to regular AR System forms in most respects, they do not store independent data. Join forms point to the data stored on the AR System forms that were used to create the join form.
keyword
See fixed license, floating license, read license, write license.

macro
A set of operations within BMC Remedy User recorded for later execution. Macros are useful for automating frequently used or complex operations.
macro bar
A variable whose value is defined by the AR System. For example, $USER$ represents the name of the user that is currently logged in. Keywords can be used in defining qualifications for searches, search menus, workflow, and macros; or for specifying a value in the Set Fields action for active links, filters, and escalations.
The row of buttons below the menu bar in BMC Remedy User that enables easy access to commonly used macro commands. Macro commands are also available from the Tools menu.
mail template
A template that enables you to submit a request by using electronic mail. The AR System administrator generates templates from an existing form by using the export command.
main form
A form that users interact with directly. An application might use more than one main form. Main forms are sometimes called primary forms.
Glossary
345
main window
ODBC
The BMC Remedy User window that displays a form in the Details pane and, optionally, the results of a search in the Results pane and prompt text in the prompt bar. The main window includes a menu bar and optional status bar, toolbar, and macro bar.
menu item
Open Database Connectivity (an SQLbased communication standard developed by Microsoft)a connectivity solution that enables the AR System to communicate with ODBC clients.
override approve
A command accessed from a menu.

mid tier
An indication for notifications when a process administrator has approved a request in a manner that circumvents the normal process.
override reject
The architecture level consisting of add-in services that communicate between AR System servers and various clients. BMC Remedy User can communicate directly with AR System servers. However, browser clients must use the mid-tier addin services to communicate with AR System servers.
more information
An indication for notifications when a process administrator has rejected a request in a manner that circumvents the normal process.
packing list
A set of associated server objects that can be viewed as a work space in the server window or used in external utilities.
page field
An approvers query for additional data that becomes part of the audit trail of the approval request. The approver is not required to delay the approval request until someone responds.
more info return
A type of field that provides an area to group related fields. See also page holder field.
page holder field
An indication for notifications when a more information request has been responded to.
new signature
A field that contains one or more page fields that allows display of one of the grouped field sets at a time in a given area of the screen.
parameterized get next approver
An indication for notifications that a new signature record has been created with an individual as an approver.
notification
A message to a user from workflow. Notifications can be alerts, email messages, or other methods using integrations.
A rule type that finds the next approvers in the current process, including the first approver at the start of processing. This rule lets you add additional Ad Hoc approvers to any stage in an approval process.
346 Glossary
parent-child
process administrator
An approval process type with a fixed relationship between approvers, such as found in a management hierarchy. See also level, Ad Hoc, and rule-based process types.
pending
An AR System user who is a member of the Approval Admin group (402) and has authority to set up and maintain approval processes. See also AR System administrator.
prompt bar
The status of an incomplete approval request that is waiting for response from an approver or more information.
permission
The part of the main window in BMC Remedy User that displays instructions or useful information about the form it is attached to.
Public group
The property setting that enables AR System administrators to control who can view and change individual fields of a form. Administrators also set permissions for forms, active links, active link s, and applications. See also access control, group, user.
plug-in
One of several special access control groups that the AR System provides. Every user is automatically a member of this group.
qualification
An auxiliary program that works with the AR System server to enhance its capability. A plug-in is a dynamically linked library (DLL) on Microsoft platforms and a shared object on UNIX platforms. The plug-in service loads the plug-in at runtime.
plug-in service
A search criteria including field references, values, and arithmetical and relational operators used to find a set of data that matches the conditions specified.
query-by-example (QBE)
A server that loads plug-ins. The plug-in service is a companion server to the AR System server that loads the ARDBC, AREA, or Filter API plug-ins at runtime.
preference server
A method for describing a database search visually. An empty form is displayed and the search conditions are typed in or selected in their respective fields. The AR System turns the visual query into the proper command language, such as SQL, necessary to interrogate the database.
read license
An AR System server that stores user preferences centrally in one or more preference forms.
prep get next approver
A license that allows a user to search the AR System forms and to submit new requests but does not allow the user to modify existing requests. See also write license.
real data type
A rule type that gathers information to be used by the get next approver rules.
The data type used for fields that contain floating-point numbers. The range and precision can be set by the AR System administrator.
Glossary
347
reassign
reserved field
An action for an approver to reroute a request by changing the assigned approvers.

regular form
One of a set of fields with specific rules and interpretations that are defined by the AR System.
results list
A form used to manipulate and display data. These forms and their contents are stored in database tables created, owned, and managed by the AR System server.
reject by another approver
An indication for notifications when there are multiple required approvals outstanding and one of the other approvers rejects the request.
reject by later level
1. A list of requests that match a search. 2. An AR System server object for displaying search results that can be added to forms and views. Multiple rows (for example, requests) in the results list that meet specified criteria can be selected for further processing.
Results pane
An indication for notifications when an approval process is rejected by an approver after it has been approved by a previous approver.
rejected
The part of the form window in BMC Remedy User that displays the results of a search.
role
The status of a completed approval request when an approver has disagreed.

related workflow
A named alias for one or more approvers. Allows the definition of a position regardless of the individual approvers who are currently fulfilling that position.
rule-based
Workflow objects that are related to a field.

request
See action request, approval request.

Request ID field
The core field on a form that contains the unique numeric identifier for a request or entry in the AR System. In join form entries, the Request ID field contains the Request ID field contents for each of the underlying forms, separated by a vertical bar. Previously called an entry ID.
requester
A custom approval process type set up by the process administrator. There are no assumptions about relationships between approvers. Everything is built into the rules. See also Parent child, level, and Ad Hoc process types.
search
The process in which users display a subset of requests according to search criteria that they define.
search menu
A user who submits a form that requires authorization, triggering the Approval Server.
A menu whose items are based on data retrieved from a search of an AR System form.
348 Glossary
selection data type
statistical override
The data type used for fields with a set of mutually exclusive choices. The selections are displayed as option buttons or as a list of items.
selection list
A rule type that is used to preempt the default behavior of the approval process and follow an approve or reject path before all pending signatures have been completed.
status bar
A list that appears when an active link performs a search that returns more than one request.
self-approval
The part of a main window in an AR System client that displays instructions or useful information to the user.
Status field
A rule type that allows for automatic approval of a request if the submitter of the request has sufficient authority for the request to be approved.
server
The core field in which the AR System tracks the various stages of the resolution process for a request.
status history
See AR System Server.

server tier
The architecture level consisting of the AR System server that controls access to the data and any supporting services called by or used by the AR System server.
signature accumulator
Information that shows what progress has been made on a request. Users can view status history from any display showing the contents of an entry.
subadministrator
An individual with limited administrative access to the AR System as defined by an administrator.

Subadministrator group
A rule type that is used to collect statistical information about the signature records associated with an approval process.
signature record
A database record for the signature of an approver. If an approval request requires more than one signature, then multiple signature records are generated for that single approval request.
source control
One of several special access control groups that the AR System provides. Members of this group have limited administrative access to the AR System as defined by an administrator. See also Administrator group.
Submitter group
Managing server objects in AR System application development by controlling object access.

SQL menu
One of several special access control groups that the AR System provides. Users automatically belong to this implicit group for requests they have submitted (that is, their name is in the Submitter field). See also Assignee group, Assignee Group group.
supporting form
A menu whose items are based on data retrieved from a direct SQL command to the AR System database.
A form that supplies information needed by the main form.
Glossary
349
table field
validate approver
A field that displays data from other requests within the context of the current request. The data appears in a spreadsheetstyle format.
task
A rule type that is used to verify that a name specified as the next approver is a valid user. Only used to verify a user specified in an Ad Hoc process or an Ad Hoc override of another process type.
variable
A shortcut or link created in BMC Remedy User that enables users to quickly open a specific form, search, application, or active link.
toolbar
A data element that changes according to the conditions.

vendor form
The row of buttons below the menu bar in BMC Remedy User that enables easy access to commonly used menu commands.
toolbar button
Forms that allow users to connect to external data sources, such as text or spreadsheet data, that reside on local or remote servers.
view
In BMC Remedy User, an icon for a menu item that triggers an active link. See also button, menu item.
trim data type
See form view.

view field
The data type of fields that enhance a forms usability and appearance. Trim includes lines, boxes, text, and URL links. These fields do not contain data.
user
Field that provides a browser window within a form. Can be used to display a URL, the contents of an attachment, or direct HTML text.
view form
Any person with permission to access the AR System. See also access control, group, permission.
user default
Forms that allow users to connect to external database tables accessible by the AR System database user.
view user interface (VUI)
A structure that contains information about a single view.

web client
A value or set of values that a user can predefine. A user default overrides an AR System administrator default. See also administrator default.
User form
An AR System client that runs in a browser to provide a user interface to AR System applications.
wildcard
The form in which administrators add users to the AR System and specify each users type of access and login information.
A character that users can enter to represent other characters in a search. For example, in search statements in character and diary fields, users can specify wildcards to match single characters, strings, or characters within a range or set.
350 Glossary
workflow
1. A set of business processes used to run a company. 2. The automation of business processes through actions performed by active links, filters, and escalations.
work space
A subset of all objects on the server displayed in AR System Administrator. This subset of server objects is defined in a packing list.
write license
A license that allows a user to modify and save data in existing requests as field and form permission settings allow. See also fixed license, floating license, read license.
Glossary
351
352 Glossary
Index
A
access privileges 66 accessing approval module forms 118 Approval Server with web clients 119 active links for Lunch Scheduler 224 active signature record 99 ad hoc approvers 94 defined 337 defining processes 142 process type versus ad hoc override 94, 112 sample application 74 ad hoc process described 112 Get Next Approver rules 169 Parameterized Get Next Approver rule 113 adding alternate approvers 70 Add-PGNA-Values command 259 Add-Sig command 258 multitenancy 258 administration 119 Approval Server 117 URL 119 administrators defined 339 setting capabilities 125 administrators, process assigning capabilities 125 authority of 84 defined 84 delegating authority 85 Override Only 85 responsibilities of 84 Specific Process 85 All must sign field 171, 175, 209 alternate approvers access privileges 66 adding 70 assigning 49, 66 creating for others 70, 209 defined 42 modifying information 69 serving as 50, 68 alternate reject 338 answering approval requests 56 More Information requests 63 AP:Admin-DeleteVerify dialog 270 AP:Administration form 118, 234, 269 AP:Admin-Rename dialog 121, 271 AP:Admin-ServerSettings dialog 127, 272 AP:Alternate form 276 AP:Detail form 85, 279 AP:Detail-Signature form 232, 280 AP:Dtl-Sig-MoreInfoDialog dialog 283 AP:Form form 284 AP:More Information form 86, 242, 285
Index
353
AP:Notification form 243, 286 AP:PreviewInfo form 292 AP:Process Administrator form 125, 211, 292, 293 AP:Process Definition form 140, 242, 295 AP:Reserved Word form 301 AP:Role form 208, 301 AP:Rule Definition form entering rule information 156 field descriptions 303 opening the form 154 setting field values on forms 157 tabbed views 154 AP:Signature form 86, 309 Application Pending form 20, 256, 321 Application-Command process 256 applications connecting to Approval Server 230 Get Agreement 73 licensing forms 20 Lunch Scheduler 213 troubleshooting sample 322 Approval Central form 268 hidden characteristic 231 logging in with User tool clients 56 logging in with web clients 54 URL 54, 322 approval errors 49 approval module, accessing forms 118 approval notifications 116 Approval Process ad hoc 112 creating 84, 140 defined 34 deleting 150 diagram of 88, 106 done versus complete 89 error handling 49 licensing forms 20 modifying 149 reassigning requests 48, 61 requesting more information 47 restarting 222 specifying next approver 48, 60 viewing approval request records 46
Approval Process Done rules creating 201 described 201 example of 202 worksheet 253 Approval Process, types of ad hoc 169 level 110, 169 parent-child 108, 168 rule-based 114, 170 summary table 114 approval processes for Lunch Scheduler 216 approval requests audit trails 85 defined 338 diagram of 88 login list 55, 57 processing 46, 54, 119 reassigning 48, 61 responding to 56, 96 sample application 73 specifying next approver 48 status of 47 viewing 46, 58 approval routing, setting up 84 approval rules defined 87 deleting 206 modifying 205 approval rules, types of Approval Process Done 201 Auto-Approval 159 Completion 187 Get Authority 91, 181 Get Authority Regular 183 Get Authority Self 91, 185 Get Next Approver 94, 168, 174 Prep Next Approver 165 Self-Approval 92 Signature Accumulator 189, 190 Statistical Override 193 Validate Approver 94, 179
354 Index
Approval Server accessing components 120 accessing with web clients 119 administration 117 ARDBC plug-in, using 27 configuring 122 connecting applications to 230 deadlocked ARDBC plug-in 323 debugging 122 defined 338 incompatibility with bundled version 320 installing on Windows 21 licensing before installation 321 licensing forms 20 manually starting and stopping 27 performance 67 previous installation 320 purchasable license not required 20 URL 54, 322 Approval Server commands Add-PGNA-Values 259 Add-Sig 258 Det-Approved 259 Det-Cancelled 259 Det-Error 260 Det-Rejected 260 MoreInfo-Return 261 New-Details 261 Rename-Form 262 Rename-Process 262 Sig-Approved 262 Sig-Cancelled 263 Sig-Notify 263 Sig-Notify-Change 264 Sig-Notify-State 264 Sig-Reassign 265 Sig-Rejected 265 Update-Config 265 Approval Server dialogs AP:Admin-DeleteVerify 270 AP:Admin-Rename 271 AP:Admin-ServerSettings 127, 272 AP:Dtl-Sig-MoreInfoDialog 283 Approval Server for the Web. See Approval Web
Approval Server forms AP:Administration 269 AP:Alternate 276 AP:Detail 279 AP:Detail-Signature 280 AP:Form 284 AP:More Information 285 AP:Notification 286 AP:Process Administrator 292, 293 AP:Process Definition 295 AP:Reserved Word 301 AP:Role 301 AP:Rule Definition 303 AP:Signature 309 Approval Central 268 APW:Access Privileges 310 APW:Approval Central 312 APW:More Info Requests 313 Business Time Holidays 315 Business Time Workdays 315 User 317 Approval Web configuring without portmapper 30 notes on installation 20 processing requests 54, 119 requesting more information about approvals 62 responding to More Information requests 63 reviewing requests 58 troubleshooting 322 URL 54, 322 viewing More Information requests 63 Approval Web, alternate approvers designating 66 modifying 69 reassigning approval requests 61 reviewing 68 serving as 68 Approval Workspace field 221 approval, defined 34
Index
355
approvers ad hoc 94 approving requests 89 assigning alternate 49, 66, 209 completed versus done requests 89 defined 41 list of, defined 339 modifying alternates 69 multiple 60 overriding 51, 71 previewing 144, 218 problem with responses 323 rejecting requests 89 response in sample application 75 reviewing alternates 69 roles and 92 serving as alternate 50, 68 approving requests 75, 89, 97 AP-Sample:Company form 216 AP-Sample:Lunch Scheduler form 215, 224 AP-Sample:Lunch-Detail form 215 AP-Sample:Lunch-Detail-Signatu form 216, 225 AP-Sample:Restaurant form 216 AP-Sample:Signature Authority form 216, 226 APW:Access Privileges form 310 APW:Approval Central form 312 APW:More Info Requests form 313 AR System administrator 339 AR System filters 158 AR System server starting manually UNIX 28 Windows 27 stopping manually UNIX 29 Windows 27 AR System server, installation notes 20 AR System User creating approval rules 153 modifying approval rules 153 overriding approvers 71 responding to More Information requests 63 reviewing answers to More Information requests 63
AR System User, alternate approvers defining for other approvers 70 ar.cfg 266 ar.conf 266 ar_apinstall 23 ARDBC plug-in 27 deadlocked server 323 arjoinfix 233 arstruct.h 265 Assigned To field 231 assigning administrator capabilities 125 alternate approvers 49, 66 approval requests 61 limited administration rights 84 override capabilities 211 audit trail of approval requests 85 authority process administrator and 84 signature 68 Auto-Approval Rules process instance ID, using 159 Auto-Approval rules checks 90 creating 160 defined 338, 339 example of 161 worksheet 245
B
BMC Remedy Alert 134 browsers, web 54 Business Time Holidays form configuring 137 described 315 More Information escalations 148 Business Time Workdays form described 315 More Information escalations 148 buttons Manage More Information 223 Show Approval Summary 224 Show Signature 224
356 Index
C
cancel at later level 340 cancelled 340 cancelling approval processes 222 category parameter 256 chained processes 105, 221, 235 complex 40 filters 214, 234 Change Management 20, 320 changing alternate approvers 69 processes 149 rules 205 checks auto approval 90 self approval 91 clients web 54 Windows User Tool 56 close approve 341 close reject 341 closed 341 command format 256 command parameter 256 commands, Approval Server Add-PGNA-Values 259 Add-Sig 258 Det-Approved 259 Det-Cancelled 259 Det-Error 260 Det-Rejected 260 MoreInfo-Return 261 New-Details 261 Rename-Form 262 Rename-Process 262 Sig-Approved 262 Sig-Cancelled 263 Sig-Notify 263 Sig-Notify-Change 264 Sig-Notify-State 264 Sig-Reassign 265 Sig-Rejected 265 Update-Config 265 compatibility matrix 20 complete versus done 89
completing processes 89 Completion Checks diagram of 103, 106 routing and 102 rules 104 Completion rules creating 188 defined 341 described 187 example of 188 worksheet 250 complex processes 40 components, Approval Server 120 configuring Approval Server 122 Approval Web without portmapper 30 Business Time Holidays form 137 connecting applications to Approval Server 230 conventions used in this manual, preface 17 Create Date field 231 creating actions for rules 157 alternate approvers 70 Approval Process 84 notifications 129 processes 87, 140 roles 208 rules 154 creating rules Auto-Approval rules 160 Completion 188 Get Authority 181 Get Authority Regular 183 Get Authority Self 185 Get Next Approver 170, 174 Prep Get Next Approver rules 165 Self Approval rules 162 Signature Accumulator 190 Statistical Override rules 193 Validate Approver 179 currency fields 156, 157 functions 157 current signature records 99
Index
357
D
daemon 25 debugging Approval Server 122 debug mode 266, 272 log file 124 default directories 334 defining actions for rules 157 alternate approvers 70, 209 notifications 129 roles 208 defining rules Approval Process Done 201 Auto-Approval 160 Completion 188 Get Authority 181 Get Authority Regular 183 Get Authority Self 185 Get Next Approver 170, 174 Prep Get Next Approver 165 Self Approval 162 Signature Accumulator 190 Statistical Override rules 193 Validate Approver 179 delegating authority 85 deleting processes 150 rules 206 designating alternate approvers 49, 66 designing processes 242 Detail records 85 Detail-Signature records 47 Det-Approved command 259 Det-Cancelled command 259 Det-Error command 260 Det-Rejected command 260 dialogs AP:Admin-DeleteVerify 270 AP:Admin-Rename 121, 271 AP:Admin-ServerSettings 127, 272 AP:Dtl-Sig-MoreInfoDialog 283 directory structure 334, 335 done versus complete 89 Done, Process 89
E
editing alternate approvers 69 processes 149 rules 205 email notifications 127, 129 defining 135 enabling notifications 127 entering rule information 156 errors approval 49 defined 342 process 104 escalations creating 275 enabling 127 More Information 148 signature 298 signature worksheets 243 events that trigger notifications 133 EXTERNAL keyword notification qualifications 287 Rule qualifications 305 Run If qualifications 305 Set Fields qualifications 308
F
feedback 37 field IDs 1 230 102 225 13191 232 536870920 221 7 231, 232 8 231 fields All must sign 171, 175, 209 Approval Workspace 221 One must sign 171, 175, 209 Reassign 48 Request 231 Request ID 230 Status 232
358 Index
filters AP-Sample:StartCostApproval 217 AP-Sample:StartLevelApproval 217 AP-Sample:StartOverdueApprov 218 New-Details command 234 specifying for rules 158 first approver list 169 first level of approvers 169 format of commands 256 forms AP:Administration 118, 234, 269 AP:Alternate 276 AP:Detail 85, 279 AP:Detail-Signature 232, 280 AP:Form 284 AP:More Information 86, 242, 285 AP:Notification 243, 286 AP:PreviewInfo 292 AP:Process Administrator 125, 211, 292, 293 AP:Process Definition 140, 242, 295 AP:Reserved Word 301 AP:Role 208, 301 AP:Rule Definition 154, 303 AP:Signature 86, 309 Application Pending 20, 256, 321 Approval Central 268 APW:Access Privileges 310 APW:Approval Central 312 APW:More Info Requests 313 Business Time Holidays 137, 315 Business Time Workdays 315 licensing for approval process 20 See also forms, Lunch Scheduler User 317 forms, Lunch Scheduler AP-Sample:Company 216 AP-Sample:Lunch Scheduler 215, 224 AP-Sample:Lunch-Detail 215 AP-Sample:Lunch-Detail-Signatu 216, 225 AP-Sample:Restaurant 216 AP-Sample:Signature Authority 216, 226 functions currency 157 date 157
G
Get Agreement application ad hoc process 74 approving requests 75 licensing sample users 226 parent-child hierarchy 227 reassigning requests 79 requesting items 74 requesting more information 77, 78 reviewing answers to More Information requests 80 statistical rules 199 Get Authority Regular rules creating 183 defined 344 described 104 example of 184 worksheet 250 Get Authority rules creating 181 defined 344 described 91 example of 182 worksheet 246 Get Authority Self rules creating 185 defined 344 described 91 example of 187 worksheet 246 Get Next Approver rules ad hoc process 113, 169 creating 170 defined 344 described 94, 168 example of 172 level process 169 parent-child process 168 rule-based process 170 worksheet 249 global approve 280 overrides 52, 72 reject 280 group (402) 347
Index
359
H
Hidden characteristic 232 Approval Central 231 hold defined 344 response to requests 96
I
ID, reserved 230, 231 inner join 232 installation notes 20 installer script, UNIX 23 installing Approval Server for Windows 21 Approval Web notes and 20 AR System server notes and 20 directory structure 334, 335 licensing Approval Server 321 troubleshooting 320
logging in User tool 56 web clients 54 Low Priority Notification worksheet 244 Lunch Scheduler application approval processes 216 chaining approval processes 221 forms 215 licensing sample users 226 overview 214 parent-child hierarchy 227 restarting approval processes 222 reviewing information 223 showing password field 225 showing signatures 224 showing summaries 224
M
Major Account Level Approval approval process 217 Manage More Information button 223 Management Cost Authorization approval process 217 Modified Date field 231 modifying alternate approvers 69 processes 149 rules 205 More Information defined 346 records 285 worksheet 242 More Information escalations notifications 148 setting parameters 148 worksheet 242 More Information requests entering information 62 responding to 63, 96 reviewing answers 63 reviewing answers in sample 80 using in sample application 77, 78 MoreInfo-Return command 261 multiple approvers 60
J
join forms, applications with Approval Server 230 join, inner 232
L
Last Modified By field 231 level approvers 169 defined 345 identifier 169 level process described 110 Get Next Approver rules 169 licensing approval server does not require purchasable license 20 before Approval Server installation 321 forms 20 sample users 226, 322 limiting administration rights 84 linking applications to Approval Server 230 lists first approver 169 signatures 224 log file, debugging and 123, 124
360 Index
multitenancy Add-Sig command 258 New-Details command 261 support added to approval server 16
P
Parameterized Get Next Approver rules ad hoc process 113, 169, 174 creating 174 defined 346 described 174 example of 177 rule-based process 170 worksheet 251 parameters 256 parent-child process described 108 Get Next Approver rules 168 sample applications and 227 Password field 225 passwords setting up for users 297 verifying 281 pending 347 performance issues with privileges 67 performing overrides 51 permissions change 209 connecting applications and 231 performance issues with privileges 67 portmapper 30 portmapper and Approval Web 30 preface conventions used in this manual section 17 related Remedy documents section 14 Prep Get Next Approver rules creating 165 defined 347 described 93 example of 217 worksheet 248 previewing approvers 144, 218, 292 previous Approval Server installation 320
N
new features 15 new signature 346 New-Details command 234, 261 multitenancy 261 Next Approver rules 93 Normal Priority Notification worksheet 243 notifications creating 274 email 127 enabling 127 escalation worksheets 243 examples of 115 methods 134 process administrators and 126 setting up 129 workflow 134, 230 workflow-based, enabling 235
O
One must sign field 171, 175, 209 Other, Set Fields value 158 Override Only Admin privileges 293 Override Only process administrators 85 override reject 346 overrides, Ad Hoc 142 overriding approvers 51 assigning capabilities 211 global 52, 72 process administrators and 84 single signatures 71
Index
361
process administrators adding alternate approvers 70 assigning capabilities 125 authority of 84 creating processes and rules 87 defined 84 delegating authority 85 described 43 Override Only 85 overriding approvals 71 responsibilities of 84 Specific Process 85 Process definition worksheet 242 Process Done rules 105 process instance ID, using with Auto-Approval rules 159, 160 Process, Set Fields value 158 processes chained 105 creating 140 deleting 150 designing worksheet 242 done versus complete 89 errors 104 modifying 149 restarting 222 rules and 87 types of 107 processing approval requests 46 product compatibility matrix 20 Purchasing@Work 320
Q
Query, Set Fields value 158
R
reassigning approval requests 48 requests in sample application 79 records active signature 99 current signature 99 Detail 85 Detail-Signature 47 reject response to requests 96
rejected 348 rejecting by another approver 89, 348 by later level 348 related Remedy documents in preface 14 relationships level approval process 110 parent-child approval process 108 roles and 92 rename, process 151 Rename-Form command 262 Rename-Process command 262 repeat interval 299 Request field 231 Request ID field 230, 231 requesters 41 requesting items in sample application 74 more information 48, 62 requests, approval audit trails 85 defined 338 diagram of 88 login list 55, 57 processing 46, 54, 119 reassigning 48 responding to 56, 96 sample application 73 specifying next approver 48 status of 47 viewing 46, 58 requests, More Information described 48 entering information 62 responding to 63 reviewing answers 63 reviewing answers in sample 80 using in sample application 77, 78 reserved ID 230, 231 responding to approval requests 56 More Information requests 63, 78 responses problem with 323 types of 96
362 Index
responsibilities of process administrators 84 restarting processes 222 restoring forms during installation 24 reviewing alternate approvers 69 approval requests 58 Lunch Scheduler application and 223 More Information responses 63 roles approver 92 creating 208 defined 348 versus relationships 92 routing, setting up for 84 RPC socket number 273 rule-based process described 114 example of 217 Get Next Approver rules 170 rules approval process and 87 completion 104 creating 154 deleting 206 filtering 203 modifying 205 stages, viewing 203 rules, types of Approval Process Done 201 Auto-Approval 159 Completion 187 Get Authority 91, 181 Get Authority Regular 104, 183 Get Authority Self 91, 185 Get Next Approver 94, 168, 174 Parameterized Get Next Approver 174 Prep Get Next Approver 93 Process Done 105 Self Check 90 Self-Approval 92 Signature Accumulator 190 Statistical Override rules 193 Validate Approver 94, 179, 323
rules, worksheets for Approval Process Done 253 Auto-Approval 245 Completion 250 Get Authority 246 Get Authority Regular 250 Get Authority Self 246 Get Next Approver 249, 251 Prep Get Next Approver 248 Self-Approval 247 Signature Accumulator 252 Statistical Override 252 Validate Approver 247 Run Process action 256 runtime, troubleshooting 323
S
sample Get Agreement application ad hoc process 74 approving requests 75 licensing sample users 226 More Information requests 77, 78, 80 parent-child hierarchy 227 reassigning requests 79 requesting items 74 statistical decision-making rules sample 196 sample Lunch Scheduler application approval processes 216 chaining approval processes 221 forms 215 licensing sample users 226 overview 214 parent-child hierarchy 227 restarting approval processes 222 reviewing information 223 showing password field 225 showing signatures 224 showing summaries 224 sample users, licensing 226, 322 Self Check approvals 89, 91 rules 90
Index
363
Self-Approval rules creating 162 defined 349 described 162 example of 164 overview 92 worksheet 247 server settings 272 configuring 122 serving as alternate approver 50, 68 Set Fields tab AP:Rule Definition form 157 assignment types 158 examples 159 setting up alternate approvers 70 approval routing 84 field values on forms 157 notifications 129 roles 208 setting up rules Approval Process Done 201 Approval Process Done worksheet 253 Auto-Approval Rules 159 Auto-Approval worksheet 245 Completion 188 Completion worksheet 250 Get Authority 181 Get Authority Regular 183 Get Authority Regular worksheet 250 Get Authority Self 185 Get Authority Self worksheet 246 Get Authority worksheet 246 Get Next Approver 170, 174 Get Next Approver worksheet 249, 251 Parameterized Get Next Approver 174 Parameterized Get Next Approver worksheet 251 Prep Get Next Approver 165 Prep Get Next Approver worksheet 248 Self-Approval 162 Self-Approval worksheet 247 Signature Accumulator 190 Signature Accumulator worksheet 252 Statistical Override rules 193
Statistical Override worksheet 252 Validate Approver 179 Validate Approver worksheet 247 Setup@Work 320 Short Description field 232 Show Approval Summary button 224 Show Signature button 224 Sig-Approved command 262 Sig-Cancelled command 263 signature active record 99 authority 68 current records 99, 189 escalations 298 escalations worksheets 243 line errors 49 line records 168, 171, 175 open (currently) 200 overriding single 71 record 349 Totals 100 weights 97 Signature Accumulator rules conceptual overview 99 creating 190 defined 349 example of 191 sample 200 weights 97 worksheet 252 Sig-Notify command 263 Sig-Notify-Change command 264 Sig-Notify-State command 264 Sig-Reassign command 265 Sig-Rejected command 265 single signature overrides 71 socket number 273 Special Overdue Approval approval process 217 Specific Process process administrator 85 SQL, Set Fields value 158 starting Approval Server manually 27 starting AR System server, manually UNIX 28 Windows 27
364 Index
statistical decision-making rules conceptual overview 97 sample 196 underlying workflow 199 Statistical Override rules conceptual overview 101 creating 193 defined 349 example of 195 sample 200 Total signature values 100 worksheet 252 status approval requests and 47 Approval Status 59 notifications, defining 130 Status field 232 Status field ID 7 231 stopping Approval Server manually 27 stopping AR System server, manually UNIX 29 Windows 27 Submitter field 231
U
uninstall 31 UNIX arjoinfix 233 daemon 25 default directories 334 directory structure 335 start command 28 Update-Config command 265 Urgent Priority Notification worksheet 243 URL Administration 119 Approval Central 54, 322 navigation links in applications, adding 239 User form 317 User tool logging in 56
V
Validate Approver rules approver cannot respond 323 creating 179 defined 350 described 94, 179 example of 180 worksheet 247 viewing alternate approvers 69 approval requests 46, 58 More Information responses 63
T
Total signature values 100 trails, audit, of approval requests 85 transferring requests 79 tree, directory 334, 335 triggering notifications 127 troubleshooting Application Pending form 321 Approval Web 322 approver cannot respond 323 ARDBC plug-in 323 deadlocked approval server 323 installation 320 licensing 321 runtime 323 sample applications 322
W
web clients 54 accessing Approval Server 119 creating approval rules 153 modifying approval rules 153 using 119 web document directory 273 weighting signatures with Signature Accumulator rules 97 Windows arjoinfix.exe 233 default directories 334 directory structure 334 installing Approval Server 21
Index
365
workflow notifications 134, 230 notifications, enabling 235 process instance ID, using 160 worksheets, process Low Priority Notification 244 More Information 242 Normal Priority Notification 243 Process definition 242 Urgent Priority Notification 243 worksheets, rule Approval Process Done 253 Auto-Approval 245 Completion 250 Get Authority 246 Get Authority Regular 250 Get Authority Self 246 Get Next Approver 249, 251 Prep Get Next Approver 248 Self-Approval 247 Signature Accumulator 252 Statistical Override 252 Validate Approver 247 write licenses 226
366 Index
*59459* *59459* *59459* *59459*

*59459*

BMC Remedy Approval Server 70 Guide For Users and Administrators

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMC Remedy Approval Server 70 Guide For Users and Administrators

Uploaded by

Copyright:

Available Formats

BMC Remedy Approval Server 7.

Guide for Users and Administrators

May 2006 Part No: 59459

BMC Software, Inc.

Installation and configuration