approval server guide 7.6.03

www.bmc.com

BMC Remedy Action Request System 7.6.03

BMC Remedy Approval Server Guide

August 2010

If you have comments or suggestions about this documentation, contact Information Design and Development by email at [email protected].

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 1991–2010 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

AIX, DB2, IBM, and Informix are trademarks or registered trademarks International Business Machines Corporation in the United States, other countries, or both.

Linux is the registered trademark of Linus Torvalds.

Oracle is a registered trademark of Oracle Corporation.

Solaris and Sun are trademarks or registered trademarks Sun Microsystems, Inc., in the U.S. and other countries.

UNIX is the registered trademark of The Open Group in the U.S. and other countries.

The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product documentation.

Restricted rights legendU.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.

http://www.bmc.com

mailto:[email protected]

Customer Support

You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or email. To expedite your inquiry, please see “Before Contacting BMC Software.”

Support website

You can obtain technical support from BMC Software 24 hours a day, 7 days a week athttp://www.bmc.com/support. From this website, you can:

■ Read overviews about support services and programs that BMC Software offers.■ Find the most current information about BMC Software products.■ Search a database for problems similar to yours and possible solutions.■ Order or download product documentation.■ Report a problem or ask a question.■ Subscribe to receive email notices when new product versions are released.■ Find worldwide BMC Software support center locations and contact information, including email addresses, fax

numbers, and telephone numbers.

Support by telephone or email

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

Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:

■ Product information

— Product name— Product version (release number)— License number and password (trial or permanent)

■ Operating system and environment information

— Machine type— Operating system type, version, and service pack— System hardware configuration— Serial numbers— Related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ Sequence of events leading to the problem

■ Commands and options that you used

■ Messages received (and the time and date that you received them)

— Product error messages— Messages from the operating system, such as file system full— Messages from related software

http://www.bmc.com/support



License key and password information

If you have a question about your license key or password, contact Customer Support through one of the following methods:

■ E-mail [email protected]. (In the Subject line, enter SupID:<yourSupportContractID>, such as SupID:12345.)

■ In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support center for assistance.

■ Submit a new issue at http://www.bmc.com/support.



Contents

Preface 13

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 1 Introduction to the approval server 17

Approvals in business processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Overview of the approval server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Flexibility and common experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Notification with feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Basic approval server concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Approval roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 2 Configuring the approval server 23

Using the approval server Administration form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Process administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Configuring process administrator capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Process administrator prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Creating a process administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Configuring server settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Approval server debug log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Private queues for loopback calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Configuring settings on the Basic tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Configuring settings on the Notifications tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Configuring settings on the Escalations tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Configuring business times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Configuring previews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Configuring the approval server to work with flowcharts . . . . . . . . . . . . . . . . . . . . . . 33

Contents 5

Chapter 3 Processing approval requests 35

Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Opening Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37AR System Object List in browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Working with pending approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Processing an approval request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Performing a search on Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Approving and rejecting requests from Approval Central . . . . . . . . . . . . . . . . . . . 39Rejection justification for approval requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Working with request details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Processing More Information requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Requesting more information about approval requests. . . . . . . . . . . . . . . . . . . . . . 46Viewing and responding to More Information requests . . . . . . . . . . . . . . . . . . . . . 47Viewing pending More Information requests and responses . . . . . . . . . . . . . . . . . 48Viewing all More Information requests you submitted . . . . . . . . . . . . . . . . . . . . . . 49

Using alternate approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Designating alternate approvers for yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Viewing and modifying alternate approver definitions . . . . . . . . . . . . . . . . . . . . . 52Viewing requests for which you are an alternate approver . . . . . . . . . . . . . . . . . . 52Defining alternates for other approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Performing overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Performing an override to a single signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Performing a global override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 4 Using the Get Agreement sample application 57

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

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

Approval server data and forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Approval data and audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Approval server supporting forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Difference between processes and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Approval process stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Approval process types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Summary of process types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Signatures for multiple approvers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Action date for a process or signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6 BMC Remedy Approval Server Guide

Approval server rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Self Check stage—Rules that test for automatic approval and self approval. . . . 82Next Approver stage—Rules that get the next approver . . . . . . . . . . . . . . . . . . . . 85Approver Response stage—Rules that work with signatures . . . . . . . . . . . . . . . . 87Completion Check stage—Rules that test for completion. . . . . . . . . . . . . . . . . . . . 91Process Done stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Chained processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Approver fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Lengths of approver fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94The apchgschema utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapter 6 Defining an approval process 97

Using the Process tab on AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Creating a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Defining process basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Setting process intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Creating signature escalations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Creating More Information escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Working with existing processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Viewing and modifying a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Deleting processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Renaming an approval process or form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Defining roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Chapter 7 Defining approval rules 109

Using the Rule tab on AP:Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Creating a rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Using the Basic tab on the Rule Definition form. . . . . . . . . . . . . . . . . . . . . . . . . . . 111Using the Set Fields tab on the Rule Definition form. . . . . . . . . . . . . . . . . . . . . . . 113Example of the Set Fields tab for a query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Defining approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Defining Auto Approval rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Example of an Auto Approval rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Defining all Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Example of a Get Authority rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Defining Self Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Example of a Self Approval rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Defining Prep Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Example of a Prep Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Defining Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Process type and Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Creating a Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Example of a Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Defining Parameterized Get Next Approver rules. . . . . . . . . . . . . . . . . . . . . . . . . 126Example of Parameterized Get Next Approver rule . . . . . . . . . . . . . . . . . . . . . . . 128Defining Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Example of a Validate Approver rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Defining Signature Accumulator rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Contents 7

Example of a Signature Accumulator rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Defining Statistical Override rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Example of decision-making rules in a sample application . . . . . . . . . . . . . . . . . 133Example of a Statistical Override rule with default data . . . . . . . . . . . . . . . . . . . . 137Defining Completion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Example of a Completion rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Defining Approval Process Done rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Example of an Approval Process Done rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Working with existing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Viewing and modifying rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Deleting rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Chapter 8 Using the Lunch Scheduler sample application 143

Overview of the Lunch Scheduler application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Important Lunch Scheduler forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Sample process descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Management cost authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Major account level approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Special overdue approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Chaining approval processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Using filters and a process status field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Restarting an approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Licensing sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Sample user approval authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Chapter 9 Adding approvals to your application 151

Designing an approval application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Connecting an application to the approval server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Creating an approval request form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Creating the join forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Running arjoinfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Adding the approval request form to AP:Administration . . . . . . . . . . . . . . . . . . 156Implementing the approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Adding notifications to the approval process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Creating notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Enhancing your approval forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Add workflow to your approval server forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Show the password field in the detail view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Add a field menu of valid names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Adding previews to your approval application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Multi-process preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Using a custom ad hoc dialog box with the approval server. . . . . . . . . . . . . . . . . . . . 171


Appendix A Upgrading the approval server 173

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

Appendix B Application commands 179

Using Application-Command processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Application command syntax and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Application command parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Example of an application command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Approval server commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Add-PGNA-Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Add-Sig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Det-Approved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Det-Cancelled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Det-Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Det-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Generate-Multi-Process-Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Generate-Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186MoreInfo-Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187New-Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Rename-Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Rename-Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Sig-Approved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Sig-Cancelled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Sig-Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Sig-Notify-Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Sig-Notify-State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Sig-Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Sig-Rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Update-Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Appendix C Worksheets 195

Process worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Defining a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196More Information escalations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Signature escalations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Rule worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Auto Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Get Authority rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Get Authority Self rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Self Approval rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Validate Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Prep Get Next Approver rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Get Authority Regular rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Contents 9

Parameterized Get Next Approver rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Signature Accumulator rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Statistical Override rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Completion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Approval Process Done rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Appendix D Approval forms 207

Administration forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208AP:AdhocDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208AP:Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209AP:Admin-DeleteVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210AP:Admin-Rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210AP:Admin-ServerSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212AP:Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215AP:Detail-Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217AP:DynamicLabels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219AP:Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220AP:Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223AP:Preview Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226AP:PreviewInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227AP:PreviewSignatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228AP:Process Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229AP:Process Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231AP:Question-Comment-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245AP:Reserved Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245AP:Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246AP:Rule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247AP:Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252AR System Business Time forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

User forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Approval Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255AP:AdhocDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263AP:Alternate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266AP:Dtl-Sig-MoreInfoDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268AP:More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269AP:Password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270AP:Reassign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270AP:Rejection Justification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271AP:Show-Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271AP:ShowDetail-DeleteVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Appendix E Installing the approval server in a server group 281


Appendix F Troubleshooting 283

Installation and upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Issues when upgrading to version 7.6.03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Previous approval server installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Error 333 and Assignee Group Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Approval server log files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Location of log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Approver server logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Runtime issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Approver receives request but cannot respond . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Deadlocked approval server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Approval server configuration file settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286System error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Accessibility issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Glossary 289

Index 293

Contents 11

Preface

IMPORTANT The compatibility information listed in the product documentation is subject to change. See the compatibility matrix at http://www.bmc.com/support for the latest, most complete information about what is officially supported.

Carefully read the system requirements for your operating system, especially the patch requirements. See the Installation Guide, “Obtaining system requirements and software,” page 12.

AudienceThe BMC Remedy Approval Server Guide is written for:

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

! Administrators of AR System who install the BMC Remedy Approval Server (approval server) component, create users, forms, and workflow objects, and assign permissions.

! Approval server process administrators who design and maintain approval processes.

This document assumes you are familiar with AR System. The administration sections assume that you want to add the approval server feature to an existing application.

This document provides instructions to install approval server forms and workflow on the Windows and UNIX® operating systems, and assumes that you are familiar with the environment in which you install the software.

AR System documents The following table lists documentation available for AR System products.

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

Preface 13





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

Title Description Audience

Concepts Guide1 Overview of AR System architecture and features; includes information about add-on products that extend AR System functionality and a comprehensive glossary for the entire AR System documentation set.

Everyone

Installation Guide Instructions for installing AR System. Administrators

Introduction to Application Development with BMC Remedy Developer Studio

Information about the development of AR System applications, including an introduction to using BMC Remedy Developer Studio.

Developers2

Form and Application Objects Guide

Information about AR System applications and their user interface components, including forms, fields, views, menus, and images.

Developers

Workflow Objects Guide Information about the AR System workflow objects (active links, filters, and escalations) and how to use them to create processes that enforce business rules.

Developers

Configuration Guide Information about configuring AR System servers and clients, localizing, importing and exporting data, and archiving data.

Administrators

BMC Remedy Mid Tier Guide Information about configuring the mid tier, setting up applications for the mid tier, and using applications in browsers.

Administrators

Integration Guide Instructions for integrating AR System with external systems by using web services, plug-ins, and other products, including LDAP, OLE, and ARDBC.

Administrators/Developers/Programmers3

Optimizing and Troubleshooting Guide

Information about monitoring and maintaining AR System and AR System applications to optimize performance and solve problems.

Administrators/Developers/Programmers

Database Reference Database administration topics and rules related to how AR System interacts with specific databases; includes an overview of the data dictionary tables.

Administrators/Developers/Programmers

BMC Remedy Distributed Server Option Guide

Information about implementing a distributed AR System server environment with BMC Remedy Distributed Server Option (DSO).

Administrators

BMC Remedy Flashboards Guide

Instructions for creating, modifying, and administering flashboards to display and monitor AR System information.

Administrators/Developers

C API Reference Information about AR System data structures, C API function calls, and OLE support.

Programmers

C API Quick Reference Quick reference to C API function calls. Programmers

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

Programmers


AR System documents

1 The full title of each guide includes BMC Remedy Action Request System 7.6.03 (forexample, BMC Remedy Action Request System 7.6.03 Concepts Guide).2 Application developers who use BMC Remedy Developer Studio.3 C and Java programmers who write plug-ins and clients for AR System.

Java Plug-in API Information about Java classes, methods, and variables used to write plug-ins for AR System. For the location of the JAR file containing this online documentation, see the information about plug-ins in the Integration Guide.

Programmers

BMC Remedy Email Engine Guide

Instructions for configuring and using BMC Remedy Email Engine.

Administrators

Error Messages Guide Descriptions of AR System error messages. Administrators/Developers/Programmers

Master Index Combined index of all books. Everyone

BMC Remedy Approval Server Guide

Instructions for using BMC Remedy Approval Server to automate approval and signature processes in your organization.

Administrators

Release Notes Information about new features, compatibility, and international issues.

Everyone

Release Notes with Known Issues

Information about new features, compatibility, international issues, installation planning, and open issues.

Everyone

BMC Remedy User Help Instructions for using BMC Remedy User. Everyone

BMC Remedy Developer Studio Help

Instructions for using BMC Remedy Developer Studio to develop AR System forms, workflow objects, and applications.

Developers

BMC Remedy Data Import Help

Instructions for using BMC Remedy Data Import. Administrators

BMC Remedy Alert Help Instructions for using BMC Remedy Alert. Everyone

BMC Remedy Mid Tier Configuration Tool Help

Instructions for configuring BMC Remedy Mid Tier. Administrators

BMC Remedy Browser Help

Instructions for using AR System forms in browsers. Everyone

Title Description Audience

Preface 15

Chapter

1
Introduction to the approval server
This chapter introduces basic concepts and terminology related to BMC Remedy Approval Server (approval server).

The following topics are provided:

! Approvals in business processes (page 18)! Overview of the approval server (page 18)! Basic approval server concepts (page 19)



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

You can use the approval server for processes with the following requirements:

! Workflow that includes need for agreement or acknowledgment from others

! Processes that must be auditable

! Signatures that must be authenticated

Overview of the approval serverThe approval server is a self-contained, shared module that can be attached to any AR System application. It is a flexible solution for automating any approval or signature-driven process across any organization. You can have multiple instances of the approval server running with multiple instances of the AR System server on one computer. The approval server includes built-in contingency handling, which makes sure that approvals are completed quickly and properly within the system.

When an AR System application triggers an approval process, the approval server routes a request to collect signatures within a defined approval process, handling all notifications and requests for more information as it collects each response (approval or rejection). The approval server then reactivates the original application and reports the result of the approval process.

Figure 1-1: Using BMC Remedy Approval Server with AR System applications


Basic approval server concepts

Flexibility and common experienceYou can use the approval server to define or modify how each approval process should work. You can set up new processes and adapt existing processes as changes occur in your organization. Customizing the approval server does not require programming expertise.

For every stage of the approval process, you can define notifications to inform interested parties of the status of an approval request. The approval server allows approvers to gather more information about a request from any AR System user.

With BMC Remedy Approval Server, you do not need to build custom workflow or separate solutions for each application. All processes can share the same approval engine, providing a common approval experience across applications.

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

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

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

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

! A process must have procedures to route an approved request to the next approver, to stop routing a rejected request, and to notify a person when a response is required.

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



A given request might require one simple approval process, or several processes that work with each other. Often the appearance of a single operation involves multiple approvals. Some requests must follow a process but can be approved automatically based on certain criteria.

In BMC Remedy Approval Server, an approval process is the set of rules and forms that generate data to authorize specific AR System workflow. An approval process consists of definitions for the operation itself, rules that define what happens at each specific stage in the process, and a place to store signatures. While process administrators need to understand these rules, they are transparent to approvers. The types of rules and how they interact are described under “Approval server rules” on page 82.

The data generated by an approval process, such as the type of approval, approver signatures, requests for more information, and time stamps for audit trails, is stored in the detail record and other supporting forms. This enables you to track the approval process for auditing or troubleshooting purposes. For more information about data, see “Approval data and audit” on page 70.

Approval rolesThree roles are involved in the approval process: those requesting approval (requesters), those approving requests (approvers and alternate approvers), and process administrators who set up and modify the approval server configuration.

Most approval processes are transparent to requesters, who therefore do not need a thorough understanding of approval server. This document is primarily written for approvers and process administrators.

RequestersRequesters are people who want something to be approved. Requesters work with an application that starts an approval process by entering an approval request. Approval requests are routed to all required approvers according to the rules of the approval process.

The approval server allows requesters to enter approval requests, check the status of their requests, and respond to More Information requests.

ApproversApprovers are people with the authority to approve, reject, reassign, hold, or provide questions and comments for a request in a given process.

The process administrator configures approvers for each process, so that each request has a specified approver list. Different requesters can have different approver lists for the same process.

An approver list specifies the exact list of signatures required for a request. A signature can come from an individual or from a business role containing multiple individuals, such as department managers. The approval server allows you to work with any combination of individuals and roles to create the approver list for each process.


Basic approval server concepts

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

! Approving

! Rejecting

! Reassigning

! Holding

! Requesting and responding to More Information Requests

! Checking status

Approvers have access to the details of the request being processed as well as to the request history. The history includes a list of all approvers who have responded to the request, and the actions they took. Also, any comments that have been entered by other approvers are available for review.

If approvers need to obtain more information before approving a request, they can send a More Information request to any AR System user. A More Information request is separate from the approval request, but remains associated with it.

Alternate approversWhen an approver cannot be available, such as during a business trip or vacation, the approver can define an alternate approver with the same authority within an approval process. An alternate is someone who substitutes for the approver and acts with the approver’s authority and privileges for a duration of their choice.

Approvers can to set up any number of alternates. Each alternate might be set up to substitute within one or more approval processes.

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

! Define approval server processes and rules.

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

! Grant limited authority to specified users, allowing them to configure a process, to override a process, or both.

! Designate alternates for any approver.

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

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


Chapter

2
Configuring the approval server
This section describes the procedures that process administrators use to configure BMC Remedy Approval Server (approval server).


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



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

! Create or configure other process administrators and alternates

! Access AR System server settings specific to the approval server

! Rename related processes and forms

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

To access the AP:Administration form, you must be an approval server process administrator or an AR System administrator.

Figure 2-1: AP:Administration form

! To open the AP:Administration form

1 Log in to AR System as an AR System administrator or a process administrator by using BMC Remedy User or a browser.

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

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

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

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

http://hostName/arsys/forms/serverName/AP:Administration

hostName is the name of the web server, and serverName is the name of the AR System server.


Process administrator

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

! Administrator tab—This tab enables you to create and configure process administrators. See “Creating a process administrator” on page 26.

! Server settings link—This link enables you to configure approval server logging, and customize other approval server settings. See “Configuring server settings” on page 27.

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

Process administratorA process administrator is an AR System user with the authority to define an approval process and to perform administrative tasks related to the AR System. The first process administrator must be set up by the AR System administrator, but others can be set up by an existing process administrator.

The process administrator is a more powerful authority than the signature authorities (approvers) who actually sign approval requests. A process administrator performs the following responsibilities:

! Designs the approval process to generate approval signature data when AR System workflow needs to be authorized.

! Connects the approval server forms to workflow to accomplish the designed approval process. This includes configuring routing, and creating the list of authorized approvers. See also Chapter 9, “Adding approvals to your application.”

! Overrides a process, or parts of a process, when circumstances arise that must be handled outside of established workflow. See “Performing overrides” on page 54.

! Creates and deletes other process administrators as needed. Other process administrators can have full or limited authority. A process administrator with limited authority can perform the following activities:

! Act as an administrator to manage only specific processes that are assigned by a process administrator with full authority.

! Act as an override-only administrator to approve or reject requests regardless of the approver list for the assigned processes.



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

! Full Admin authority—grants the ability to configure and modify processes, as well as to approve or reject requests regardless of the normal process.

! Override Only Admin authority—grants the ability to approve or reject requests regardless of the normal process, but not create or modify processes.

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

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

! To create a process administrator

1 Open the AP:Administration form as described in “Using the approval server Administration form” on page 24.

2 Open the Administrator tab, and click Create to open the AP:Process Administrator form.

Figure 2-2: Creating a process administrator


Configuring server settings

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

See “AP:Process Administrator” on page 229.

4 Click Save.

Configuring server settingsYou can configure various approval server settings such as specifying the debug mode, log file name and location, and the private queues for loopback calls.

The AP:Admin-Server Settings form allows process administrators to manage settings that apply to all approval server functionality and processes.

Approval server debug logIf you select the Approval Debug Mode check box, a log of approval activity is generated. The log is a text file, and is stored in the location you specify in the AP:Admin-ServerSettings form.

After the log is activated, logging starts immediately. The log file is emptied and restarted when you restart the approval server or when you reactivate logging after it has been deactivated. Because logging can generate large files, you should plan to use the log for specific purposes, or regularly save and delete your log files.

The following output is a sample of the approval information stored in the log file.

<APPR> Approval Server Trace Log -- ON (Fri Mar 17 2006 10:39:00.9700)<APPR> Configuration tag Approval-Log-File: updated successfully<APPR> Delete pending item -- 000000000000134<APPR> Processing item number 1 (Fri Mar 17 2006 10:39:00.9860)<APPR> Initiated by -- Demo<APPR> Category -- Approval<APPR> Command -- Update-Config<APPR> Source Form -- <APPR> Entry ID -- <APPR> Tag -- Debug-mode:<APPR> Field ID 1 -- 0<APPR> Field ID 2 -- 0<APPR> Field ID 3 -- 0<APPR> Other Short -- <APPR> 65536<APPR> Process an 'Update-Config' command<APPR> Configuration tag Debug-mode: updated successfully<APPR> Delete pending item -- 000000000000135<APPR> Processing item number 2 (Fri Mar 17 2006 10:39:01.0170)<APPR> Initiated by -- Demo<APPR> Category -- Approval<APPR> Command -- Update-Config<APPR> Source Form -- <APPR> Entry ID --



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

Private queues for loopback callsThe Server Settings form provides the Private AR Server RPC Socket and Plugin Loopback RPC Socket fields for controlling loopback calls to the AR System server.

A loopback call occurs when the approval server plug-in initiates a call back to the AR System server while processing approval workflow. During heavy loads, this can cause a server deadlock if enough queues or threads are not available. To avoid this, use a dedicated loopback RPC queue. The valid RPC port number ranges are:

! 390621–390634

! 390636–390669

! 390680–390694

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

Private AR Server RPC SocketThe Private AR Server RPC Socket field creates a private queue dedicated to approval server loopback calls only. This setting appears in the AR System server configuration file with the tag Approval-RPC-Socket.

If both the Private AR Server RPC Socket and Plugin Loopback RPC Socket values are set, the approval server uses the Private AR Server RPC Socket.

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

This setting appears in the AR System server configuration file with the label Plugin-Loopback-RPC-Socket.

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



If the Plugin Loopback RPC Program Number is already defined for the AR System server, enter the same RPC number in the Plugin Loopback RPC Socket field of the Server Settings window. If this queue is not already defined for the server, it will appear in the Server Information dialog box, on the Server Ports and Queues tab, after you enter it in the Server Settings dialog box.

For more information about defining server ports and queues, see the Configuration Guide, “Server Information—Ports and Queues tab,” page 153.

How the approval server uses RPC settingsIn releases earlier than BMC Remedy Approval Server 7.5.00, RPC settings were used as follows.

The approval server used the following RPC program numbers (defined by using fields on the AP:Admin-ServerSettings form):

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

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

These values were supposed to be different because they were used for different functionalities.

Beginning with release 7.5.00, the approval server uses the Visualizer sub-plugin to render previews (different from the Preview feature implementation). Therefore, the same RPC queue can be used for approval processing as well as preview generation.

Following this change, the RPC settings are provided by default at the time of installation or upgrade:

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

! When upgrading to release 7.5.00 or later:

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

! If Approval-RPC-Socket is not defined, but other Private-RPC-Socket entries exist, the Private-RPC-Socket and Approval-RPC-Socket entries are created and set to the next available valid value.

If this value is not specified, approval processing is done through the default admin queue.



! If Plugin-Loopback-RPC-Socket is not defined, the corresponding entry is created and set to the same value as that of Approval-RPC-Socket.

By default, the approval server uses this socket to run the Visualizer sub-plugin.

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

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

! To configure the server settings on the Basic tab

1 Open the AP:Administration form in BMC Remedy User or a browser.

2 Click the Server Settings link in the navigation pane.

3 On the AP:Admin-ServerSettings form, open the Basic tab (Figure 2-3 on page 30).

Figure 2-3: AP:Admin-Server Settings form



4 To generate a log of the approval server activity, check Approval Debug Mode.

5 In the Log File Name field, type the full path to the debug log file.

See “Approval server debug log” on page 27.

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

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

! A larger number can increase AR System performance.

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

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

7 To cause the approval server to use a dedicated private queue when it makes calls to the AR System server, enter an RPC port number in the Private AR Server RPC Socket field.

Choose an available RPC port number from the valid ranges. See “Private queues for loopback calls” on page 28.

Leave this field empty if your approval server implementation does not use a dedicated queue for loopback calls to the AR System server.

8 To cause the approval server to use the plug-in loopback RPC socket for loopback calls, as required for the preview feature, enter the loopback queue RPC port number in the Plugin Loopback RPC Socket field. Use an RPC port number from the ranges given in step 7.

Leave this field empty if your Plug-in server does not use a dedicated loopback RPC port. See “Plugin Loopback RPC Socket” on page 28.

9 Specify the Due-Soon Interval in Hours or Days for approval requests to be highlighted when an approver logs in to Approval Central.

10 Specify the Recent History Interval in Hours or Days for the approval requests to be displayed in the My Recent History section of Approval Central for an approver.

11 Click Save to save your changes.

12 If you set a value for either the Private AR Server RPC Socket or Plugin Loopback RPC Socket field, restart the AR System server.

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

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



! To define the events that trigger notifications

1 Open the AP:Administration form in BMC Remedy User or a browser.

2 Click the Server Settings link in the navigation pane.

The AP:Admin-ServerSettings form appears.

3 Click the Notifications tab.

4 Select the appropriate option button for each event.

! Disabled—Select Disabled if you never want the event type to trigger a notification.

! Enabled—Select Enabled for each event type that you want to send a notification.

! Enabled Including Alternate—Select this setting if you want the event to trigger a notification for both the intended approver and any designated alternates.

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

! To define approval events that can trigger notifications

1 Click the Escalations tab.

2 Select the appropriate option buttons to determine which event types are Disabled, Enabled, or Enabled Including Alternate, as defined in “Configuring settings on the Notifications tab” on page 31.

3 Click Save.

Configuring business timesThe approval server uses the data in the business time forms to schedule approval notifications. Business time in AR System is the ability to define periods of availability and unavailability, workdays, and holidays to calculate business schedules using AR System commands.

You must configure business times to assure that your approval notifications and escalations calculate times correctly. For information, see the Configuration Guide, “Using Business Time in the AR System server,” page 213.


Configuring previews

Configuring previewsThe AP:PreviewInfo form allows requesters and approvers to get a list of the completed and remaining approvals for any request. This is referred to as “previewing” approvals.

To allow users to preview approval responses, you must perform the following configuration actions:

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

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

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

! Create workflow that uses the Add-PGNA-Values command to gather signatures. See “Defining Parameterized Get Next Approver rules” on page 126.

Configuring the approval server to work with flowcharts

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

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

! On the Ports and Queues tab, check whether a private RPC private port has been defined for the approval server. The values of Min Threads and Max Threads for this port should be greater than one.

Also check whether the same port is used in the approval Plugin Loopback RPC Socket setting on the AP:Admin-ServerSettings form. See “Configuring settings on the Basic tab” on page 30.

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

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

http://ARSystemServerName:8080/arsys

For more information, see the Configuration Guide, “Configuring AR System servers,” page 120.



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

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

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

! Select the appropriate authentication server.

See the Configuration Guide, “Server Information—EA tab,” page 141.

NOTE You must have Flash version 9.x or later installed on the machine.

The flowchart view is backward compatible with mid tier 7.1.00 and 7.0.01. You can use any version of BMC Remedy User to see the flowchart view for an approval request, or view it through a browser.

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


Chapter

3
Processing approval requests
Approval Central is the primary console for the users of BMC Remedy Approval Server (approval server).

This section describes how approvers use Approval Central to process approval requests, how approvers and process administrators specify alternate approvers, and how process administrators carry out approval overrides.


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



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

! Search for approval requests by specifying certain criteria

! View approval request details

! Approve or reject requests

! Put requests on hold

! Define alternate approvers

! Reassign a request to another approver

! Create or respond to More Information requests

Process administrators use Approval Central to override approvers to respond to requests when necessary. Approvers also use Approval Central when acting as alternates for other approvers.

Figure 3-1: Approval Central as seen by the sample user Jack Miller

For more information, see “Approval Central” on page 255.


Opening Approval Central

Opening Approval CentralThis section describes the different ways to open Approval Central.

! To open Approval Central from the AR System Home Page

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

! To open Approval Central in a browser

1 Launch your browser and enter a URL as follows:

http://hostName/arsys/forms/serverName/Approval Central

where hostName is the name of the web server where BMC Remedy Mid Tier is running, and serverName is the name of the AR System server where the approval server is running. Ask your AR System administrator for the exact URL.

2 In the BMC Remedy Mid Tier login window, enter your user name and password, along with an authentication string if necessary, and click Log In.

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

! To open Approval Central in BMC Remedy User

1 Open BMC Remedy User, and log in to the appropriate AR System server.

2 Choose File > Open > Object list.

The object list appears, showing the objects that you have access to. This list might include the Approval Central entry point and the Approval Central form.

3 Select the Approval Central form, and click New or Search.

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

AR System Object List in browsersThe AR System Object List displays a list of all forms (including Approval Central) and other object types for which the user has permissions. The AR System administrator can make the object list available in a browser, by entering the URL http://hostName/arsys/forms (hostName is the name of the web server where BMC Remedy Mid Tier is running).

For information about how to make the AR System Object List available in a browser, see the BMC Remedy Mid Tier Guide, “Enabling the AR System Object List,” page 88.

For information about AR System server objects, see the Form and Application Objects Guide and the Configuration Guide.



Working with pending approval requestsThis section describes how to search for specific approval requests, and provides procedures for managing and responding to approval requests.

The examples in this section are from the sample applications Get Agreement and Lunch Scheduler, which are installed with the approval server. For more information about the sample applications, see Chapter 4, “Using the Get Agreement sample application” and Chapter 8, “Using the Lunch Scheduler sample application.”

Processing an approval requestApprovals typically follow this sequence:

Step 1 Someone submits a request that requires your approval.

Step 2 You receive notification of the approval request.

Step 3 You review the approval request and take one of the following actions:

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

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

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

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

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

! Acting As = “MySelf”

! User = “yourARSystemUserID”

! Approval Status = “Pending” or Approval Status = “More Information” or Approval Status = “Hold”

Using this query, AR System searches for requests that are awaiting your action. If any requests are found, they appear in the Pending Approvals table.

The Approval Tasks section provides more predefined searches. You can also use the Search My Approvals link in the Action Menu section to open the Approval Search section in the right pane. Specify your search criteria in this section, and click the Search button to display a set of requests in the Approval Search Result table.


Working with pending approval requests

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

The following procedure is an example of how to retrieve a list of requests pertaining to a particular application.

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

1 Open Approval Central using one of the methods described in “Opening Approval Central” on page 37.

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

3 In the Approval Search section, select AP-Sample2:Get Agreement in the Application field, and select (clear) in the Status field.

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

The Approval Search Result table then displays all requests that belong to the AP-Sample2:Get Agreement sample application for the current user.

For information about how to add an application to the Application field, see “Connecting an application to the approval server” on page 152.

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

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

1 Open Approval Central using one of the methods described in “Opening Approval Central” on page 37.

2 In the Pending Approvals table, use the check boxes to select the pending requests that you want to act upon.

3 Click Approve, Reject, Hold, or Reassign.

If the related approval processes require approvers to enter a password, the AP:Password dialog box appears.

4 If necessary, enter your password when prompted, and click Submit.

If you click Reassign, and the related approval processes are enabled for reassignment, the AP:Reassign dialog box appears.

5 If necessary, enter the name of the person to whom you want to reassign the requests, and click OK.

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



WARNING No “undo” option exists when you respond to a request. After you respond to a request, you do not have any opportunity to change your mind.

If you click Approve and other approvers are required, AR System routes the requests to the respective next approvers. If you click Approve and no further approvers are required, the request statuses change to Approved, and the approval process is done. If you click Reject, the request statuses change to Rejected, and the approval process is done. If you click Hold, the request statuses change to Hold until any further action is performed on them.

If you provide an incorrect password, the error “Authentication failed. Please enter your valid AR System password. (ARERR 45490)” appears, and no action is performed on the selected requests.

Rejection justification for approval requestsOn Approval Central or AP:Show-Detail, approvers can provide a justification for rejecting a request by entering some meaningful text in the Justification For Action field and clicking Reject.

The justification is stored as a note in the Approval Activity Log, and pushed to:

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

! AP:Signature, from where the application can access it

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

Currently, this feature is associated only with the Reject action. If an approver enters a justification and clicks any other action button, the request status changes as appropriate, but the text is not stored at any location.

The mandate for providing a justification is configurable at the process level. Process administrators can use the Rejection Justification area on the Configuration tab of AP:Process Definition to specify:

! whether an approver must provide a justification when rejecting a request

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

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

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

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

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

! If the approver clicks OK without entering some text in the Justification field, the following message is displayed:

Please enter appropriate rejection justification. (ARNOTE 46409)



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

Applications can also enable approvers to provide rejection justification on the three-way join form. To make this possible, application developers must:

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

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

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

The processName process requires a rejection justification, which the approver failed to provide.

See “Creating the join forms” on page 153 and Appendix D, “Approval forms.”

For general information about join forms, see the Form and Application Objects Guide, “Join forms,” page 116.

Working with request detailsThe View Details button on Approval Central opens the AP:Show-Detail form, which enables you to see more details about a request. You can also approve, reject, or hold an approval request, add ad hoc approvers, reassign a request to another approver, and create or respond to More Information requests using this form.

On Approval Central, the Source ID link that appears in the Approval Request Summary section for a request opens the relevant application form. Click the Show Signatures button on the application form (if implemented) to open the three-way join form associated with the application request. This document also refers to this view as the “detail view.” The following procedures use this detail view to perform various actions on an approval request.

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

! To approve an approval request by changing the Approval Status field

1 Open Approval Central by using one of the methods described in “Opening Approval Central” on page 37.

2 In the Pending Approvals table, select the pending request you want to work with, and click its Source ID link in the Approval Request Summary section.

The appropriate request form opens (for example, AP-Sample2:Get Agreement).



3 Click the Show Signatures button.

The appropriate three-way join form opens (for example, AP-Sample2:Issue Detail Signat).

Figure 3-2: Setting the Approval Status field

4 Click the drop-down arrow on the Approval Status field, and choose Approve, as shown in Figure 3-2.

To ask for more information about the request, see “Processing More Information requests” on page 45.

5 If the Password field is present, enter your password. Otherwise, proceed to the next step.

If a password is required and you do not enter your password, or if you enter the wrong password, AR System returns the following error:

Authentication failed. Please enter your valid AR System password. (ARERR 45490)

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

6 Click Save.



You can use the same procedure to reject or hold a request by setting the Approval Status to Rejected or Hold.

For information about how to configure an approval process to require a password, see “Creating a process” on page 98.

When you return to Approval Central and refresh the search, this request is removed from the table of pending requests.

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

Specifying additional approversPerform the following procedure if you must specify the next approver instead of automatically routing the request. With some processes, such as an Ad Hoc process, approvers can or must specify additional approvers. The process administrator can also configure Parent-Child, Level, and Rule-Based processes to allow users to add the next approver with the Allow Ad Hoc Next Approver field. See “Creating a process” on page 98.

You must specify the additional approvers before or at the same time as you approve or reject the approval request. After you have approved or rejected the request, you no longer have access to the Next Approvers field.

NOTE If the approval process includes rules that specify the next approver, the process rules supersede any changes you make in the detail-signature view.

Specifying the next approver is not the same as reassigning an approval request. The option to specify the next approver also requires you to approve or reject the request. For information about reassigning requests, see “Reassigning approval requests” on page 45.

! To specify next approvers



The relevant request form appears.

3 Click the Show Signatures button.

The appropriate three-way join form.



Figure 3-3: Adding multiple approvers

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

You must enter one or more AR System login IDs. To specify multiple approvers, separate each name with a semicolon (;).

5 If you specify multiple approvers, determine the appropriate option for the If Multiple Approvers field.

! One Must Sign—A single signature entry is created for all approvers. Only one of those approvers needs to take action.

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

NOTE In an Ad Hoc approval process, if you do not complete the If Multiple Approvers field, AR System requires all additional approvers to sign the request.

6 In the Approval Status field, select Approved.

7 Click Save.

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


Processing More Information requests

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

! To reassign an approval request



3 In the request form, Click the Show Signatures button.

4 In the Reassign To field on the three-way join form, enter the name of the approver to whom you want to reassign the request.

You can enter only one person’s AR System login ID.

5 Click Save.

The approval server routes the request to the reassigned approver.

Processing More Information requestsIf you need more information before approving or rejecting an approval request, you can send a More Information request, which is an independently-routed AR System record. The approval server uses the AP:More Information form to manage More Information requests.

When you create a More Information request, the approval server links it to the original approval request and changes the status of the approval request to More Information. Thus, others can see that the request is paused until the More Information request is answered.

Your response to the original approval is independent from the More Information request’s routing. In other words, you do not have to wait for the More Information response before approving or rejecting the approval request. However, if you do approve or reject the original approval request, the approval server immediately closes any related outstanding More Information requests.

The procedures in this section describe the basic steps for requesting more information and responding to More Information requests.

! “Requesting more information about approval requests”

! “Viewing and responding to More Information requests” on page 47

! “Viewing pending More Information requests and responses” on page 48

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



Requesting more information about approval requestsUse the following procedure to request more information before approving a request.

! To request more information about approval requests



3 On the application request form that appears, click the Show Signatures button.

4 On the relevant detail form that appears, click Manage More Information.

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

5 On the AP:Dtl-Sig-MoreInfoDialog form, click New Record to create a More Information request.

6 On the AP:More Information form, specify values in the various fields as follows:

a In the To field, enter the name of the person from whom you want more information.

This can be the original requester or any other person, but it must be that person’s exact AR System login ID.

b In the Question field, enter a description of the information you need.

Figure 3-4: Creating a More Information request



c Click Save.

The More Information form closes, and the pending More Information request appears temporarily in the More Information Requests table on the AP:Dtl-Sig-MoreInfoDialog form.

d Click Close.

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

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

! To view and respond to More Information requests to you


By default, the Pending Approvals table displays requests with the Pending, Hold, and More Information, status.

2 To view requests with the More Information status only, in the Approval Tasks section, click Needs Attention.

3 The Needs Attention Approvals table displays the list of More Information requests that are awaiting your attention; select a request to view its details.

4 In the Approval Request Summary section, click Response.

The AP:More Information form opens in Modify mode, and More Information requests directed to you are listed in the results table included on the form.

5 Select the request you want to respond to from the results list.

The details area of the form changes to show details of the selected More Information request.

6 Type your answer in the Response field, and click Save.

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

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



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

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

! To view a More Information response


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

3 On the AP:Show-Detail form, open the Activity Log tab.

4 Click the row pertaining to your Question or Comment.

The response is visible in the appropriate field of the Activity Log Details section.

You can access More Information requests that you have submitted by finding the related approval request in Approval Central, and clicking the Manage More Information button in the details view to access the related More Information request.

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



! To view a pending More Information request


By default, the Pending Approvals table displays a predefined number of requests, including those in the Pending, More Information, and Hold states.

2 To view More Information requests only, click the Needs Attention link in the Approval Tasks panel.

This action also displays only a predefined number of requests at a time.

3 To view the complete list of More Information requests awaiting your attention, perform a search as follows:

a More In the Action Menu section, click Search My Approvals.

b In the Approval Search section, select More Information in the Status field, and click Search.

The Approval Search Result table displays the requests for which the status is More Information.

4 In the Approval Search Result table, select a request and click View Details.

5 On the AP:Show-Detail form, open the Activity Log tab.

6 Click the row pertaining to your Question or Comment.

The Activity Log Details section displays the corresponding details.

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

! To retrieve all your More Information requests

1 In BMC Remedy User or a browser, open the AP:More Information form.

2 Enter your AR System user name in the From field, and click Search.

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

3 Select a request from the results list.

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



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

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

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

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


Using alternate approvers

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

Figure 3-7: Creating an alternate approver

! To designate alternate approvers


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

The AP:Alternate form opens in New mode.

3 In the Alternate field, enter the AR System login name of the person to designate as your alternate.

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

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

! All—To authorize the alternate to approve all processes for which you have signature authority.

! Specific—To authorize the alternate to approve a specific process. Then select a process from the Process list.

6 In the Notify Alternate field, select Yes to send notifications to the alternate for each new approval, or No to prevent notifications to the alternate.

7 Click Save.

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



Viewing and modifying alternate approver definitionsUse the procedures in this section to view or modify existing information about an alternate approver.

! To view and modify the record for an alternate approver


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

The AP:Alternate form opens in New mode.

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

The results list appears, containing a list of your past, current, and cancelled alternates.

4 To see details, select the record you want to view; the record details appear in the details pane.

5 Modify the fields you want to change.

6 If you want to cancel this approver, select Cancelled from the Status field.

7 Click Save to save your changes, or Close to close the record without any changes.

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

Viewing requests for which you are an alternate approverIf you are acting as an alternate approver, you have the same signature authority as the approver for whom you are serving. Your authority as an alternate approver exists for a specific time period, and for the designated approval processes.

By default, Approval Central displays requests assigned to other approvers for whom you are designated as an alternate approver. You can identify such requests by looking at the Acting As column in the approval requests table. The requests for which there is no value in the Acting As column, are directly assigned to you.

Figure 3-8 on page 53 depicts the Approval Central view of Violet Anderson, whom Jack Miller and Larry Goldstein designated as an alternate approver for a certain period. Approval Central displays only a predefined number of requests at a time. To view all requests on which you can act as an alternate approver, perform a search as described in the following procedure.


Using alternate approvers

Figure 3-8: Acting as an alternate approver

! To view all requests for which you are an alternate approver



3 In the Approval Search section:

! In the Acting As field, select Alternate.

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

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

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

! Verify that the Status field is set to Pending.

! Click Search.

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



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

! To define alternates for other approvers

1 Open the AP:Alternate form in New mode.

2 Create an alternate as described in “Designating alternate approvers for yourself” on page 50.

3 In the For field, replace your user name with the AR System user name of the person this alternate will be substituting for.

4 Click Save.

Performing overridesThe override capability of the approval server allows a process administrator to move an approval process forward when the normal approver has not responded. An override is useful in an unexpected situation, such as when the normal approver is unavailable but did not designate an alternate.

A single-signature override closes one approver signature, similar to acting as an alternate approver for one signature line, and allows the approval request to continue within the regular process. In this case, an override rejection terminates the request just as if the normal approver had rejected it. An override approval moves the request forward just as if the normal approver had approved it. If more approvers exist, the request is routed to them.

A global override closes all open signatures, stops routing the request, and terminates the approval process for that request. The global override is useful for unusual situations, such as ending an approval process for a request that is no longer necessary.

A process administrator can assign override-only authority to any user without granting other approval process administrator privileges. For more information, see “Configuring process administrator capabilities” on page 26.


Performing overrides

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

! To perform an override to a single signature

1 Log in to AR System as the process administrator for the process you need to override (such as the process administrator or AR System administrator).




! In the Acting As field, select Override.

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


! Click Search.

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

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

! To perform global overrides

1 Log in to AR System as the process administrator for the process you need to override (such as the process administrator or AR System administrator).




! In the Acting As field, select Global Override.


! Click Search.

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


Chapter

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


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



Overview of the Get Agreement applicationIf you installed the approval server sample applications, you can use them to understand and test the approval server functionality. The Get Agreement sample application demonstrates an Ad Hoc process, in which the requesters and approvers choose who should approve the request. For more information about the Ad Hoc process type, see “Ad Hoc process” on page 78.

The procedures in this section use a set of sample users: Frank Williams, Jack Miller, Larry Goldstein, Violet Anderson, and Sue Smith. To follow the sample application procedures using these names, the AR System administrator must create the AR System user names, and they must be issued either floating or fixed write licenses. Because this is an Ad Hoc process, you can also substitute licensed user names that already exist on your system when you try these procedures.

In the sample procedures, Frank Williams (the requester) requests a new computer. The approvers use Approval Central to approve or reject the approval request, and to reassign an approval request to another approver. The sample users also send and respond to More Information requests.

The sample application demonstrates the use of Approval Central, an application request form (in this case, AP-Sample2:Get Agreement), and related forms, such as the three-way join form (AP-Sample2:Issue Detail Signat) and AP:More Information forms. It also demonstrates how to display the status of an approval request and how to identify the actions taken by each approver.

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

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

See “Opening Approval Central” on page 37.


Creating new approval requests

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

! To create a new approval request

1 Log in to the appropriate AR System server as the sample user Frank Williams.

2 In a browser, open AP-Sample2:Get Agreement in New mode using the URL:

http://hostName/arsys/forms/serverName/AP-Sample2:Get Agreement

hostName is the name of the web server where BMC Remedy Mid Tier is running, and serverName is the name of the AR System server where the approval server is running.

NOTE In this sample application, the Get Agreement form is the application request form.

Figure 4-1: The Get Agreement form in New mode

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



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

5 In the Initial Approvers field, type

Jack Miller; Larry Goldstein; Violet Anderson

Since this is an Ad Hoc process, you must enter at least one approver. In case of multiple approvers, separate the names with semicolons.

6 Click Save to save the request and begin the approval process.

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

! To approve an approval request

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

By default, the Pending Approvals table shows requests with the Pending, Hold, or More Information status for the current user. Because Jack Miller was included in the list of approvers, the “I need a new computer” request appears in the table.

Figure 4-2: Pending requests for Jack Miller on Approval Central

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

3 Click Approve.

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


Reassigning approval requests

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

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

! To reassign an approval request

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

2 From the Pending Approvals table, select the request “I need a new computer.”

3 In the Approval Request Summary section, click the Reassign button.

4 If prompted, enter your AR System password.

Figure 4-3: Violet Anderson reassigns Frank Williams’ request to Sue Smith

5 In the AP:Reassign dialog box, type Sue Smith, and click OK.

6 After returning to Approval Central, click Search to refresh the list of pending approval requests.

The reassigned request disappears from the Approval Requests table.



Requesting more informationThis section demonstrates how to seek more information about approval requests. It requires that you followed “Creating new approval requests” on page 59 and “Approving approval requests” on page 60.

To request more information about an approval request, you can create a separate More Information request. The AP:More Information stores the More Information request, and allows approvers to ask questions and have them answered before acting on an approval request.

! To create a More Information request

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

2 Select the “I need a new computer” request from the Approval Requests table, and click View Details.

3 On AP:Show-Detail, open the Activity Log tab and click Add.

Figure 4-4: Larry Goldstein asks Violet Anderson a question about Frank William’s request


Approval Status and More Information requests

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

a In the Type field, select Question.

b In the Question To field, specify the login name of the person from whom you need more information.

c In the Question field, enter appropriate text.

d Click Save.

An entry is added to the Activity Log table.

5 Click Close.

Approval Status and More Information requests

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

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

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

! To respond to a More Information request

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

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



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

4 In the AP:More Information form, enter the appropriate text in the Response field, and click Save.

The AP:More Information form closes. The More Information request is no longer visible to Violet after she responds to it. Also, after Violet responds to the More Information request, the Approval Status of the request changes back to Pending.

Figure 4-5: Violet Anderson responds to Larry Goldstein’s question

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


Viewing responses to More Information requests

Viewing responses to More Information requests

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

! To view the response to a More Information request

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

2 Select the approval request for which you sent a More Information request, and click View Details.

NOTE Until the recipient responds to the More Information request, the Approval Status of the associated approval request is More Information, rather than Pending. If you do not see the approval request you are looking for in the approval requests table on Approval Central, click the Search My Approvals link in the Action Menu panel and search for More Information requests.

3 On AP:Show-Detail, open the Activity Log tab.

4 In the activity log table, select the appropriate entry.

If your question has been answered, the answer will appear in the Response field in the Activity Log Details panel.

Figure 4-6: Larry Goldstein views Violet Anderson’s response to his question

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



Checking status of requestsThis section shows how to verify the status of an approval request that you created. It requires that you have followed “Creating new approval requests” on page 59.

Before trying you check the status of Frank Williams’ request, perform the following procedures (see “Approving approval requests” on page 60):

Step 1 Log in to AR System as Larry Goldstein, and approve the “I need a new computer” request.

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

! To check the status of an approval request you have sent

1 Log in to AR System as Frank Williams, open the AP-Sample2:Get Agreement form in Search mode, and click Search.

2 In the results list that appears, select Frank’s request for the new computer.

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


Checking status of requests

Figure 4-7: Frank’s approval request in the Get Agreement application request form

3 To determine which approvers have responded to the approval request, click Show Approver Signatures.

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



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

4 To determine which approver is associated with each status, select an entry from the results list.

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


Chapter

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


! Approval server data and forms (page 70)! Approval processes (page 72)! Approval server rules (page 82)! Approver fields (page 94)



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

Approval data and auditAs an approval request is routed through the approval process workflow, the approval server collects data about the request in the request form and in the approval server supporting forms. Some of this data is temporary, for use only during the process, while other data, such as signatures, is saved for audit purposes.

Because approval server processes are designed to implement business processes and rules, you can use the approval server data as an audit trail for any process that uses the approval server. The approval server collects the following data:

! The original request

! Electronic signatures of every person who approves or rejects a request

! More information requests and their responses

! Dates and times for each approval activity

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

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

Approval CentralSee “Approval Central” on page 36.

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


Approval server data and forms

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

NOTE Modify signatures only through Approval Central.

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

Approval request formAny application that uses the approval server must have an approval request form that users open to enter their approval requests.

For example, in the sample applications, the application request forms are AP-Sample2:Get Agreement and AP-Sample:Lunch Scheduler.

Three-way join formWhen you link your application to the approval server, you must create an inner join form by linking your application request form to the AP:Detail-Signature form. Because the AP:Detail-Signature form is also a join form, this join is referred to as a three-way join.

For example, in the Get Agreement sample application the three-way join form is AP-Sample2:Issue Detail Signat. It joins AP-Sample2:Get Agreement with AP:Detail-Signature.

See “Creating the join forms” on page 153. For general information about join forms, see the Form and Application Objects Guide, “Join forms,” page 116.

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



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

Signature authority formFor Parent-Child and Level process types, you create a signature authority form to define the relationships between approvers or levels.

For example, the Lunch Scheduler sample application uses the AP-Sample:Signature Authority form.

See “Approval process types” on page 75.

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

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

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

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


Approval processes

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

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

The approval server provides 13 types of approval rules. See “Approval server rules” on page 82.

Approval process stagesThe approval process ensures that all the necessary steps take place to complete any approval, while rules govern how the request is handled at various stages of the process.

Figure 5-1 illustrates the five stages of any approval process. The approval server checks for rules belonging to each stage during the approval process. Any given approval process does not require rules in all five stages, but most approval processes include rules in at least the approver response and Process Done stages.

Depending on the process design and the rules used, the approval cycle can include several iterations of the next approver, approver response, and Completion Check stages.

Figure 5-1: Approval process stages

2

1

5 4

3

Self Check

NextApprover

Moreapprovers?

ProcessDone

Requesterapproved

Requester not approved

No

Yes

Approved

More InformationRequest (optional)

CompletionCheck

SubmitRequest

Requester

Requester

Rejected

SomeoneEntirelyArbitrary

AnotherApprover

ApproverResponse

ApprovalCycle



An approval process starts when someone submits an approval request.

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

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

! Stage 3, Approver Response—In this stage of the process, approvers either approve or reject an approval request. This action completes the signature line for that approver. If an approver approves the request, the approval process continues. If an approver rejects the request, the approval process is usually done. (You can override this behavior with Signature Accumulator and Statistical Override rules).

The Approver Response stage is repeated as necessary, and is closely integrated with the Completion Check stage.

! Stage 4, Completion Check—The Completion Check stage accepts the results of the Approver Response stage, and checks to see if the routing of a request is complete. Routing is complete if all required approvers have received the request, whether they have responded. If all required approvers have not received the request, the process returns to the Next Approver stage.

The Completion Check stage is repeated as necessary until the Completion Check passes.

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

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


Approval processes

Approval process typesThe approval server provides four process types that you can choose from when designing an approval process. These process types differ in how the approval server identifies the next approver. They are known as Parent-Child, Level, Ad Hoc, and Rule-Based. Each is introduced in this section.

For an example of each process type, examine the sample applications installed with the approval server. For information about how to create, modify, and delete processes, see Chapter 6, “Defining an approval process.” For information about rules and how they are used with each process type, see “Approval server rules” on page 82. For information about creating rules, see Chapter 7, “Defining approval rules.”

Parent-Child processThe Parent-Child process type uses the relationships between requesters and approvers, and between approvers and other approvers, in conjunction with a Get Next Approver rule, to determine the routing of an approval request. You define these relationships in a signature authority form.

The Management Cost Authorization process in the Lunch Scheduler sample application is an example of a Parent-Child rule. It uses the Manager Login Name field on the AP-Sample:Signature Authority form to define the “parent” login name of each sample user.

In a process where each approver has a defined relationship to the next approver, such as employee to manager and manager to director, the most appropriate process type is usually Parent-Child. In this type of process, the approval request is routed up an approval hierarchy from the “child” (requester or previous approver with lower authority) to the “parent” (approver with higher authority). A manager-employee relationship is often the hierarchy represented with a Parent-Child approval process.



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

Figure 5-2: Parent-Child hierarchy

In a Parent-Child process, the approval server automatically routes the request to the next approver according to the defined relationship. Persons represented by “X” in the diagram do not receive the approval request because they do not have parent relationships with the requester or any approvers.

A rejection from any approver rejects the request for everyone in the hierarchy. This is also true if the process uses two or more separate approval hierarchies. Process administrators can configure notifications to inform all approvers when any other approver has rejected a request.

The following considerations apply to a Parent-Child process:

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

! When an approver marks an approval request as approved, the approval server automatically checks for the “parent” of that approver and, if one is found, routes the request to that person.

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


Approval processes

Level processThe Level process type uses a hierarchical set of organizational levels, in conjunction with a Get Next Approver rule, to determine the routing of an approval request. The process administrator defines the organizational levels and their members in a signature authority form.

The Major Account Level Approval process in the Lunch Scheduler sample application is an example of a Level process. It uses the Account Approval Level field of the AP-Sample:Signature Authority form to define organizational levels and the sample users who belong to them.

If anyone in a certain organizational position, such as a job level, can approve a request, the Level process type is often the best fit. In a Level process, the approval server delivers the request to all approvers in the next level. When the defined number of approvers in any level have approved the request, the approval server routes the request to the next level.

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

Figure 5-3: Level process with three levels

In a Level process, a request must be approved by at least one approver in each level before it passes to the next level. The approvers for a given level can consist of individuals or roles. A Level process does not dictate the number of approvers on each level. You can set up routing to the next level to require signatures from any number of individuals in each level. For information about configuring roles, see “Defining roles” on page 106.

A Level process uses a level value to indicate the position of individuals or roles. The approval server uses the value in the level field to determine an approval sequence, starting with level 0. The highest level is 1000. The approval server skips over unused levels.



The following considerations apply to a Level process:

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

! The process rules must be configured to determine whether a request should be routed to more than one person in each level.

Ad Hoc processIn an Ad Hoc process, no Get Next Approver rule is used, and the process administrator does not define approver or organizational relationships. Instead, the requester and the approvers designate the next approver or a set of approvers while working with the request. The requester enters at least one approver when creating the request. Approvers can add additional approvers when they respond to the request.

The Issue Approval process in the Get Agreement sample application is an example of an Ad Hoc process.

Figure 5-4: Routing two requests in the same Ad Hoc process

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


Approval processes

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

Rule-Based processThe Parent-Child, Level, and Ad Hoc process types are partially preconfigured and, therefore, are relatively simple to implement. A Rule-Based process is similar to a Parent-Child process, except that a Rule-Based process relies on rules that you create to define the relationships between approvers. This option enables you to define a routing method that allows more complexity than predefined relationships. However, a Rule-Based process requires more thought and work to implement.

The Special Overdue Approval process in the Lunch Scheduler sample application is an example of a Rule-Based process.

Summary of process typesThe approval server handles approval requests with one of four process types. Processes and their rules are configured by a process administrator.

Table 5-1: Summary of process types

Process type Routing method Determining next approver

Parent-Child Hierarchy of individuals. The process administrator defines the relationships between individuals.

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

Level Hierarchy of organizations. The process administrator defines the levels and their members.

Get Next Approver and Parameterized Get Next Approver rules determine the next level and approvers.

Ad Hoc Routing is based on the approvers entered by the requester or approvers.

Determined manually by users.

Rule-Based Custom, as determined by the Process Administrator.

Custom, as determined by the Process Administrator. Parameterized Get Next Approver rules can add approvers.



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

The options are:

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

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

! (Process-level only) Allow Only One Approver—The approval server creates a single signature entry for an approver. If a requester specifies multiple approvers for a request, the approval server returns an error.

Action date for a process or signatureEach approval server process and signature can be associated with an action date. The action date enables approvers to know in advance the duration within which to take action on requests assigned to them. Process administrators can use this value to determine whether a process is on track or needs intervention (automatic or manual). This helps in addressing requests and driving them to completion in a timely manner.

In BMC Remedy Approval Server 7.5.00, the action date is based on the Automatic Action interval defined for a process. For more information, see the BMC Remedy Action Request System 7.5.00: BMC Remedy Approval Server Guide.

Beginning with release 7.6.03, the action date is calculated by using the following fields on the tabs of AP:Process Definition:

! Configuration—Process Due, Signature Due, Buffer Period, and Enable Preview

! Signature Escalations—Automatic Action and Notification (First) intervals

Applications can override the Process Due interval by directly passing the desired Process Due Date as a parameter of the New-Details command. For more information, see “New-Details” on page 187.

The action dates for processes and signatures are stored in the following fields:

! Process Due Date (ID 11000) on AP:Detail

! Signature Due Date (ID 12000) on AP:Signature

NOTE Using Enable Preview to determine the action date might increase the processing time for a new request due to the steps required to retrieve the list of future approvers.

When working with notifications and escalations, make sure that the appropriate notification and escalation types on AP:Admin-ServerSettings are enabled.


Approval processes

How action date for a Parent-Child or Level process is calculatedWhen the first signature is created for a request, the Process Due Date is either derived from the Process Due period defined on AP:Process Definition, or set to the value sent by the application through New-Details. If the application specifies the Process Due Date value, the value in Process Due field is ignored.

If Enable Preview is set to Yes, the total number of approvals in the process is calculated by fetching the future approvers with the help of the Preview feature. The effective Signature Due period is calculated as follows:

signatureDue = (Process Due / totalNumberOfApprovals)

This value is then compared with the one specified in the Signature Due field, and the minimum of the two is considered.

effectiveSigntaureDue = MIN (Signature Due, signatureDue)

If no value is entered in the Signature Due field, the derived signatureDue is used for further computation.

The action date for a signature is calculated as follows:

Action Date = MIN (effectiveSignatureDue, Automatic Action interval-Buffer Period, Escalation interval-Buffer Period)

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

How action date for an Ad Hoc process is calculatedWhen the first signature is created for a request, the Process Due Date is either derived from the Process Due period defined on AP:Process Definition, or set to the value sent by the application through New-Details. If the application specifies the Process Due Date value, the value in Process Due field is ignored.

The value of Enable Preview is ignored, because the ad hoc nature of the process makes it impossible to identify the future approvers.

The action date for a signature is calculated as follows:

Action Date = MIN (Signature Due, Process Due date-Buffer Period, Automatic Action interval-Buffer Period, Escalation interval-Buffer Period)

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



Approval server rulesThe approval server includes 13 rule types that are used in various stages of an approval process. A given process does not usually include all types of rules, and some do not include all five process stages. This section introduces the rule types included with the approval server, and describes how they function in the approval process.

Figure 5-5 illustrates how each rule type fits into the overall approval process.

Figure 5-5: Rule types in the approval process

Self Check stage—Rules that test for automatic approval and self approval

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

! Auto Approval

! Get Authority or Get Authority Self

! Self Approval

5

ApprovalCycle

2

1

4

3

Outstandingsignatures?

No

No

Yes

Yes

Get Authority

SignatureAccumulator

Get AuthorityRegular

ParameterizedGet NextApprover

Signatureline error

Ad hoc?

ValidateApprover?

Moreapprovers?

ApproverResponse

No

No

Yes

Yes

Valid

Invalid

Approved

Rejected

(Wait for)CorrectionAuto Approval?

Selfapproval?

ProcessDone

Yes

No

Yes

No

GetAuthority

GetAuthority

Self

Submit Request

Requester

Completion

Get Next Approver

Prep. GetNext Approver

StatisticalOverride


Approval server rules

The Auto Approval and Self Approval rule types use different methods to determine whether the requester has sufficient authority to approve his or her own request. The Get Authority and Get Authority Self rules gather data to be used by the Self Approval rule.

Figure 5-6: Details of Self Check stage rules

Auto Approval rulesThe approval server first tests for an Auto Approval rule. Automatic approval occurs when any user has authority to approve a given request, independent of the user’s role in the organization or within the AR System. When an Auto Approval rule condition is met, the request is done, and moves directly to the Process Done stage. In Auto Approval rule, the rule condition contains the authority criteria, which applies to all users.

For example, if an Auto Approval rule says that everyone in the company can be reimbursed for a business lunch up to $40, and Frank requests approval for a $25 lunch, the Auto Approval condition is met and the approval server uses the Auto Approval rule to automatically approve Frank’s request.

The Management Cost Authorization process of the Lunch Scheduler sample application contains an example of an Auto Approval rule. To create an Auto Approval rule, see “Defining Auto Approval rules” on page 114.

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

21Auto Approval?

SelfApproval?

ProcessDone

Yes

No

Yes

No

GetAuthority

GetAuthority

Self

Submit Request

Requester

NextApprover

ApprovalCycle



Get Authority and Get Authority Self rules

These two rule types collect data, such as a monetary amount, that determines the limits of the current approver’s authority. The information collected by either the Get Authority or Get Authority Self rule is used by any Self Approval rules that exist in the process.

The difference between Get Authority and Get Authority Self rules is in when they run during the approval process. The approval server runs Get Authority rules during both the Self Check stage and the Completion Check stage of the approval process. It runs Get Authority Self rules only in the Self Check stage. You determine which rule type to use based on the data you need to gather in each stage of the approval process.

You can use a combination of get authority rule types in a process that requires more than one type of get authority check. For example, a company’s business rules might require one set of self approval levels for expenses (such as $100 for regular employees, $200 for managers and above), but another set of approval limits for major purchases (such as up to $5000 for managers and higher expenses requiring three approvers including a Vice President). A process to support these business rules would include two different signature authority forms. A Get Authority Self rule would support the Self Approval rule, and a Get Authority rule would support the Get Next Approver rules.

The Cost Get Approval Authority rule in the Lunch Scheduler sample application is an example of a Get Authority rule. To create Get Authority rules, see “Defining all Get Authority rules” on page 116.

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

Self Approval rules

Self Approval rules test data collected by the Get Authority or Get Authority Self rules to determine whether the requester has sufficient authority to approve the request. When a Self Approval rule’s conditions are met, the request is done.

The following is an example of a self approval rule: If Frank requests approval for a $50 business lunch, the condition of the $40 Auto Approval rule is not met. In this case, the Self Check stage continues with a Get Authority or Get Authority Self rule to collect Frank’s employee status. The data gathered shows that Frank has authority to approve lunches up to $100. The Self Approval rule uses this data to test whether Frank has authority to approve his own $50 lunch.

The Cost Approve for Myself rule in the Lunch Scheduler sample application is an example of a Self Approval rule. To create a Self Approval rule, see “Defining Self Approval rules” on page 118.



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

Rule types used in the Next Approver stage include:

! Prep Get Next Approver

! Get Next Approver

! Parameterized Get Next Approver

! Validate Approver

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

Prep Get Next Approver rules

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

Get Next Approver rules

Get Next Approver rules are the heart of approval processing. They route requests to the next valid approver and create a signature line for each required approver. When configuring an approval process, the process administrator defines a list of valid approvers. Get Next Approver rules use this approver data to determine who is next in the approver list and to create signature lines for each approver.

The sample applications contain the following examples of Get Next Approver rules, in each type of process where these rules are used:

! Cost Get Next Approver, in the Management Cost Authorization process (a Parent-Child process)

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

! Overdue Assign Approvers, in the Special Overdue Approval process (a Rule-Based process)

To create a Get Next Approver rule, see “Defining Get Next Approver rules” on page 121.



Get next approver manuallyFor some approval processes, it is appropriate to allow requesters or approvers to specify the next approver, or to add an approver at another level. In this case, the approval server identifies the next approver based on what the user enters.

Several situations allow approvers to designate additional approvers. These are:

! An Ad Hoc process, which requires all approvers to be added by the users, as described in “Ad Hoc process” on page 78.

! An ad hoc override, in which you configure the process to allow approvers to alter the predetermined routing. This is controlled by the Allow Ad Hoc Next Approver? field on the Basic tab of the Process Definition form. See “Creating a process” on page 98.

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

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

Parameterized Get Next Approver rules

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

The Parameterized Get Next Approver rule works exactly like a Get Next Approver rule, with the following exceptions:

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

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

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

To create a Parameterized Get Next Approver rule, see “Defining Parameterized Get Next Approver rules” on page 126.

Validate Approver rules

The approval server uses Validate Approver rules to protect against inappropriate ad hoc assignments. If the test to validate the approver fails, the user assigning the invalid approver receives an error and must correct it before the request can proceed.

The Issue Validate Approvers rule in the Get Agreement sample application is an example of Validate Approver rules. To create a Validate Approver rule, see “Defining Validate Approver rules” on page 129.



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

Figure 5-7: Get Next Approver rules

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

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

Signatureline errorSelf Check

Moreapprovers?

ApproverResponse

ProcessDone

Approved

Notapproved

No

Yes

Approved

CompletionCheck

Submit Request

Requester

Rejected

(Wait for)Correction

ParameterizedGet NextApprover

Ad hoc?

ValidateApprover?

Get Next Approver

Prep. GetNext Approver

No

Yes

Valid

Invalid

ApprovalCycle



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

! Approved—When an approver approves a request, the request passes to the Completion Check stage, where the approval server determines whether more signatures are required. See “Completion Check stage—Rules that test for completion” on page 91.

! Rejected—If an approver rejects a request, the request moves to the Process Done stage. No more routing occurs, and the request is withdrawn from approvers who have placed the request on hold or requested more information.

! Hold—When an approver places a request on hold, the approval server changes the signature line to Hold, but no other action occurs. Process administrators should establish escalations to prevent requests in Hold status from being neglected indefinitely.

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

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

! Signature Accumulator

! Statistical Override

Signature Accumulator and Statistical Override rulesSignature Accumulator and Statistical Override rules can use ratios between approved and rejected signatures to determine the outcome of a process. These rules preempt the usual routing to bring the approval process to a conclusion based on statistics that you define. These two rule types are also known collectively as “statistical decision-making rules.”

An example of a statistical decision making rule is: “If more than 50% of the approvers approve the request, then approve the process.” With this rule in place, if the approval request has a list of five approvers, and the first two approvers reject the request, the remaining approvers are still given a chance to approve it. If the last three approvers approve the request, the request is approved overall.

Signature Accumulator and Statistical Override rules run during the Approver Response stage (whenever an approver responds to a request). If any Statistical Override rules are defined, then the statistical decision-making approval process begins. If no Statistical Override rules exist, the approval server follows its default logic, and the request moves to the Completion Check or Process Done stage.



Signature Accumulator rulesA Signature Accumulator rule collects statistical information about the signature records associated with an approval process, for use in a Statistical Override rule. You define the criteria for counting signatures.

In a Level process, only signatures associated with the current level are included in the set. These are referred to as “current signature records.” In all other process types, all signatures associated with the detail record are included in the set.

For each signature record, the approval server applies each existing Signature Accumulator rule, provided the Run If qualification passes. For example, if the approval server finds four signatures to check, the server runs all the Signature Accumulator rules on the first signature, then on the second signature, and so on until all the signatures are finished.

Examples of Signature Accumulator rules are included in the sample applications. They are Issue Increment Signature Limit and Issue Retrieve Signature Limit, in the Get Agreement Sample application. For information about using these examples, see “Example of decision-making rules in a sample application” on page 133. To create a Signature Accumulator rule, see “Defining Signature Accumulator rules” on page 131.

Statistical Override rulesA Statistical Override rule preempts the default behavior of the approval process and causes the process to be approved or rejected before all pending signatures have been completed. To do so, the rules check whether the statistical conditions required for making a decision have been satisfied.

Statistical Override rules can perform one of three actions: approve, reject, or do nothing. If a Statistical Override rule approves or rejects a request, the request is done and moves to the Process Done stage. If the conditions for approving or rejecting are not met, the process continues the default behavior of checking for more signatures to gather.

When the Statistical Override rule approves or rejects a request, the normal approval process is preempted by performing the following actions:

Table 5-2: Process and signature considerations in the Statistical Override rule

Process type Signatures considered Approving requests Rejecting requests

Level Only signatures for the current level

Preempts the approval server to proceed to the next level.

Preempts the approval server to reject the request and stop the processing.

Parent-Child All signatures, at all times

Preempts the approval server to proceed to proceed to next parent.


Ad Hoc All signatures, at all times

Preempts the approval server to approve the request.


Rule-Based All signatures, at all times

Preempts the approval server to proceed to the next set of approvers.




WARNING If you define Statistical Override rules, you must also define a rule to approve or reject the process if no pending signatures exist. If a rule is not defined to handle this condition, the approval server considers this as an error condition.

Figure 5-8 illustrates how the approval server uses both types of statistical decision-making rules in the Approver Response stage.

Figure 5-8: Statistical decision-making rules in Approver Response stage

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

The following statistical data is available by default:

! Total Signatures

! Total Approved

! Total Rejected

! Total Pending

StatOverrideRules?

Preempt?

Approve?RejectNo

No

Yes

Yes

ApproverResponse(Approval/Rejection/

Cancellation)

StatisticalRules

Cancel ActiveSignatures


StatisticalOverride

Wait for moreSignatures

MoreSignatures?

Error

DefaultLogic

DefaultLogic

Yes

No

No

Yes



! Total Hold

! Total More Information

! Total Canceled

! Total Closed

! Total Error

Examples of Statistical Override rules are included in the sample applications. They are Issue Statistical Approval and Issue Statistical Boundary Condition in the Get Agreement Sample application.

For information about using these examples, see “Example of decision-making rules in a sample application” on page 133.

To create Statistical Override rules, see “Defining Statistical Override rules” on page 132.

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

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

Rule types used in the Completion Check stage include:

! Get Authority

! Get Authority Regular

! Completion rule

Get Authority and Get Authority Regular rulesIn the Completion Check stage, the approval server runs Get Authority or Get Authority Regular rules to collect information. Get Authority rules are described in “Get Authority and Get Authority Self rules” on page 84.

Like Get Authority rules, Get Authority Regular rules collect data that is used by the Completion rule. The approval server runs Get Authority Regular rules only during the Completion Check stage of an approval process.



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

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

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

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

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

A process that requires a fixed number of signatures will complete successfully when the process exhausts the Approver List. For example, you can create a process that completes routing when any five approvers respond, instead of completing with one approver of a specific authority.

Examples of the routing completion checkThe rules governing approval of a business lunch might be determined by the amount of the request. If Frank requests approval of a $150 business lunch, and Jack has authority to approve requests for $150 or less, the process passes the completion check when Jack approves the request. If Jack does not have authority to approve requests of $150, the approval process does not pass the completion check when Jack approves it, and the process returns to the Get Next Approver stage. In this example, the Completion rule uses data gathered by a Get Authority rule to test for completion against a specific dollar amount.

Alternatively, the same request might require signatures from two steps up the management hierarchy. When Frank’s manager and his manager’s manager have approved the request, no more approvers are required, and the process is complete. In this case, the Completion rule uses data gathered by a Get Authority rule to test the approver relationships.

The Cost Completion and Level Completion rules in the Lunch Scheduler sample application are further examples of Completion rules. For information about creating a Completion rule, see “Defining Completion rules” on page 138. Figure 5-9 illustrates how the approval server uses the Completion, Get Authority, and Get Authority Regular rule types during the Completion Check stage.



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

Process Done stageA process is done when a request has generated a final result, such as Approved, Rejected, Error, or Cancelled. Approval Process Done rules allow a process to take action on the original request when the approval server is done handling the request. For example, when a process is done, you use an Approval Process Done rule to change the approval status on the approval request form. The only rule type used to implement the Process Done stage is the Approval Process Done rule.

The sample applications contain many examples of Approval Process Done rules, including, for example, Cost Approved, Cost Rejected, Issue Approved, and Issue Rejected. To create an Approval Process Done rule, see “Defining Approval Process Done rules” on page 139.

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

Self Check

NextApprover

ApproverResponse

Moreapprovers?

Outstandingsignatures?


StatisticalOverride?

ProcessDone

Requesterapproved

Requester not approved

No

No

No

Yes

YesYes

Approved

Get Authority

Get AuthorityRegular

Submit Request

Requester

Rejected

Completion

ApprovalCycle



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

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

Beginning with release 7.6.03, you can increase the length of these fields to the maximum limit permitted by the database (VARCHAR limit) by manually executing an approval server utility. See “The apchgschema utility” on page 95.

In release 7.5.00 or earlier, the approval server only checks the size of the Approvers field at startup, and enforces this length as the maximum limit for approver names. If the default limits are insufficient, you need to increase the field lengths manually.

Table 5-3: Approver fields checked for maximum length at startup

Field ID Field name Form name

12401 Member List AP:Role

13203 Original Approvers ! AP:Signature! AP:PreviewSignatures

13205 Next Approvers ! AP:Signature! AP:PreviewSignatures

13207 Approvers ! AP:Signature! AP:PreviewSignatures! AP:PreviewInfo

14511 GNA Approvers AP:Signature

14512 PGNA Approvers AP:Signature

Table 5-4: VARCHAR limits for special fields on supported databases

Database VARCHAR limit

IBM® DB2® 4000

IBM Informix® 255

Microsoft SQL Server 8000

Note: Even though the VARCHAR limit on SQL Server is 8000 characters, apchgschema sets the field length to 4000 characters to support Unicode.

Oracle® 4000

Sybase 255


Approver fields

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

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

! For real-time previews, increase the length of the Approvers field on AP:PreviewInfo.

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

! Windows—approvalServerInstallDir\bin\apchgschema.bat

! UNIX—approvalServerInstallDir/bin/apchgschema.sh

Administrators can run this utility to set the length of approver fields on certain forms to the maximum limit allowed by the database. Table 5-3 on page 94 lists the forms and their approver fields that are affected.

The syntax for apchgschema is as follows:

apchgschema -s serverName -u userName [-p userPassword][-portnum tcpPortNumber] -i ARSystemInstallDir[-l absoluteLogFilePath]

Table 5-5 describes the parameters that administrators need to supply when running the apchgschema utility.

Table 5-5: Parameters for the apchgschema utility

Parameter Description

-s Mandatory; name or IP address of the AR System server to log into (or localhost, if applicable).

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

-p Optional; specify the password for the aforementioned user.Omit this parameter if the user account does not have a password.

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



Here is a sample apchgschema command:

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

NOTE The apchgschema utility increases the lengths of the approver fields provided that the current lengths are not already set to the maximum VARCHAR limit, or to unrestricted or 0 (zero).

In case of the Member List field, if the maximum length supported by the database is less than 512 characters, the current field length is not modified. This ensures that the corresponding data remains intact.

-i Mandatory; path to the directory where AR System is installed.The utility further searches for the approval server directory.

-l Optional; absolute path to your custom log file.The utility writes the details of all its activities into this file.If this value is not provided, the utility records its activities in the default apchgschema.log file, at the following location:! Windows—ARSystemInstallationDir\Arserver\Db! UNIX—ARSystemInstallationDir/db

Table 5-5: Parameters for the apchgschema utility



Chapter

6
Defining an approval process
This section describes the procedures to create and modify processes in BMC Remedy Approval Server (approval server).


! Using the Process tab on AP:Administration (page 98)! Creating a process (page 98)! Working with existing processes (page 103)! Defining roles (page 106)



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

The buttons on the Process tab take the following actions:

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

! Search—Opens a blank AP:Process Definition form in Search mode. Use this option to search for a process using a field that does not appear in the processes list.

! Create—Opens the AP:Process Definition form in New mode. Use this option to create a new process.

! Delete—Deletes the selected process. You must select a process from the list to use this button.

! Refresh—Refreshes the current list of processes. Use this button to refresh the list, for example, after adding a new process.

Creating a processTo create a new process, click Create on the Process tab of the AP:Administration form. This opens the AP:Process Definition form in New mode.

For more information, see “AP:Process Definition” on page 231.

AP:Process Definition contains the following tabs:

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

! Configuration—Use this tab to specify:

! Process intervals to calculate the Action Date for a request

! Menus to generate lists of users that appear when creating a More Information request (by adding a question or comment), reassigning a request, and assigning a request to an ad hoc approver

! The mandate for rejection justification and the application form’s field on which to push an approver’s input

! Signature Escalations (Normal, Urgent, and Low)—Use these tabs to schedule notifications and automatic actions for pending requests.


Creating a process

! More Info Escalations—Use this tab to schedule notifications for requests in the More Information state.

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

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

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

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

! To create a process

1 Open the AP:Administration form.

See “Using the approval server Administration form” on page 24.

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

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

See “AP:Process Definition” on page 231.

4 Click Save.

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



Figure 6-1: Process Definition form—Basic tab

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

! To set process intervals

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

For more information, see “Creating a process” on page 98 and “AP:Process Definition” on page 231.

The selected process opens in Modify mode.

2 Click the Configuration tab.

3 Enter a number in the Process Due field, and select what this number represents from the Unit list.

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


Creating a process

NOTE The Process Due interval is required as a minimum for the action date feature.If this field is left blank, no action date is associated with the process or its corresponding requests.

4 Enter a number in the Signature Due field, and select what this number represents from the Unit list.

For example, if you want every signature to be due in two days, enter “2” in the Interval field, and select Days from the Unit list.

5 Enter a number in the Buffer Period field, and select what this number represents from the Unit list.

This value is used as a delta to be deducted from all other intervals, except Signature Due, to derive the minimum of all the required process intervals.

6 In the Enable Preview field, select Yes if you want to consider future approvers when calculating the Signature Due date. Select No if you want if you want to use the value in the Signature Due field only.

7 Click Save.

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

Creating signature escalationsUse the Signature Escalations tabs to configure settings for notifications and actions when a signature line has been waiting too long without a response. For example, you can set up a notification to be sent when a request has been outstanding for two days.

This procedure applies to any of the notification priority levels—Normal, Urgent, or Low.

! To enter signature escalations

1 Open the Process Definition form if it is not already open. See “Creating a process” on page 98.

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

The selected process opens in Modify mode.

3 Click the tab for the notification priority level on the Process Definition form: Normal, Urgent, or Low.

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



4 Select or enter the names of the business calendar and the holiday calendar you want to use for signature escalation notifications.

These names must match existing schedule names from the Business Time Workdays or Business Time Holidays forms. For information about configuring business times, see the Configuration Guide, “Using Business Time in the AR System server,” page 213.

5 To change the state of an approval request automatically if no signature action occurs after a specified interval, enter the Automatic Action parameters:

a Enter a number in the After Interval field to indicate when you want the state changed, and select what this number represents from the Unit list.

For example, if you want the state to change two days after the approval request enters a certain state, enter “2” in the After Interval field, and select Days from the Unit list.

b In the Change State field, use the drop-down list to select the state that you want to apply to the approval request.

The options are Pending, Approved, or Rejected.

If you set these parameters, approvers can see the resulting date and time after which the state of the approval request changes automatically. This reflects on AP:Show-Detail > Action Date field and Approval Central > Action Date column. For more information, see “AP:Show-Detail” on page 243 and “Approval Central” on page 255.

6 To send notifications when a signature line has been outstanding (in any state) for too long, specify the Notification: Still Outstanding parameters:

a Enter a number in the First Interval field to indicate when you want the first notification sent, and select what this number represents from the Unit list.

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

This reflects on Approval Central > Past Due requests > Action Date column. For more information, see “Approval Central” on page 255.

7 If you want to send notifications when the approval request remains in a certain state (Pending, Error, Hold, or More Information) too long, specify the Notification: Still in State parameters:

a Enter a number in the First Interval field for the desired state to indicate when you want the first notification sent, and select what this number represents from the Unit list.

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


Working with existing processes

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

! To enter More Information escalations

1 Open the Process Definition form if it is not already open. See “Creating a process” on page 98.

2 Click the More Info Escalations tab.

3 Select or enter the names of the business calendar and the holiday calendar you want to use for More Information Escalation notifications. These names must match existing schedule names from the Business Time Workdays or Business Time Holidays forms. For information about setting up business times, see the Configuration Guide, “Using Business Time in the AR System server,” page 213.

4 If you want to send notifications when a signature line has been outstanding (in any state) for too long, specify the Notifications: Still Outstanding parameters:

a Enter a number in the First Interval field to indicate when you want the first notification sent, and select what this number represents for the Unit list.

For example, if you want the first notification sent two days after the approval request enters the More Information state, enter a “2” in the First Interval field and select “Days” from the Unit list.

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

5 Click Save.

Working with existing processesThe following sections describe how to modify, delete, or rename an existing process.

Viewing and modifying a processFollow these steps to view or modify an existing process.

! To modify a process

1 Open the AP:Administration form. See “Using the approval server Administration form” on page 24.

2 Click the Process tab, and click Refresh.

3 Select the process from the list and click View.



The Process Definition form opens in Modify mode, displaying the entry for the selected process.

4 Modify the appropriate process fields as needed. See “Creating a process” on page 98 for information about field values.

5 Click Save.

Deleting processesThis section describes how to delete an existing process.

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

! To delete a process

1 Open the AP:Administration form and click the Process tab.

2 Click Refresh to populate the list of processes.

3 Select the process you want to delete.

4 Click Delete.

5 Click Yes when prompted to confirm the deletion.

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

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

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

! To rename a process or form

1 Open the AP:Administration form.

See “Using the approval server Administration form” on page 24.

2 Click Rename in the navigation pane.

The approval server Rename dialog box (AP:Admin-Rename form) appears as shown in Figure 6-2.


Working with existing processes

Figure 6-2: Renaming a process

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

4 In the field labeled “Select GUID of the process to be renamed,” click the drop- down menu.

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

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

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

6 In the Scope of Update field, select whether you want to rename the process or form for all requests, or only active requests.

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

! Only Active Requests—This option updates only the currently active detail and signature records.

7 To change the name of the process or object as well as the related requests, make sure that the Including Object Itself check box is selected.

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

8 Click Rename to complete the action.



Defining rolesThe approval server can route a request to a role instead of an individual. When you use a role, the request is routed to all members of the role. You specify whether one member of the role can approve a request or whether all members must approve it.

The Overdue Oversight role is an example of the use of roles in the Lunch Scheduler sample application. It works with the Rule-Based process to route approvals for an overdue account to the members of the Overdue Oversight role.

! To define a role

1 Open the AP:Administration form. See “Using the approval server Administration form” on page 24.

2 Click the Role tab, and click Create.

The AP:Role form appears in New mode.

Figure 6-3: Defining an approver role

3 Enter a Role Name in the Role Name field.

The name should be descriptive of a job or a responsibility, for example, “MIS Management.”

4 Select an option from the If Multiple Approvers list.

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


Defining roles

The options are:

! One Must 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.

! All Must Sign (default)—Use this value to create a separate signature line for each member of the role.

This option is overridden when the If Multiple Approver setting for the process is defined as One Must Sign. When this is the case, the role follows the “One Must Sign” process setting. See “Creating a process” on page 98.

NOTE If you include a role in the member list of another role, the If Multiple Approvers option of the “parent” role will take precedence. For example, suppose that Role A is defined with If Multiple Approvers set to “All must sign” and you include Role A in the member list of Role B. Role B is defined with If Multiple Approvers set to “One must sign.” In this example, the approval server uses the settings for Role B.

5 In the Status field, select Active or Inactive. Active is the default value.

6 In the Member List field, type the names of the role members.

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

7 Click Save.


Chapter

7
Defining approval rules
This section describes how to create and modify rules in BMC Remedy Approval Server (approval server).


! Using the Rule tab on AP:Administration (page 110)! Creating a rule (page 110)! Defining approval rules (page 114)! Working with existing rules (page 141)



Using the Rule tab on AP:AdministrationTo create and manage rules, you use the Rule tab on the AP:Administration form. See “Using the approval server Administration form” on page 24.

When you open the Rule tab, a table field appears listing all existing rules. You can sort this list on any column, including rule name, process name, rule type, order, status, and process instance ID. If you installed the sample applications, all the sample application rules appear on this list.

Below the list of rules, a diagram illustrates the stages of an approval process and contains links that filter the list for each rule type. For example, to see a list of all existing Get Next Approver rules, click the Next Approver link on the diagram.

To see only the rules for a specific process, select the process from the menu in the Show for Process field.

The buttons on the Rule tab take the following actions:

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

! Search—Opens a blank AP:Rule Definition form in Search mode. Use this option if you want to search for a rule using a field that does not appear in the rules list.

! Create—Opens the AP:Rule Definition form in New mode. Use this option to create a new rule.

! Delete—Deletes the selected rule. You must select a rule from the list to use this button.

! Refresh—Refreshes the current list of rules. Use this button to refresh the list, for example, after adding a new rule.

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

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

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


Creating a rule

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

! Basic—The fields on this tab store identification and execution information about the rule, as well as a Run If qualification statement, if any.

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

! Administrative Information—The fields on this tab contain change history and help text (if any) for the rule. Use the help text field to describe the purpose of the rule, or any other information helpful to process administrators.

Figure 7-1: Defining a new rule

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

! To complete the fields on the Basic tab that are common to all rules

1 Open the AP:Administration form, and click the Rule tab.

2 In the Rule Name field, enter a name for the rule.

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



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

The processes that appear on this menu are those you have defined in the Process tab. When you select the process name, AR System automatically populates the Process Instance ID field.

4 In the Rule Type field, select the appropriate rule type from the list. For example, if you are creating a Get Next Approver rule, select Get Next Approver.

When you select a rule type, the Rule Definition form changes to display the fields appropriate for the rule type. Fields that apply to the rule type have a white field box. Fields that do not apply are gray.

5 In the Order field, enter an execution order number. The default value is “0.”

This number determines the rule sequence when two or more of the same rule type exist for a specific process.

6 In the Status field, select either Active or Inactive. The default value is Active.

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

NOTE If you save a rule with the Status field empty, the rule is saved as Active.

7 In the Assignee Group Permissions field, the Public group appears by default. If you use this field for multi-tenancy support, create workflow to populate this field with the correct assignee group name. You do not need to change this setting when creating the rule.

The approval server supports multi-tenancy for use by application service providers. The Assignee Group Permissions field is field 112, and appears on all the approval server forms. The field 112 value from records created in the AP:Details form is used automatically in all the other approval server forms, for example, AP:Signature, AP:More Information, and so on.

8 If the rule requires a qualifying condition to control execution, enter the condition in the Qualification area of the Basic tab. This field is labeled “Rule” or “Run If,” depending on the rule type. Process Done rules use a radio button field to set the execution condition.

You can type the condition statement or you can build it by using the qualification bar and list. When the qualification is met, the rule actions execute. You can use currency, date, and time fields in Run If and Rule qualification statements.

For more information, see the Workflow Objects Guide, “Building qualifications and expressions,” page 49. For specific examples pertaining to various rule types, see the discussion of each rule type in this section.

9 Click Save.


Creating a rule

Using the Set Fields tab on the Rule Definition formThe Set Fields tab applies to all rule types except Auto Approval, Self Approval, and Completion rules. You use the Set Fields tab to define the actions for the rule. For example, for a Get Authority rule, you can define a query to retrieve a signature authority amount from the AP-Sample:Signature Authority form and set that amount into a temporary field on the AP:Signature form.

When you construct assignments using the Set Fields tab, you can also use currency, date, and time fields, currency functions such as CURRCONVERT, CURRSETDATE, CURRSETTYPE, or CURRESETVAL, and date functions such as DATEDIFF, DATENAME, DATENUM, or DATEADD.

Depending on the rule type, the Set Fields tab provides the following action options in the Set Fields Type field:

! Value—Use this action to assign a value to a particular field.

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

! SQL—Use this action to specify an SQL command to be run on either the AR System server or another database. You can assign the value from any returned column. If the command finds no entries, a NULL value is assigned. If it finds multiple entries, the value assigned depends on the If Multiple Rows setting on the Basic tab.

! Process—Use this action to specify a process to be run on the AR System server. If the command returns an empty string or an error, a NULL value is assigned.

! Other—This setting enables you to specify an action by using an AR System filter. See the Workflow Objects Guide, “About filters,” page 17.

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

Example of the Set Fields tab for a queryFigure 7-2 illustrates a Get Authority rule from the sample applications that makes a query to the AP-Sample:Signature Authority form.

In this example, the rule uses a query to the AP-Sample:Signature Authority form to retrieve the signature dollar limit for the current approver.



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

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

Defining Auto Approval rulesAn Auto Approval rule determines if the request can be automatically approved at the time it is submitted, without action from any approver, and regardless of the submitter’s signature authority. Automatic approval occurs when an approval request transaction passes any Auto Approval rule included in the process.

Creating Auto Approval rules is optional. If you do not define an Auto Approval rule, no automatic approval occurs.

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



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

! To define an Auto Approval rule

1 Follow the procedure in “Using the Basic tab on the Rule Definition form” on page 111 to complete the basic information about the rule.

! Select Auto Approval in the Rule Type field.

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

2 Enter an Audit Text message (optional).

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

3 Click Save to save your changes.

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

Figure 7-3: Example of an Auto Approval rule



Defining all Get Authority rulesThe approval server provides three types of get authority rules:

! Get Authority—Runs in both the Self Check and Completion Check stages of the approval process

! Get Authority Self—Runs only in the Self Check stage of the approval process

! Get Authority Regular—Runs only in the Completion Check stage of the approval process.

You use the same procedure to define all three types of get authority rules.

All get authority rules gather information about the current approver or environment that is used by subsequent Self Approval or Completion rules.

! To define any type of get authority rule


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

! Create a condition statement in the Run If field if necessary. The condition statement controls whether the rule actions execute. This field is optional for this rule type; if no qualification exists, the rule always runs.

2 Click the Set Fields tab.

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

The Set Field Type indicates the type of assignment to be used for the rule action. See “Using the Set Fields tab on the Rule Definition form” on page 113.

4 In the From Form field, select a form name from the menu.

This value defines the form that the rule will search for the requested data; for example, the AP-Sample:Signature Authority form.

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

! Current—The form exists on the current server.

! Alternate—The form exists on another server. In this case, type the server name where the form is located in the Server field.



6 In the Qualification area, enter a qualification statement to define the parameters for retrieving the authority data.

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

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

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

7 In the Fields Data area, enter the names of the field or fields to receive the data in the Field Name column, and a value statement or the name of each source form field in the Value column.

Use the field list button to the right of each field to select the field names. The fields in the Field Name column are located in the AP:Signature form. The fields in the “Value” column are located in the form named in the From Form field (such as AP-Sample:Signature Authority).

8 Click Save.

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

Figure 7-4: Example of a Get Authority rule



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

Defining Self Approval rulesA Self Approval rule determines whether an approval request can be approved, based on an attribute of the requester, such as signature authority. Self approval is immediate and simply tests whether the approval request meets the defined criteria.

A Self Approval rule differs from an Auto Approval rule in that Self Approval rules can use values retrieved from another form. Self Approval rules usually depend on a Get Authority Self or Get Authority rule to retrieve a value from another form. For example, a Get Authority Self rule can retrieve the signature authority value for the requester and write the value to a temporary field on the AP:Signature form. This makes the signature authority value available for use by a Self Approval rule.

When an approval request meets the criteria in a Self Approval rule, the request moves directly to the Process Done stage. The approval server sets the rule state to Approved in the Detail record, which activates an Approval Process Done rule.

! To define a Self Approval rule


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

! Build a condition statement that tests for a specific field value to determine if the rule passes. The condition can reference any value of the current approval request or any values retrieved by a Get Authority or Get Authority Self rule.

For example, test to see if a signature authority field value is $100.00 and the total approval request amount is less than or equal to $100.00.

2 Enter an Audit Text message (optional).

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

3 Click Save.



Example of a Self Approval ruleFigure 7-5 on page 119 shows an example of a Self Approval rule from the Lunch Scheduler sample application. In this example, the rule condition is a statement comparing the value in the Estimated Total field of the approval request with the value in a temporary field (Temp Decimal 1) on the AP:Signature form, and the value 200.

For this Self Approval rule to work, a Get Authority Self or a Get Authority rule must also be included in the process to retrieve the value for the temporary field. In this example, the temporary field value is a signature authority value pulled from the AP-Sample:Signature Authority form by a Get Authority rule. The Estimated Total field is located on the approval request form (AP-Sample:Lunch Scheduler).

In addition to the rule condition, this sample rule includes a customized audit trail message to be written to the audit log when the rule passes.

Figure 7-5: Example of a Self Approval rule



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

! To define a Prep Get Next Approver rule


! Select Prep Get Next Approver from the Rule Type list.

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

2 Open the Set Fields tab and perform the following steps:

a In the Set Fields Type field, select the action type from the menu. See “Using the Set Fields tab on the Rule Definition form” on page 113.

b If the action type is Query, select a form name from the From Form list. This value indicates which form to search for the data being retrieved by the query.

c In the On Server field, select Current if the form exists on the current server, or select Alternate if the form exists on another server, and enter the server name where the form is located in the Server field.

d Depending on the action type, enter the qualification statement or command line in the Qualification area.

e In the Fields Data area, enter the name of the field or fields to receive the data in the Field Name column, and a value statement or the name of each source form field in the Value column.

f Click Save.

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



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

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

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

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

A signature record is considered complete when any approver on the signature record approves, rejects, or cancels the approval request.



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

Get Next Approver rules in a Parent-Child processIn a Parent-Child process, you must create a form to define individuals or roles, and the form must include a field that identifies the “parent” record. When an approver marks a request Approved, the approval server automatically routes the approval request to the “parent” of the approver (usually the approver’s manager). See “Parent-Child process” on page 75 for more information about this process type.

For a Get Next Approver rule in a Parent-Child process, the following considerations apply:

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

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

Get Next Approver rules in a Level processIn a Level process, you must define individuals and roles with a field that identifies the organizational level of the individual or role. For example, level 1 might be project leaders and level 2 might be section managers. Levels are always numeric values, with 0 (zero) being the lowest level. See “Level process” on page 77 for more information about this process type.

When the approval server creates the first approver list when the request is submitted, it assumes that the previous level was -1. Therefore, the first level is the level with the lowest number. The approval server keeps track of the current approver level during the approval cycle.

For a Get Next Approver rule in a Level process, the following considerations apply:

! You must identify the field containing the level identifier.

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



Get Next Approver rules in a Rule-Based processIn a Rule-Based process, rules define the relationships between individuals or roles and the approval process. The approval server makes no assumptions regarding these relationships. You must design the appropriate rules to determine how to construct the first approver list and how to move from one phase of the approval process to the next.

Use the Next Approver Rule Is field on the Rule Definition form to define a set of rules that evaluate the conditions necessary to add an approver to the current approver list. See “Rule-Based process” on page 79.

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

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

! To define a Get Next Approver rule


! Select Get Next Approver from the Rule Type list.

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

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

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

! Value from First—Uses the value from the first record retrieved.

! Values from All—Uses all of the values retrieved.

! Return Error—Returns an error message if more than one record is retrieved.

! Clear—Leaves this field blank.

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

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

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



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


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

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

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

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

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


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

If used, this field defines a conditional statement that controls whether the rule runs. You can type the conditional statement or you can build it by using the qualification bar and list. See the Workflow Objects Guide, “About Run If qualifications and expressions,” page 50.


7 In the Set Fields Type field, select the appropriate action type. See “Using the Set Fields tab on the Rule Definition form” on page 113.

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

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




10 Depending on the action type, enter the qualification statement or command line in the Qualification area.

11 In the Fields Data area, enter the name of the field or fields to receive the data in the Field Name column, and a value statement or the name of each source form field in the Value column.

12 Click Save.



Example of a Get Next Approver ruleFigure 7-7 illustrates an example of a Get Next Approver rule for the Parent-Child process in the Lunch Scheduler sample application.

The Basic tab in this example does not contain a Run If statement, so the rule always runs. The If Multiple Approvers setting causes the approval server to create a single signature record for the approver list (One Must Sign). Therefore, only one approver action is required for the approval request to be complete. The Next Approver Rule Is field is set to Ending, so no other Get Next Approver rules will be processed after this one.

On the Set Fields tab, the Qualification statement causes the approval server to match the current approver ($Approver$) to the Login Name field in the AP-Sample:Signature Authority form during the query. The current approver could be the approval request submitter or an approver.

The rule retrieves the “parent” of the current approver by getting the value from the $Manager Login Name$ field on the matching record in the AP-Sample:Signature Authority form and setting the value in the Next Approver field of the approval request.

Figure 7-7: Example of a Get Next Approver rule in a Parent-Child process

These fields determine the number of signature records created.



Defining Parameterized Get Next Approver rulesThe Parameterized Get Next Approver rule enables requesters and approvers working with a Parent-Child, Level, or Rule-Based process to add an approver anywhere in the approval hierarchy at run time. This rule type works with the preview feature to make this functionality available. See “Adding previews to your approval application” on page 168.

For example, an approver using the preview feature in a Parent-Child process might see the following hierarchy of approvers:

1 Allan

2 Lin

3 Akon

4 Penni

A Parameterized Get Next Approver rule would allow approver Lin to enter an additional approver, Michel, at the same level as Penni, for example.

You use the Parameterized Get Next Approver rule in combination with the Add-PGNA-Values application command. The Add-PGNA-Values command populates the detail record with the run-time variables to be used by the rule. See “Add-PGNA-Values” on page 182.

A Parameterized Get Next Approver rule works exactly like a Get Next Approver rule, with the following exceptions:

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

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

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

! To define a Parameterized Get Next Approver rule


! Select Parameterized Get Next Approver from the Rule Type list.

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

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

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

! Value from First—Uses the value from the first record retrieved.

! Values from All—Uses all of the values retrieved.



! Return Error—Returns an error message if more than one record is retrieved.


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

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

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

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


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

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

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

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

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


5 Select Yes or No from the Guaranteed Add list.

! Yes—The parameterized rule runs even when a Completion rule would otherwise determine that the process is done, thus guaranteeing that the user will be added as an approver.

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



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








12 Click Save.

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

! Run If qualification: $Level$ = “%1”

! Guaranteed Add: Yes

! Set Fields: $Next Approver$ = “%2”

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

The following actions occur:

Step 1 A user enters an approval request in a process that includes an approval hierarchy, such as a Parent-Child or Level process.

Step 2 When working with the approval request, the first approver uses the preview feature to view the existing approvers for the request, for example, by clicking a button on the approval form. The approver decides to add Michel LeTourneau as an approver at a future level, for example, level 4.

Step 3 The approver uses functionality added to the approval request form, such as a button that opens an “Add Approvers” form, to enter the level and the approver name. When the approver saves his or her changes, a filter runs that captures these values and sends an Add-PGNA-Values application command using the values to the approval server.



For example:

Application-Command Approval Add-PGNA-Values -o “My Param Rule” -l “4/Michel LeTourneau”

Step 4 The approval server receives the command, and stores the data in the Param Data field on the AP:Detail record.

Step 5 After the approval server executes the Get Next Approver rules, it executes Parameterized Get Next Approver rules. While executing the parameterized rules, it retrieves the values from the Param Data field in the detail record. In this case, it retrieves 4/Michel LeTourneau and parses this into %1=“4” and %2=“Michel LeTourneau”

Step 6 The approval server replaces the variables in the Parameterized rule with these values:

! Run If qualification—$Level$ = 4

! Set Fields—$Next Approver$ = “Michel LeTourneau”

Step 7 If the condition matches, the Set Fields action is executed. If the condition never matches and the regular Get Next Approver rules do not return any approvers, the approval server checks for the Guaranteed Add flag. If this is set to yes, the parameterized rule executes, even though the Run If condition is not satisfied.

Parameterized Get Next Approver rules are executed when a preview is generated, so the added approver is visible when future approvers preview the request.

Defining Validate Approver rulesA Validate Approver rule enables you to verify approver names when they are manually entered on an approval request. This applies to either an Ad Hoc process type or an ad hoc override.

This rule validates the approver name at the time of entry by searching for a match to the entered name on a specified form, for example, a signature authority form such as AP-Sample:Signature Authority in the sample application.

You can define any number of Validate Approver rules. This allows you to search more than one form to validate an approver name.

WARNING Approver names in Validate Approver rules are case sensitive. Make sure approver names are entered correctly by providing a menu of names for requesters to select from. See the Form and Application Objects Guide, “Creating menus,” page 309.



! To define a Validate Approver rule


! Select Validate Approver from the Rule Type list.

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







! Alternate—The form exists on another server. Enter the server name where the form is located in the Server field.



8 Click Save.

Example of a Validate Approver ruleFigure 7-9 illustrates an example of a Validate Approver rule from the Get Agreement sample application. On the Set Fields tab, the qualification condition causes the rule to search the Login Name field of the User form to find a match for a name entered in the approver field ($Approver$) of the approval request form (AP-Sample2:Get Agreement).



Figure 7-9: Example of a Validate Approver rule

Defining Signature Accumulator rulesA Signature Accumulator rule gathers data across the set of current signature records, for use by a Statistical Override rule. You use Signature Accumulator rules when the standard signature statistics gathered by the approval server are not sufficient.

The approval server automatically populates the hidden “Total” fields in the join forms with the number of signature records in Pending, Approved, Rejected, Hold, More Information, Cancelled, Error, and Closed states. These values are often sufficient to construct a Statistical Override rule. If not, you can define Signature Accumulator rules to gather other data.

If a Signature Accumulator rule exists, it runs when a signature record is approved, rejected, or cancelled. The approval server collects a set of current signature records and applies the Signature Accumulator rules for the approval process to each record (provided the Run If qualification passes). After all rules have been applied for the current signature, the approval server moves to the next signature and applies the rules.

A Signature Accumulator rule uses the Set Fields operation to collect and store the signature data. Typically, the Set Fields operation in a Signature Accumulator rule performs an addition to accumulate information, as in the following example:

$Temp Decimal 1$ = $Temp Decimal 1$ + $Signature Dollar Limit$

The assignment of the Set Fields operation is always to the Detail record that the approval server is processing. After all rules have been applied for one signature, the approval server moves to the next signature and applies the rules.



! To define Signature Accumulator rules


! Select Signature Accumulator from the Rule Type list.

! Use the Run If qualification to include or exclude signatures. The Run If condition is qualified on each signature, for example:

$Approval Status$ = “Approved”

If the Run If condition is met, the server will perform the Set Fields operation.








6 Enter a qualification statement to define the parameters for retrieving the authority data.

For example, to retrieve the current approver’s signature authority limit, define a qualification statement that sets $Approver$ (the current approver) to equal the user name field on the signature authority form (such as Login Name on AP-Sample:Signature Authority).


8 Click Save.

Example of a Signature Accumulator ruleThe Get Agreement sample application includes an integrated set of Signature Accumulator and Statistical Override rules in an Ad Hoc process. See “Example of decision-making rules in a sample application” on page 133.

Defining Statistical Override rulesThe Statistical Override rule evaluates data gathered by a Signature Accumulator rule or by the approval server, and determines whether the process should immediately conclude with an Approved or Rejected state, or should continue using the default approval server behavior.



! To define a Statistical Override rule


! Select Statistical Override from the Rule Type list.

! In Statistical Override rules, the Run If condition specifies the condition to be evaluated. For example, to check if 50 percent or more of the signatures have been approved, you create a Run If condition as follows:

$Total Signatures$ / $Total Approved$ >= .5

To derive the statistical override value, you can use static values, arithmetic operations, keywords, the results from functions, and values from the record that the approval server is processing in the AP:Detail-Signature form.


3 In the Set Fields Type field, select the appropriate action type.

See “Using the Set Fields tab on the Rule Definition form” on page 113.






6 Enter a qualification statement, if any.

7 In the Fields Data area, type one of the following values (or its integer equivalent) into the first entry in the Value list:

! Approved

! Rejected

In a Statistical Override rule, the Field column on the Set Fields tab is automatically populated with the statistical override field name. The Set Fields function sets the specified value in the statistical override field on the Detail form. The only valid statistical override values are Approved or Rejected.

8 Click Save.

Example of decision-making rules in a sample applicationThe Get Agreement sample application uses an Ad Hoc process that contains four interrelated statistical decision-making rules. These are Issue Retrieve Signature Limit and Issue Increment Signature Limit (Signature Accumulator rules), and Issue Statistical Approval and Issue Statistical Boundary Condition (Statistical Override rules).

For more information about the Get Agreement sample application, see Chapter 4, “Using the Get Agreement sample application.”



Activating the sample rules

When the sample application is installed, these rules are set to Inactive status. To follow the procedures in this section, you must change the status to Active.

! To change the rules to active status

1 Open the Rule tab on the AP:Administration form.

2 In the Show For Process field, select the process Issue Approved.

3 Check the Status column. If any rules are set to Inactive, use the View button to open the rule.

4 In the Status field of the Basic tab, select Active.

5 Click Save, and Close.

Sample data for the statistical decision-making rules

The approvers in this example have the following signature authority:

! Jack Miller’s signature limit is $100.00.

! Larry Goldstein’s signature limit is $500.00.

! Violet Anderson’s signature limit is $2000.00.

The signature authority data that supports these sample rules is imported with the sample applications and stored in the Signature Dollar Limit field of the AP-Sample:Signature Authority form, as shown in Figure 7-10.

Figure 7-10: Dollar signature limits in the AP-Sample:Signature Authority form



Rule functionality

When one of the sample approvers responds to a request, the sample statistical decision-making rules run. Signature Accumulator rules run before Statistical Override rules. In this case, they both have a Run If condition that causes the Set Fields action to occur only when the approver’s signature is set to Approved. (If the approver’s signature is set to Rejected, these rules do not run and the default approval server behavior causes the request to be rejected.)

! The rule Issue Retrieve Signature Limit has execution order 0, so it runs first. It retrieves the Signature Dollar Limit for the current approver, and sets the value in a temporary field (Temp Decimal 1) on the Detail form.

For this rule, the Set Fields qualification used is:

'Login Name' = $Approvers$

This qualification retrieves the signature authority amount for the current approver by matching the current approver’s login name to the Login Name field on the AP-Sample:Signature Authority form.

! The rule Issue Increment Signature Limit has execution order 1, so it runs next. It increments another temporary field in the Detail form with the current cumulative signature dollar value for all approvers who have responded.

The example Statistical Override rules run after the Signature Accumulator rules are complete.

! The rule Issue Statistical Approval has execution order 0. The Run If condition causes it to run only when the Approver response is set to Approved.

! It checks the current cumulative signature authority. If the current cumulative signature authority is greater than $500, the Set Fields action sets Statistical Override to Approved.

This approves the request, regardless of whether all approvers have responded. In this way, the rule preempts the default approval server behavior and approves the request. In this case, the other Statistical Override rule does not run because the request is done.

! If the current cumulative signature value is less than $500, the Set Fields action does not occur, and the request is not yet done.

! The rule Issue Statistical Boundary Condition has execution order 1. It runs only if the first Statistical Override rule did not result in approving the request.

! If signatures are still pending, the Set Fields action does not occur, and the approval process continues.

! If a hold exists or a More Information request is pending, the Set Fields action does not occur, and the approval process continues.

! If approvers remain, and the current cumulative signature authority is not greater than $500, the Set Field action sets Statistical Override to Rejected, and the request is done.

These two Statistical Override rules work together to assure that the approval process always ends with the request set to either Approved or Rejected.



NOTE This example assumes that the request is for an amount greater than $500. The Get Agreement sample application does not include a field for the amount of the request. In an actual approval process, you would also need a field to gather the amount of the request, and a Run If condition to test the amount.

Using the sample application with statistical decision-making rules

This section describes how to create a request that will activate the example Signature Accumulator and Statistical Override rules, and how to observe the action of the rules after each approval. Use BMC Remedy User or a browser to perform these procedures.

! To create a request that activates the example rules

1 Log in to the appropriate AR System server as the sample user Frank Williams.

2 Open the AP-Sample2:Get Agreement form in New mode.

3 In the Summary field, type:

I want to purchase a new laser printer.

4 In the Details field, type:

A really nice new laser printer costs $600.

This entry is only a comment, and does not affect the behavior of the rule.

5 In the Initial Approvers field, type:

Jack Miller; Larry Goldstein; Violet Anderson

Be sure to type a semicolon between each approver’s name.

6 Click Save.

To illustrate how statistically driven approvals work, the following procedure uses the AP:Detail-Signature form to view the approval status after a response by each approver.

! To observe the approval process in the AP:Detail-Signature form

1 Using BMC Remedy User or a browser, log in to AR System as an administrator, and open the AP:Detail-Signature form in Search mode.

2 In the Approval Status field, select Pending, and click Search.

The approval request created by Frank Williams is pending for Jack Miller, Larry Goldstein, and Violet Anderson.

3 Log in as Jack Miller, open Approval Central, and approve the request from Frank Williams.



Figure 7-11: Observing rule activity in the AP:Detail-Signature form

4 Repeat steps 1 and 2.

The sample statistical decision-making rules require the cumulative signature authority to be greater than $500. Because Jack’s signature authority is weighted at $100, the approval is still pending for either Larry or Violet’s signature.

5 Log in as Larry Goldstein, open Approval Central, and approve the request from Frank Williams.

6 Repeat steps 1 and 2.

The request is no longer pending when you search the AP:Detail-Signature form. Because the cumulative signature authority of Jack Miller and Larry Goldstein is $600 ($100 + $500), the approval condition in the Issue Statistical Approval rule is met, and the request is approved, even though Violet has not responded.

Violet’s signature authority is weighted at $2000. Therefore, Violet could have approved Frank’s request without requiring either Larry or Jack’s approval.

Example of a Statistical Override rule with default dataThe approval server automatically populates the hidden “Total” fields in the join forms with the number of signature records in Pending, Approved, Rejected, Hold, More Information, Cancelled, Error, and Closed states. You can use these field values in Statistical Override rules. In this case, no Signature Accumulator rule is necessary.

For example, the following Run If condition would check if 50 percent or more of the signatures have been approved:

$Total Approved$ / $Total Signatures$ >= .5



When the Run If condition has been met, the preempted decision is specified on the Set Fields tab.

Defining Completion rulesA Completion rule determines when the approval routing process is complete. For example, a Completion rule can compare the current approver’s signature authority against the estimated total on the approval request.

Completion rules are usually teamed with the Get Authority or Get Authority Regular rules. The authority rules retrieve information about an individual’s or role’s authority from other forms and make the information available to Completion rules.

! To define a Completion rule


! Select Completion from the Rule Type list.

! Construct a rule condition. The Completion rule condition defines whether the approval process is complete (no further routing of the request is necessary). If the condition is met, the process is complete. If it is not met, the approval server returns the request to the Get Next Approver stage of the approval process.

2 Click Save.

Example of a Completion ruleFigure 7-12 illustrates an example Completion rule from the Lunch Scheduler sample application. In this example, the temporary field Temp Decimal 1 on the AP:Detail form contains the current approver’s signature limit, which was retrieved by a Get Authority rule. The rule compares the Estimated Total field on the approval request to this signature limit. If the condition passes, the approval process is considered complete.

You must define a Get Authority or a Get Authority Regular rule for the Completion rule to work correctly in this example.



Figure 7-12: Example of a Completion rule

Defining Approval Process Done rulesApproval Process Done rules define the actions taken when the approval process is done. The approval process is considered done when an approval request is approved and passes a Completion rule, or if it is rejected, cancelled, or ends with an approval error.

Approval Process Done rules are often used to change the state of the approval request. For example, you use one Approval Process Done rule to change the state of the approval request to Approved and another Approval Process Done rule to change the state of the approval request to Rejected.

When an approver marks an approval request as either Approved or Rejected, the approval server sets this status in the AP:Signature record for that approver. When the conditions are met to approve the request, as determined by the process definition or a Completion rule, the approval server sets the status in the AP:Detail record for the request. To change the status in the approval request form, you use an Approval Process Done rule. This also applies to approval requests that are cancelled or that end in an error.

! To define an Approval Process Done rule


! Select Approval Process Done from the Rule Type list.

! Select one or more rule conditions from among the radio buttons: Approved, Rejected, Cancelled, or Error.

The rule executes when the AP:Detail record is put into the selected state.


3 Select a value from the Set Field Type list. See “Using the Set Fields tab on the Rule Definition form” on page 113.



4 In the Field Data area, enter the appropriate Field Name and Value to change the status of the approval request.

5 Click Save to save the rule.

Example of an Approval Process Done ruleFigure 7-13 illustrates an example Approval Process Done rule from the Lunch Scheduler sample application. This Approval Process Done rule is activated when the AP:Detail record is marked Approved during the Completion check. In this rule, the Set Fields action sets the hidden “Approval Workspace” field on the AP-Sample:Lunch Scheduler request form to “Cost approved.” In this case, the value set is used by the chained processes in the application. A later action results in marking the request approved overall. See “Chaining approval processes” on page 147.

Figure 7-13: Example of an Approval Process Done rule

Rule trigger

Rule assignment action


Working with existing rules

Working with existing rulesThis section describes how to view, modify, and delete existing approval rules.

Viewing and modifying rulesYou can use the table of rules on the Rule tab of AP:Administration to filter rules by process, or by rule type.

! To filter the list by process type

1 Open the AP:Administration form and click the Rule tab.

2 In the Show For Process field, select the name of the process whose rules you want to view, for example, Issue Approval.

The list is refreshed with rules that belong to the selected process.

! To filter the list by rule type


2 Clear any process name from the Show For Process field.

3 In the diagram below the table of rules, click the link for the rule type you want to view, for example, Process Done.

The list is refreshed to show all existing rules of the selected type.

! To modify a rule


2 Select the rule to be modified, and click View.

The AP:Rule Definition form opens in Modify mode, showing the current values for the rule.

3 Modify the rule as needed. For specific information about fields in the rule, see the “Defining” topic for the rule type.

4 Click Save.

Deleting rulesThis section describes how to delete an existing rule.

NOTE The delete operation is permanent and cannot be undone. Check for any rule dependencies before deleting a rule. For example, Self Approval and Completion rules might depend on a Get Authority, Get Authority Regular, or Get Authority Self rule. If the Get Authority rule is deleted, the dependent rule will no longer function as designed.



! To delete a rule


2 Select the rule to be deleted from the list, and click Delete.

3 Click Yes when prompted to confirm the deletion.

The rule is deleted and no longer appears in the list of rules.


Chapter

8
Using the Lunch Scheduler sample application
The Lunch Scheduler is a sample application deployed with BMC Remedy Approval Server (approval server).

This section describes the purpose of the three processes in Lunch Scheduler, and illustrates how to chain several processes together to form one approval process.


! Overview of the Lunch Scheduler application (page 144)! Important Lunch Scheduler forms (page 145)! Sample process descriptions (page 146)! Chaining approval processes (page 147)! Sample users (page 150)



Overview of the Lunch Scheduler applicationThe Lunch Scheduler sample application gathers approvals for employees of an imaginary company to schedule lunches with customer accounts. It uses three processes, each a different type, to implement the business rules of the company. Each process uses various types of rules.

This section describes the application’s processes and how they work together. For information about the rules used in each process, see Chapter 7, “Defining approval rules.”

NOTE The Lunch Scheduler and Get Agreement sample applications are not actually packaged as AR System applications. They consist of a related set of workflow objects, including the approval request form, active links and filters, approval processes, and approval rules.

Figure 8-1: Lunch Scheduler approval request form


Important Lunch Scheduler forms

When using Lunch Scheduler, the requester specifies information about the customer, the restaurant, and the number of attendees. These choices populate fields containing details about the total costs and information about the customer’s relationship with the company.

Lunch Scheduler includes three different approval processes chained together and uses three different filters with Run Process commands to start these processes. For more information, see the Workflow Objects Guide, “Using Run Process and $PROCESS$ commands,” page 249.

The chained processes are:

! Management Cost Authorization—This is a managerial approval based on the total cost of the lunch. It is a Parent-Child process, so the request is routed to a hierarchical series of managers until a manager with sufficient cost authority approves it. The filter AP-Sample:Start Cost Approval starts this process.

! Major Account Level Approval—This process runs if the account is a major or enterprise account. It is a Level process that causes the request to be routed to the major account and enterprise account teams. The filter AP-Sample:Start Level Approval starts this process.

! Special Overdue Approval—This process implements a special review of the request if the account is currently overdue. It is a Rule-Based process. The filter AP-Sample:Start Overdue Approv starts this process.

When requests are submitted in this application, they follow the appropriate approval processes. The processes enforce the business rules of the company, and the approval data gathered provides an auditable record of the business lunch activity at the company.

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

Important Lunch Scheduler formsThis section lists the major forms associated with the Lunch Scheduler application.

! AP-Sample:Lunch Scheduler—This is the approval request form for the application.

! AP-Sample:Lunch-Detail—This is the inner join between the AP-Sample:Lunch Scheduler and AP:Detail forms. It is used for internal processing by the approval server and for Global Override operations. The join criteria is Request ID to Request.

! AP-Sample:Lunch-Detail-Signatu—This is the three-way inner join between the AP-Sample:Lunch Scheduler and AP:Detail-Signature forms. This is the detail form that is available to approvers when they choose to view a request in Approval Central. The join criteria is Request ID to Request.



! AP-Sample:Company—This is a supporting form that stores data about customer accounts. This data supports menus, workflow, and queries about the customer companies in the application.

! AP-Sample:Restaurant—This is a supporting form that stores data about restaurants. This data supports menus, workflow, and queries about the restaurants in the application.

! AP-Sample:Signature Authority—This is a supporting form that stores data about approvers. The approval server uses this data from this form to identify hierarchical relationships in the organization. This data supplies information about the account teams and is used to identify next approvers in the Parent-Child and Level processes. The application’s rules and processes use information from this form about approvers’ signature authority to determine routing and whether the process is done.

Sample process descriptionsThe Lunch Scheduler application uses three separate approval processes that run serially. Approval processes that are designed to run serially are referred to as “chained” approval process. Two of the processes run conditionally, using a condition statement to determine if the process is required for each request.

This section describes the operation of each process. To see how each process is initiated and how the processes are chained together, see “Chaining approval processes” on page 147.

Management cost authorizationThis is a Parent-Child process that runs first and acts on every request. It uses Auto Approval and Self Approval rules to determine if the requester has authority to approve his or her own request. If not, the approval process routes the request to the manager by using the AP-Sample:Signature Authority form. The approval server routes the request to subsequent managers until a manager with sufficient authority signs the request. If no one with sufficient authority can be found for an individual, or if an individual has no manager, the process terminates with an error.

The filter AP-Sample:Start Cost Approval starts the Management Cost Authorization process. This filter uses the following application command:

Application-Command Approval New-Details -t “Management Cost Authorization”

In this command, the tag -t identifies the name of the process to run. See “New-Details” on page 187.


Chaining approval processes

Major account level approvalThis is a Level process that runs if the request is for lunch with a major or enterprise account. The process uses a Completion rule to stop lunch requests for major accounts from advancing beyond the major account level. Only enterprise accounts need to go to both the major account and enterprise account levels. The Account Type field on the request form identifies the account as a major or enterprise account.

The filter AP-Sample:Start Level Approval starts the Major Account Level Approval process. The Run If criteria in the filter must be met for this filter to execute. The filter uses the application command:

Application-Command Approval New-Details -s “$SCHEMA$” -e “$Request ID$” -t “Major Account Level Approval”

In this command, -s identifies the name of the approval request form, -e identifies the request ID for the current request, and -t identifies the name of the process to run. See “New-Details” on page 187.

Special overdue approvalThis is a Rule-Based process that runs only if the company currently has an overdue account. This process includes an example of Prep Get Next Approver rules, which retrieve and set data for Get Next Approver processing. The Account Overdue check box on the AP-Sample:Company form identifies whether the account is overdue.

The filter AP-Sample:Start Overdue Approv starts the Special Overdue Approval process. The Run If criteria of the filter must be met for this filter to execute. The filter uses the application command:

Application-Command Approval New-Details -t “Special Overdue Approval”

In this command, the tag -t identifies the name of the process to run. See “New-Details” on page 187.

Chaining approval processesThe Lunch Scheduler application demonstrates the technique of chaining three different approval processes together to approve Lunch Scheduler requests. The Lunch Scheduler application uses workflow to start the initial process and to automatically run the additional processes when necessary.



Using filters and a process status fieldThe keys to implementing this workflow are to link the filters to the approval form with the appropriate “Execute On” conditions, and to use a field to store the current process status on the request form. The workflow filters that start each chained process test the process status field with a Run If condition to determine whether the chained process should run.

In the Lunch Scheduler application, the filter that starts the initial process, Management Cost Authorization, is configured to run when the AP-Sample:Lunch Scheduler form is submitted or modified. Using the Submit condition assures that this process will run first. The chained processes, Major Account Level Approval and Special Overdue Approval, use filters that are configured to run only when the AP-Sample:Lunch Scheduler form is modified.

In the Lunch Scheduler application, a character field named Approval Workspace, ID 536870920, tracks the process status. The Approval Process Done rules for each process enter a string in this field to represent the current process status. The Run If conditions of the filters that start the Major Account Level Approval and Special Overdue Approval processes test this value to determine if the chained process should run.

The three processes in the sample Lunch Scheduler execute in this order:

Step 1 The Management Cost Authorization process runs first because the filter is configured to execute upon submission of the request.

! In the Process Done stage of this process, the Approval Process Done rules populate the Approval Workspace field of the Lunch Scheduler request form. For example, if the request is approved, the Approval Process Done rule enters “Cost-Approved” in this field.

Step 2 Because the request form was modified, the filters for the two chained processes are executed.

! If the customer is a major or enterprise account, the filter’s Run If condition causes the Major Account Level Approval process to run.

! When Major Account Level Approval process is done, its Approval Process Done rules modify the Approval Workspace field to indicate the process result. For example, if the request is approved, the Approval Process Done rule enters “Level-Approved” in this field.

! If the customer is not a major or enterprise account, the Major Account Level Approval process does not run.

! If the account is not overdue, the Special Overdue Approval process does not run. If the account is overdue, this process runs only after the Approval Workspace field has been set to “Level-Approved.”


Chaining approval processes

Step 3 If the Major Account Level Approval process runs, its Approval Process Done rules again modify the request form. This causes the filters for the two chained processes to fire again. In this case:

! If the Level process completed with an approval, and the request is marked to indicate that the account is overdue, the filter’s Run If condition causes Special Overdue Approval process to run.

! If the Level process completed with any other result (such as rejection), or if the request does not indicate that the account is overdue, the Special Overdue Approval process does not run, and the overall approval process is complete.

These three steps explain how the three processes are chained together to create the overall approval process in the Lunch Scheduler application.

In addition to the filters that start the three processes, a fourth filter, AP-Sample:Test Level Approval, runs whenever the approval request is modified. This filter runs only after the Approval Workspace field is marked “Cost-Approved,” and if the Account Type is not “major” or “enterprise.” The filter performs a set fields action that sets “Level-Approved” in the Approval Workspace field. This assures that the Approval Process Done rules function the same, even though the Level process did not actually run.

Restarting an approval processOccasionally, after an approval process has been started, it becomes inappropriate to proceed. You can configure your approval process to restart in such a situation.

For example, in the Lunch Scheduler application, a request automatically restarts if anyone changes the restaurant, the company, or the number of attendees. This ensures that users cannot make a change after the request has been approved.

The sample application implements this functionality by using a set of filters that watch for a change to the Company, Number of Attendees, and Average Cost/Person fields when the form is modified. If this occurs, a filter sets the Approval Workspace field to contain a cancellation string. Another filter resets the status of the request to “Pending Approval” in this case. (If the requester cancels the request by another means, such as by modifying the Approval Status field, the request does not restart because in that case the Approval Workspace field has not been set.)



Sample usersThe approval server sample applications include records for a set of sample users that are preconfigured for testing the Lunch Scheduler application.

Licensing sample usersTo log in as the sample users, an AR System administrator must enter them in the User form, with either a fixed or floating write license. Make sure you have purchased sufficient write licenses to create the sample users as actual accounts in your AR System database.

Alternatively, you can use existing licensed users with the sample applications. To do so, you must modify the data in the AP-Sample:Signature Authority form by replacing the sample login names with login names that already exist in your AR System User form.

Sample user approval authorityThe sample application users are set up in a Parent-Child hierarchy. Each has a spending authority limit, as shown in Figure 8-2. To follow the sample application procedures in this document, configure at least the users Frank Williams, Jack Miller, Larry Goldstein, and Violet Anderson. If you use your own existing AR System users, configure at least four users, one each with the signature authority values matching these four sample users.

Figure 8-2: The hierarchy and spending authority of sample users


Chapter

9
Adding approvals to your application
This section describes how AR System administrators connect an AR System application to BMC Remedy Approval Server (approval server). This discussion assumes you have an existing application with an approval request form, and have installed the approval server.

NOTE Although you do not need to be an AR System administrator to set up and manage approval processes, only an AR System administrator must carry out most of the tasks described in this section.


! Designing an approval application (page 152)! Connecting an application to the approval server (page 152)! Adding notifications to the approval process (page 158)! Creating notifications (page 158)! Enhancing your approval forms (page 166)! Adding previews to your approval application (page 168)! Multi-process preview (page 170)! Using a custom ad hoc dialog box with the approval server (page 171)



Designing an approval applicationBefore you begin to configure an approval application in AR System, you should think through your approval needs and the business processes that you want to implement with the approval server.

When you design an approval application, consider the process and rule types that are included with the approval server. Identify which process types are most appropriate for use in your application, and which rule types will best implement the decisions and transitions in your approval process. Also, identify where you will need to add AR System workflow to implement approval functionality, such as adding an active link to a button on your approval request form, or adding filters to start the approval process or to chain approval processes together. Also, identify which stages and statuses in the approval process should trigger notifications or escalations.

Connecting an application to the approval server

To link your application to the approval server and configure the approval process, you must perform each of the following actions:

! Create an approval request form that requesters will use to enter approval requests.

! Create two join forms that join your approval request form with two different approval server supporting forms.

! Run arjoinfix (UNIX) or arjoinfix.exe (Windows) to configure the join forms for the approval server.

! Enter the approval request form in AP:Administration.

! Define the processes and rules in AP:Administration.

! Add workflow (at least one filter) to the approval request form that will start the approval process.

! Add notifications to your process.

This section describes procedures for the first three actions, as well as adding notifications. To create processes and rules, see the following chapters in this guide:

! Chapter 5, “Introduction to approval forms, processes, and rules”

! Chapter 6, “Defining an approval process”

! Chapter 7, “Defining approval rules”

For information about defining filters, see the Form and Application Objects Guide.



Creating an approval request formIn BMC Remedy Developer Studio, create a regular form and add any fields necessary for requesters to create an approval request. Set the field permissions and default values on the core fields of your approval request form as shown in Table 9-1. Setting these permissions allows approvers to change the fields. Otherwise, the fields listed in the table can be modified only by the AR System administrator.

You must be an AR System administrator or subadministrator to create this form and set permissions. See these sections in the Form and Application Objects Guide:

! “Creating AR System forms” on page 115

! “Defining access control” on page 19

Creating the join formsTo connect your application to the approval server, you create two inner join forms. In both cases, your approval request form is the primary form for the join. This section describes how to create both join forms.

! A two-way join connects your approval request form to the approval server form AP:Detail.

! A three-way join connect your approval request form to the approval server join form AP:Detail-Signature.

This section assumes that you have already created your approval request form.

Table 9-1: Approval request form—field permissions

DB ID Default label Permissions Allow any user to submit

1 Request ID Assignee (view)Public (view)

2 Submitter Assignee (view)Public (view)

Yes

3 Create Date Assignee (view)Public (view)

4 Assigned To Assignee (change)Public (view)

Yes

5 Last Modified By Assignee (view)

6 Modified Date Assignee (view)

7 Status Assignee (change)Public (view)Submitter (change)

Yes

8 Short Description Assignee (change)Public (view)Submitter (change)

Yes



NOTE Be sure to create only one three-way join form for your application.

! To create the two-way join

1 Log in to BMC Remedy Developer Studio as an AR System administrator.

2 In AR System Navigator, expand serverName > All Objects.

3 Right-click Forms, and choose New Join Form.

4 In the New Join Form wizard, follow the prompts to take the following actions:

! Primary Form—Select your approval request form as the primary form, and click Next.

! Secondary Form—Select AP:Detail as the secondary form, and click Next.

! Join Properties—Select the Inner join type, the appropriate field positioning and inheritance options, and click Next.

! Primary Form Field Selection—Select Default Administrator View, move all fields to Selected Fields, and click Next.

! Secondary Form Field Selection—Select Default Administrator View, move all fields to Selected Fields, and click Finish.

The new join form appears. This join form is used only for internal processing, so the appearance of the form is not critical.

5 On the new join form, you must manually specify a reserved ID for two fields. Use the Outline tab in BMC Remedy Developer Studio to locate these fields.

a Select the Status-Dtl field, and set the following values in the Properties tab:

b Select the Request field (not Request ID), and enter 10051 in the ID property.

6 Choose Form > Form Properties > Permissions.

7 Move the Public group to the Permissions field, change the group permission type to Hidden, and click OK.

8 Save and name the join form.

9 Click Yes or OK in response to the AR System warning messages.

! To create the three-way join form

1 Log in to BMC Remedy Developer Studio as an AR System administrator.

2 In AR System Navigator, expand serverName > All Objects.

3 Right-click Forms, and choose New Join Form.

Table 9-2: Property settings for the Status-Dtl field of the two-way join form

Category Property Value

Display Field Access Read / Write

Database ID 13191



4 In the New Join Form wizard, follow the prompts to take the following actions:

! Primary Form—Select your approval request form as the primary form, and click Next.

! Secondary Form—Select AP:Detail-Signature as the secondary form, and click Next.

! Join Properties—Select the Inner join type, the appropriate field positioning and inheritance options, and click Next.

! Primary Form Field Selection—Select Default Administrator View, move all fields to Selected Fields, and click Next.

! Secondary Form Field Selection—Select Default Administrator View, move all fields to Selected Fields, and click Finish.

The new join form appears. Your users use this form when working with the details of an approval, so the layout and appearance of this form are important.

5 Hide or remove from view any fields that users do not need to see, such as most of the fields from the AP:Detail-Signature form.

TIP Use the Outline tab in BMC Remedy Developer Studio to locate and select a field. Then choose Layout > Bring To Front to see the field if necessary. Use tabs in a panel field to display only those fields that you want users to view or modify.

6 Rename the status fields to clarify their purpose (optional):

! The Approval Status field (ID 13191) is from the AP:Detail-Signature form and represents the status of the current approval signature. Approvers can use this field to approve or reject a request from the detail view if they do not use the buttons in Approval Central.

! The Status field (ID 7) is from your application request form and represents the status of the overall request.

7 Choose Form > Form Properties > Permissions.

8 Move the Public group to the Permissions field, change the group permission type to Hidden, and click OK.

9 Save and name the join form.

10 Click Yes or OK in response to the AR System warning messages.

Running arjoinfixAfter the join forms are created, you must run arjoinfix (UNIX) or arjoinfix.exe (Windows). Run the arjoinfix utility once for each approval request form that you connect to the approval server. This utility modifies the join qualifications to make sure your application communicates properly with the approval server.

The arjoinfix utility is installed in the same directory as the approval server.



! To run arjoinfix (UNIX) or arjoinfix.exe (Windows)

1 Open a command window and enter the following command:

arjoinfix -i ARSystemServerInstallDir [-portnum portNumber]

In this command, ARSystemServerInstallDir is the directory where the AR System server and the approval server are installed. If the AR System server is configured to use a portmapper, do not use the -portnum parameter. If the AR System server does not use a portmapper, use the -portnum parameter and replace portNumber with the appropriate TCP port.

TIP In Windows, the -i parameter is optional. You can use Start > Run to navigate to and run arjoinfix.exe when the approval server is installed on a Windows server.

The arjoinfix utility prompts:

Enter the name of the form:

2 Type the name of the application’s approval request form, and press Enter. For example, for the Lunch Scheduler sample application, enter AP-Sample:Lunch Scheduler.

The arjoinfix utility prompts:

----------Menu----------1. Update Join Criteria2. Add New Fields In 3-Way Join FormDefault: Quit

Make your choice & Press <enter>:

3 Type 1 to update the join criteria, and press Enter.

NOTE You only need to use the option 2 of arjoinfix when you upgrade your AR System server and approval server to release 7.x.xx from an earlier release. See “Performing required three-way join form updates” on page 176.

Adding the approval request form to AP:AdministrationThis section describes how to link your approval request form to the approval server.

! To add the approval request form to AP:Administration

1 Log in to BMC Remedy User or a browser as a process administrator or an AR System administrator.

2 Open the AP:Administration form in Search mode.

3 Click the Form tab, and click Create.

4 In the Form Name list, select the approval request form for your application.



5 In the Lookup Keyword field, enter a keyword that describes the form.

The approval server uses the keyword to look up the form name. The keyword acts as a permanent search name for the form and enables workflow to find the form even if the form name is changed.

6 If your approval application uses a form for reporting, select the reporting form in the Approval Reporting list.

7 In the Assignee Group Permissions field, the Public group appears by default. If you use this field for multi-tenancy support, create workflow to populate this field with the correct assignee group name. You do not need to change this setting when creating the form entry.

8 Save and close the request form.

Implementing the approval processAfter you create the approval request form and the join forms, and enter the approval request form in AP:Administration, the following tasks remain to implement the approval process:

! Create the approval process or processes.

! Create the rules.

! Create at least one filter to start the approval process.

! Create the workflow for chained processes, if you are using them.

! Create notifications.

! Add security and usability features.

Creating the processes, rules, and filtersCreate the processes and rules that you have designed to carry out your approval process. You must include Process Done rules to make sure that the approval process result is reported to the approval request form when the process is done. See Chapter 5, “Introduction to approval forms, processes, and rules,” Chapter 6, “Defining an approval process,” and Chapter 7, “Defining approval rules.”

You must also create at least one filter that will start the approval process when a requester submits an entry in the approval request form. The filter conditions should cause the filter to run on submit (and possibly on modify). In the If Action tab, enter a Run Process action to run the New-Details application command. This initiates the approval process.

For some examples of filters that start an approval process, see the filters included in the sample applications, such as AP-Sample2:Start Approvals, AP-Sample:Start Cost Approval, and so on. For information about defining filters, see the Form and Application Objects Guide. For details about application commands, see Appendix B, “Application commands.”

Test your processes, rules, and filters together to verify that the approval workflow operates correctly and covers all possible outcomes of the approval process.



Creating chained processesSome applications require a series of processes that are linked, or chained, together by using workflow. To do so, you must:

! Add a field to your approval request form to contain the process status.

! Define Process Done rules to populate this field with the appropriate status value.

! Define workflow that tests the conditions for running each process and initiates Run Process actions using application commands to start each process.

The Lunch Scheduler application includes an example of three chained processes. For details about chaining approval processes with examples from the Lunch Scheduler application, see “Chaining approval processes” on page 147.

Adding notifications to the approval processYou can use the approval server to send notifications and escalations that alert requesters and approvers when action is required on an approval request. In addition to using email and BMC Remedy Alert as notification methods, notifications can be fired by workflow. This is referred to as “workflow-based notifications.”

For example, you can add notifications to alert requesters and approvers in the following situations:

! When a request is waiting for an approver response, including escalations for requests that have been pending for a specified time

! When an approver responds with an approval or rejection

! When a More Information request is pending

! When an error occurs

! When an approver puts a request on hold

! When the normal approval cycle has been overridden by an approver or the Process Administrator

Creating notificationsYou can configure approval server notifications to be delivered by email, by BMC Remedy Alert, by the user’s default notification mechanism, or by workflow. To create an approval notification, use the following procedures:

! Verify that the events for which you want the approval server to send notifications are enabled in the AP:Admin-ServerSettings form. If notifications are not enabled on this form, they are not sent regardless of other approval server settings. See “Configuring server settings” on page 27.


Creating notifications

! Configure the approval server to send approver notifications using the procedure “Defining an email or BMC Remedy Alert notification” on page 159.

! Configure the delay before escalations when no activity occurs using the procedure “Creating signature escalations” on page 101.

! Configure notifications for More Information requests using the procedure “Creating More Information escalations” on page 103.

Defining an email or BMC Remedy Alert notificationTo define notifications, you use the Notification tab on AP:Administration. This tab opens AP:Notification form. You can define who receives a notification, the notification message text, when the message is sent, and by what method. The AP:Notification form has four tabs:

! Basic—Specifies the notification name, associates the notification with a process, and sets the conditions for the notification.

! Details—Specifies the notification method, priority, recipients, and the message.

! Email—For notifications that use email as the delivery mechanism, specifies email-related information.

! Administrative Information—Contains change history and administrator help text for the notification.

Fields with bold headings on the Notification form are the required fields; others are optional.

! To define an approval notification

1 Log in to BMC Remedy User or a browser as a process administrator or an AR System administrator.

2 Open the AP:Administration form in Search mode.

3 Click the Notification tab, and click Create.

The AP:Notification form opens in New mode, with the Basic tab selected, as shown in Figure 9-1.



Figure 9-1: The AP:Notification form—Basic tab

4 In the Notification Name field, type a name for the notification.

5 In the Process Name list, select the appropriate process.

The process must already exist. See “Creating a process” on page 98.

6 In the Status field, set the notification to Active or Inactive.

This option enables or disables this notification. To enable or disable the events that trigger all notifications, use the AP:Admin-ServerSettings form. See “Configuring settings on the Notifications tab” on page 31.

7 In the Notify On field, select one of the following options from the list. This field specifies the approval cycle event that triggers the notification.

Table 9-3: Notify On Options (Sheet 1 of 3)

Option Triggering event Default notify list

New Signature A new signature line is added to the approval request.

Approver list.

Approve The approval request is approved. Approver list minus current approver.

Reject The approval request is rejected. Approver list minus current approver.

Alternate Approve

An alternate approves the approval request. Individual Approved for.

Alternate Reject An alternate rejects the approval request. Individual Approved for.



Override Approve A user with override capability approves the approval request.

Approver list.

Override Reject A user with override capability rejects the approval request.

Approver list.

Global Approve An administrator performs a global approve, terminating a process for a request.

Approver list.

Global Reject An administrator performs a global reject, terminating a process for a request.

Approver list.

Reassign An approval is reassigned to a different approver.

Approver list.

Error An error exists in the approval signature. Individual who approved or rejected.

Cancel An approval request is cancelled. Approver list.

More Info Return A request for more information is fulfilled. Individual who requested more information.

Reject by Later Level

The approval request is rejected after this signature is approved.

Approver list.

Cancel at Later Level

The approval request is cancelled after this signature is approved.

Approver list.

Reject by Another Approver

The approval request is rejected by another signature record.

Approver list.

Hold An approval request is put on hold. Approver list minus current approver.

More Info More information is requested by an approver. Approver list minus current approver. Does not include requester.

Still Active An approval request is in an approval pending state and no action has occurred.

Approver list.

Still Active (repeat)

A Still Active notification has been sent and no action has occurred.

Approver list.

Still Pending An approval request is on hold in the approval cycle and there has been no action.

Approver list.

Still Pending (repeat)

A Still Pending notification has been sent and no action has occurred.

Approver list.

Still Hold A Hold notification has been sent and no action has occurred.

Approver list.

Still Hold (repeat) A Still Hold notification has been sent and no action has occurred.

Approver list.

Still More Info More information has been requested for an approval request and there has been no action.

Approver list.





NOTE If you choose the Before Reassign option, a notification is sent to the approvers who are being replaced.

8 In the Qualification area, enter a condition statement to help control whether the notification runs, if necessary.

The Additional Conditions field enables you to add conditions to the setting in the Notify On field.

9 Click the Details tab.

Figure 9-2: The AP:Notification form—Details tab

10 In the Method list, select one of the following notification options:

! No Message—Send no notification.

! Alert—Users are notified when they run BMC Remedy Alert. For more information about BMC Remedy Alert, see BMC Remedy User Help.

Still More Info (repeat)

A Still More Info notification has been sent and no action has occurred.

Approver list.

Still Error An error in the approval cycle has occurred and there has been no action to correct the error.

Approver list.

Still Error (repeat) A Still Error notification has been sent and no action has occurred to correct the error.

Approver list.

Change After Approved

A change occurs that all past approvers should know about.

Approver list.

Before Reassign A request is reassigned to a different approver. Approver list.





! Email—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 MS-Exchange (Windows). When you use this option, you can send notifications to users not using the AR System, to an alias for a group, or to an email address representing a program.

! User Default—Users are notified by the default notification method defined in the User record. If the User record does not contain a default notification method, BMC Remedy Alert is used.

! Workflow—Triggers a filter guide that fires on the required event and sends the notification.

To use this option, you must add the appropriate workflow to your application. See “Creating workflow-based notifications” on page 165.

11 Select a Priority for the notification from 0 to 10.

This enables users to sort notifications in order of importance.

12 Select an option for the Send To field, which indicates where to send the notification.

Notifications are sent to users or roles, or the approval server can write to a form field.

! Notify List—Send to the default notify list for the selected Notify On option. See Table 9-3 on page 160.

! Other—Specify an individual, a group, a list of individuals or groups, or a field reference to a field containing individuals or groups.

13 Enter a Subject line for the notification message.

14 To include field values in the subject line, use the Subject drop-down list.

The Subject panel lists fields from the application’s three-way join form. Select the field whose value you want to include in the subject line, and click OK.

15 To attach more field information to the notification, use the Additional Fields field. Enter field names in the text box or select field names from the drop-down list.

16 To include field values in the message text, use the Message drop-down list.

17 For email or User Default notifications, click the Email tab.

The fields in the Email tab are the same as those used when you create an Email or User Default notify mechanism in a Notify filter action. For information about using email notifications and configuring BMC Remedy Email Engine, see the BMC Remedy Email Engine Guide.



Figure 9-3: The AP:Notification form—Email tab

The menus in the Fields columns on this tab contain fields from the three-way join form. You can select from the Fields and Keywords menus to use variables in all the fields on this tab.

18 In the Mailbox Name field, enter the name of an outgoing mailbox that is configured in the AR System Email Mailbox Configuration form. This field is not required if you use the default outgoing mailbox.

You can use a field or a keyword to get the mailbox name. The mailbox name must correspond to an outgoing mailbox configured in the AR System Email Mailbox Configuration form.

19 Enter the appropriate information in the From, Reply To, CC, and BCC fields.

You can use AR System user names, AR System groups, an email address, or a field or keyword variable. To use an email address, include the email domain name (for example, [email protected]) or a keyword (for example, [email protected]). If you make multiple entries in these fields, separate the entries by hard returns.

The Email Engine uses these fields as follows:

! From—Indicates the sender.

! Reply To—Specifies the reply-to address if the recipient replies to the notification message.

! CC—Specifies recipients of the notification.

! BCC—Specifies hidden recipients of the notification. The names of recipients in the BCC field do not appear to other recipients of the message.

20 In the Organization field, enter a company name, an organization, a keyword, or a field reference to an organization name.

This name appears in the Organization tag of the email header.



21 In the Header, Content, and Footer fields specify the names of the email templates to use for the header, content, and footer of the email notification.

22 (Optional) Click the Administrative Information tab (optional) and enter Help Text that describes this notification.

23 Click Save.

Creating workflow-based notificationsAR System application designers can use workflow-based notifications for approval events. Workflow-based notification provides a way for approval events to be propagated to a customized notification system.

! To enable workflow-based notifications

1 Follow the procedures to add an application to the AR System. See “Connecting an application to the approval server” on page 152.

2 Verify that the three-way join form for the application contains the following fields from the AP:Detail-Signature form:

! Notification Message (ID 12303)

! Subject (ID 12305)

! Additional Fields (ID 12340)

! Process Instance ID (ID 13021)

If the three-way join form existed before you upgraded to version 7.x.xx of the approval server, you must add these fields to it.

3 In the AP:Notification form, create a notification for your process. See “Defining an email or BMC Remedy Alert notification” on page 159.

4 In the Details tab, select Workflow in the Method list.

5 In BMC Remedy Developer Studio, create a filter with the following workflow actions:

a Create a Set Fields action that pushes message details from the AP:Notification form to the display-only fields that you added to the AP:Detail form.

For example, push the value from the Subject field on AP:Notification to the Subject display-only field on AP:Detail.

b Create a Call Guide action that selects the AP:Workflow Notifications Guide filter guide.

The AR System installation program adds this filter guide to the server. The filter guide was created in the 7.0.00 release for use with workflow-based notifications.

6 Add your filter to the AP:Workflow Notifications Guide.

When the approval event triggers the notification, the AR System fires the filter that sends the notification.



Enhancing your approval formsThis section introduces several techniques that you can use with your approval forms to provide a richer integration for your users. These techniques include:

! Adding workflow to your approval server forms, such as buttons, to automate common tasks.

! Adding a dynamic field to the three-way join form, such as the Password field.

! Adding a field menu of valid approver names.

Add workflow to your approval server formsThe three-way join forms in the sample applications each have a button labeled Manage More Information. This button opens a dialog box that allows the user to review and respond to the More Information requests associated with the current approval request. The AP-Sample:Lunch Scheduler form contains the buttons “Show Approval Summary” and “Show Signatures,” which allow approvers to see signature details about the current request.

NOTE To use similar buttons in your application, you must add them to the appropriate form, and create the workflow to implement them. One way to do this is to copy the workflow objects from the sample applications.

This section describes how to create a Manage More Information button on the three-way join form for your application. You can use a similar procedure to add the Show Approval Summary and Show Signatures buttons.

The Manage More Information button in the sample applications links to the AP:Dtl-Sig-MoreInfoDialog form, which enables you to create More Information records and lists the existing ones. However, BMC recommends that you use the appropriate fields on AP:Show-Detail to create such records. See “AP:Dtl-Sig-MoreInfoDialog” on page 268 and “AP:Show-Detail” on page 271.

To see how the Manage More Information button works in the sample applications, use BMC Remedy Developer Studio to review the button on the AP-Sample:Lunch-Detail-Signatu form. Also review the active links AP-Sample-Dtl-Sig:MoreInfo01 through AP-Sample-Dtl-Sig:MoreInfo06.

For information about adding fields to forms, including buttons, Form and Application Objects Guide, “Creating and managing fields,” page 169.

For information about creating active links, see the Workflow Objects Guide.

! To add a Manage More Information button

1 Create a button on the three-way join form for your application. The name of the button is not critical to its function.

2 Assign the field ID 13198 and grant the Public permission to the button.


Enhancing your approval forms

3 Make a copy of each active link named AP-Sample-Dtl-Sig:MoreInfo01 through AP-Sample-Dtl-Sig:MoreInfo06:

a Open the active link to be copied.

b Choose File > Save Active Link As.

c Give the new copy a name that is appropriate for your application.

d In the Form Name field, select the three-way join form and deselect the sample application forms.

e Save the changes.

Figure 9-4: Copying AP-Sample-Dtl-Sig: MoreInfo01 through MoreInfo06

Show the password field in the detail viewWhen you configure a process to require approver passwords, the Approve and Reject buttons on Approval Central automatically open a password dialog box that prompts the user to enter the correct password when acting on the request. However, if the approver clicks View on Approval Central to view the request details, by default the password field does not appear in the detail view.

The detail view displays the three-way join form for your application. To allow approvers to enter a password in this view, you must make the Password field (field ID 102) visible on the three-way join form. This field comes from the AP:Signature form and is present in the join form, but it is hidden by default.

If your application has only one approval process, or if all the processes in the application require a password, simply position the Password field on the three-way join form, and make the field visible by deselecting the Hidden characteristic.

If your application contains more than one process but not all processes require a password, you can cause the Password field to appear on the three-way join form only when necessary. The Lunch Scheduler sample application contains an example of this functionality, which you can copy to your application.

In the Lunch Scheduler three-way join form (AP-Sample:Lunch-Detail-Signatu), two active links run when the form is displayed. The first active link checks whether the current process requires a password, and sets the result in a temporary field. The second active link tests the value of the temporary field and makes the password field visible on the three-way join form.

Save active link with a new name.

Select your three-way join form.



The following procedure shows how to make the password field visible on the three-way join form for your application when the process requires it.

! To display the Password field dynamically

1 Use BMC Remedy Developer Studio to position the Password field (ID 102) in an obvious location on your three-way join form.

2 Copy and save the following two active links with new names appropriate to your application (use File > Save Active Link As):

! AP-Sample:ShowPwdIfRequired1

! AP-Sample:ShowPwdIfRequired2

3 In the Form Name field for each active link, select the three-way join form and deselect the sample application form.

4 Save the changes.

Add a field menu of valid namesTo prevent typographical errors when users enter approver names in an Ad Hoc process or an ad hoc override, you can provide a field menu that contains valid approver names. Examples of fields for which a menu of valid names can help prevent errors are as follows:

! AP:Alternate form, Alternate field

! AP:More Information form, To field

! AP:Detail-Signature form, Reassign To field

See the Form and Application Objects Guide, “Creating menus,” page 309.

Adding previews to your approval applicationThe approval server preview feature allows approvers to view a list of all the approvers for a request, on all levels of an approval hierarchy. To cause the approval server to generate a list of approvers for a process, you configure a value in the Generate Approvers field of the Process Definition form. The approval server gathers this data at the appropriate stage of the approval process and stores it in the AP:PreviewInfo form.

To allow users to view this list and to add approvers at run time, you create a form that retrieves the list from the AP:PreviewInfo form, and gathers data interactively from the user for the Add-PGNA-Values command. The preview feature is designed to work with a Parameterized Get Next Approver Rule.


Adding previews to your approval application

To retrieve the list of approvers for a request the AP:PreviewInfo form requires the process name, request ID, and the type of preview as input. You can provide these values in the ShowForProcess, Request/Ticket Number, and Retrieval Type fields.

You can specify one of the following retrieval types:

! Full—Shows completed, pending, and future approval signatures.

! Remaining—Shows pending and future approval signatures.

! Completed—Shows completed and future approval signatures.

As shown in Figure 9-5, the preview list includes the status of the signatures.

Figure 9-5: The AP:PreviewInfo form

! To allow users to preview and add approvers

1 Create a form that will display the preview list and gather the information from the user to add another approver.

2 Create a table field on the form that queries the AP:PreviewInfo form.

For example, Figure 9-6 illustrates a form that retrieves the approver list for a request in the Lunch Scheduler sample application, and prompts users to enter the level and name of an added approver.

For information about creating forms and retrieving data from another form, see the Form and Application Objects Guide.



Figure 9-6: Example form with preview table and input fields

3 Create filter workflow that executes the Add-PGNA-Values command, for example:

Application-Command Approval Add-PGNA-Values -t “$Signature ID add$” -o $Rule Name$ -l “$Short Description$”

This command stores the added approver values, such as level and approver name, for use by a Parameterized Get Next Approver rule.

Multi-process previewThe multi-process preview appears as a flowchart or a table that lists all the approvers whose signatures are required for the approval processes to be completed. Multiple processes appear in the sequence in which they are supplied to the Generate-Multi-Process-Preview application command. For more information, see “Generate-Multi-Process-Preview” on page 186.

Application developers can integrate this feature using this application command to pass required input values to the approval server, which are then stored in the AP:Preview Data form.

After the required data is available with the approval server, application developers can generate the preview in two ways:

! Navigate to Approval Central, search for and select a request, and click View Details to see the flowchart or tabular view on the Approver tab of AP:Show-Detail.

! For the flowchart view, invoke a predefined view from any form.For the tabular view, create your own table, based on the AP:PreviewInfo form, by passing the relevant qualification.


Using a custom ad hoc dialog box with the approval server

Using a custom ad hoc dialog box with the approval server

By default, the approval server provides the AP:AdhocDialog form to work with ad hoc approvers for a request. For more information, see “AP:Show-Detail” on page 271.

To specify a different form from which to retrieve the details of an ad hoc approver, use the Adhoc Form field on AP:Process Definition. You will also need to create an alternative to the AP:AdhocDialog form.

NOTE All information about ad hoc approvers is stored in the AP:AdhocDetails form, irrespective of which Adhoc Form is specified on AP:Process Definition.

To add a new ad hoc approver, customized applications must push the values of the following fields to AP:AdhocDetails from their customized ad hoc dialog box:

To delete an ad hoc entry, customized applications must first retrieve the request ID of the record from AP:AdhocDetails by passing the Name, Sequence, and Detail ID fields. The request ID is used to fire the standard AR System server application command Application-Delete-Entry to delete the ad hoc approver. For example, the command to delete the entry on the current form with the entry ID found in the core field 1 (Request ID) is:

Application-Delete-Entry “$SCHEMA$” $1$

Table 9-4: Custom ad hoc dialog box fields mapped to the AP:AdhocDialog form

Field name Field ID Description

Name 10009 Set to the ad hoc approver’s name or a role name. If set to a role name, the specified role is expanded to include all the approvers associated with that role.

Sequence 10001 Set to a valid sequence ID. A valid value is the current or the future sequence of the process. A sequence number that has been passed is not allowed.

If Multiple 10010 If set to All, each approver has a separate signature line created against their name. If set to One, only one signature line is created for all the approvers.

Independent 10011 If set to Yes, the approval server does not wait for this signature line to be signed before proceeding to the next level of the process or to the next process in the chain. If set to No, the approval server waits for the ad hoc signature to be marked as approved before proceeding to the next level of the process or the next process in the chain.

Signature Id 10006 Set to the signature ID for which the ad hoc approver is being added.

Locked 10012 Set to Yes to indicate that this record is ready to be used for the corresponding request.


Appendix

A
Upgrading the approval server
BMC Remedy Approval Server (approval server) 7.6.03 is available for the Windows, Linux®, and UNIX operating systems. For information about installing and uninstalling the approval server for both platforms, see the Installation Guide.


! The arapupgd utility (page 174)! Running one-time escalations to configure new data (page 175)! Performing required three-way join form updates (page 176)! Using the approval server on the Web (page 178)! Mapping application request form fields to AP:Detail fields (page 178)



The arapupgd utilityBeginning with release 7.1.00, BMC Remedy Approval Server provides an ‘approval upgrade utility’ (arapupgd.exe for Windows or arapupgd for UNIX) that populates data for newer enhancements. This utility runs automatically as part of the installation. However, if you apply an approval server patch by using the file replacement method, you need to run this utility manually.

Table A-1 lists the fields whose values the arapupgd utility populates when upgrading from an earlier release.

The syntax of the approval upgrade utility is as follows:

arapupgd -s serverName -portnum portNumber -i ARSystemInstallDir-u adminUserName -p adminUserPassword -l logFileDestinationPath-o true -h true -f true

Table A-1: Fields populated by the arapupgd utility

Release Field Form

7.1.00 or later ! Process Instance ID! Requestor

! AP:Alternate! AP:Detail-Signature! AP:Notification! AP:Process Administrator! AP:Process Definition! AP:Rule Definition

7.5.00 or later Full Name (ID 14201) AP:Signature

7.6.xx or later Recent History Time (ID 14105) AP:Signature

Table A-2: The approval server upgrade utility parameters (Sheet 1 of 2)

Parameter Value

s The name of the AR System server.

portnum If the AR System server is configured to run on a port, the appropriate port number.

i The location of the AR System installer.For example, “C:\Program Files\BMC Software\ARSystem”

u The admin user’s login ID.

p The admin user’s password.

l By default, the AR System suite installer places the upgrade.log file in ARSystemServerInstallDir/Logs.If you run this utility manually, you can use this parameter to specify the location for upgrade.log.

Note: You cannot change the name of this log file.


Running one-time escalations to configure new data

If the execution of arapupgd fails during installation or upgrade, you should run the utility manually. Then, you should restart the approval server or wait for the cache to be refreshed for the changes to be visible. Even if the utility fails, no data is lost.

Running one-time escalations to configure new data

When you upgrade from version 6.3.00 to 7.0.00 or later of the approval server, use the following escalations:

! AP:Common-Set-Process-GUID—Sets the value of the Process Instance ID field to the Process Name for the existing data.

! AP:Common-Set-AssigneeGroup—Sets the value of the Assignee Group Permission field to Public for the existing data.

NOTE You must run these escalations only once after upgrading. After the Process Instance ID and Assignee Group Permission fields are set with the appropriate values, you should disable these escalations.

o Indicates the offline mode; use as follows:! If you do not want the activities of this utility to be logged, set this value

to true.! If you want the activities of this utility to be logged, set this value to false. This might hamper the performance of the AR System server.

f Valid only when upgrading to version 7.5.00 or later; use as follows:! To populate full name values on AP:Signature, set this value to true.! Otherwise, set it to false, or do not provide this parameter at all.

h Valid only when upgrading to version 7.5.00 or later; use as follows:! To populate recent history time values on AP:Signature, set this value

to true.! Otherwise, set it to false, or do not provide this parameter at all.

Table A-2: The approval server upgrade utility parameters (Sheet 2 of 2)

Parameter Value



Performing required three-way join form updates

Two of the new features introduced with version 7.0.00 of the approval server require new fields in the three-way join form. If you are using version 7.0.00 or later with older approval server applications, you must add the following character fields to the three-way join form for your application:

! Additional Fields (field ID 12340), Notification Message (field ID 12303), Subject (field ID 12305), and Process Instance Id (field ID 13021), for the Workflow-based notifications feature.

! Assignee Group Permissions (field ID 112), for the multi-tenancy feature.

The approval server uses Process Instance IDs instead of Process Names. Therefore, notifications are based on the Process Instance IDs.

NOTE When you configure a notification for a process, a notification filter is created, based on the Process Instance ID. If the Process Instance ID is changed by any means, it is not automatically reflected in the notification filter. You must update the notification filter manually with the new Process Instance ID.

The three-way join form is the join between the application request form and the AP:Detail-Signature form. For example, in the Get Agreement sample application, the application request form is AP-Sample2:Get Agreement, and the three-way join form is AP-Sample2:Issue Detail Signat.

You can add the new fields to your application in one of the following ways:

! By editing the form in BMC Remedy Developer Studio

! Beginning with release 7.1.00, by using the arjoinfix utility

This section describes these options.

! To add the fields using BMC Remedy Developer Studio

1 Open the three-way join form in BMC Remedy Developer Studio.

2 Right-click on the form, and choose Add Fields from AP:Detail-Signature from the menu that appears.

3 Select the new required fields, and click OK.

4 Position the fields on the form, and hide them.

5 Save the three-way join form.


Performing required three-way join form updates

! To add the fields using the arjoinfix utility

1 UNIX only—Navigate to ARSystemServerInstallDir and export the directory as a shared library path, using one of the following commands.

! On the Sun™ Solaris™ and Linux operating systems, use:

#export LD_LIBRARY_PATH=/usr/ar/ARSystemServerInstallDir/bin

! On the HP-UX operating system, use:

#export SHLIB_PATH=/usr/ar/ARSystemServerInstallDir/bin

! On the IBM AIX® operating system, use:

#export LIBPATH=/usr/ar/ARSystemServerInstallDir/bin

NOTE You need to set the library paths on UNIX for all approval server utilities.

2 Run the arjoinfix utility available for your platform.

! On Windows, navigate to ARSystemServerInstallDir/approval/bin, and run arjoinfix.exe.

! On UNIX navigate to ARSystemServerInstallDir/approval/bin, and run the command:

./arjoinfix -i ARSystemServerInstallDir

After starting, the utility prompts:

Enter the name of the form:

3 Enter the appropriate approval request form name, and press Enter.

The following table provides examples of applications and their application request forms.

The utility prompts:

----------Menu----------1. Update Join Criteria2. Add New Fields In 3-Way Join FormDefault: QuitMake your choice and Press <enter>:

4 Enter 2 to add the new fields, and press Enter.

The utility adds the five new fields to the three-way join form that is associated with the application request form you entered.

Table A-3: Example applications and their application request forms

Application Application request form

Get Agreement sample application AP-Sample2:Get Agreement

Lunch Scheduler sample application AP-Sample:Lunch Scheduler

BMC Remedy Change Management CHG:Change

BMC Remedy Asset Management AST:PurchaseRequisition



NOTE If you created the three-way join form after installing version 7.0.00 or later of the approval server, you do not have to run arjoinfix to add these fields. These fields exist in the AP:Signature form, and automatically become part of the three-way join form when you create the join. See “Creating the join forms” on page 153.

For more information about the arjoinfix utility, see “Running arjoinfix” on page 155.

Using the approval server on the WebBeginning with release 7.0.00, you no longer need to use the special Approval Web application components (APW:Approval Central and related objects) that are automatically installed with the approval server. Instead, for using the approval server on the Web, you must:

! Install BMC Remedy Mid Tier

! Configure the AR System Object List for use with your browser.

For more information about configuring the object list for a browser, see the BMC Remedy Mid Tier Guide, “Enabling the AR System Object List,” page 88.

For information about accessing Approval Central in a browser, see “Opening Approval Central” on page 37.

Mapping application request form fields to AP:Detail fields

The upgrade program sets the values of two fields (field IDs 14506 and 14507) on AP:Detail for active detail records, and maps them to the appropriate fields from the application request form through the Advanced tab on AP:Form. The Process Administrator is responsible for mapping the fields 14508, 14509, 14510, 14511, 14512, 14513, and 14514 to the appropriate fields on the application request forms.

For more information about these fields, see “AP:Form” on page 220.


Appendix

C
Worksheets
The worksheets in this section are intended to assist you in designing the various components of BMC Remedy Approval Server (approval server). Reproduce the worksheets as needed.


! Process worksheets (page 196)! Rule worksheets (page 200)



Process worksheetsThe following process worksheets help you set up your process and escalations:

! “Defining a process”

! “More Information escalations”

! “Signature escalations” on page 197

You can print one or more of these worksheets at a time on separate pages, and use them as checklists when setting up your processes and escalations.

Defining a processUse this worksheet to help you design a process.

More Information escalationsUse this worksheet to help you set the More Information escalations parameters on the Process form.

Process NameFormTypeRequest Owner FieldFirst Approver FieldApproval Success ! No more approvals ! Completion ruleIf Multiple Approvers

! One Must Sign ! All Must Sign ! Allow Only One Approver

Allow Ad Hoc Next Approver?

! Anyone ! Approver ! No one

For Self Assignment ! Use Get Next Approver Rules

! Assign to Owner If

Approver

! Always Assign to Owner

Validate Approvers? ! Yes ! NoRequire Password? ! Yes ! No

Business Calendar

Holiday Calendar

Notification: Still Outstanding

First Interval Unit

Repeat Interval Unit


Process worksheets

Signature escalationsUse the following worksheets to help you set the Notification parameters on the Process form.

Normal priority notifications

Use Schedules

Business Calendar

Holiday Calendar

Automatic Action

After Interval Unit

Change State o Pending o Approved o Rejected


First Interval Unit


Notification: Still in State—Pending

First Interval Unit


Notification: Still in State—Error

First Interval Unit


Notification: Still in State—Hold

First Interval Unit


Notification: Still in State—More Information

First Interval Unit




Urgent priority notifications

Use Schedules

Business Calendar

Holiday Calendar

Automatic Action

After Interval Unit



First Interval Unit



First Interval Unit



First Interval Unit



First Interval Unit



First Interval Unit



Process worksheets

Low priority notifications

Use Schedules

Business Calendar

Holiday Calendar

Automatic Action

After Interval Unit



First Interval Unit



First Interval Unit



First Interval Unit



First Interval Unit



First Interval Unit




Rule worksheetsUse the following worksheets to help set up your rules:

! “Auto Approval rules”

! “Get Authority rules” on page 200

! “Get Authority Self rules” on page 201

! “Self Approval rules” on page 201

! “Validate Approver rules” on page 201

! “Prep Get Next Approver rules” on page 202

! “Get Next Approver rules” on page 202

! “Get Authority Regular rules” on page 203

! “Parameterized Get Next Approver rules” on page 203

! “Signature Accumulator rules” on page 204

! “Statistical Override rules” on page 204

! “Completion rules” on page 204

! “Approval Process Done rules” on page 205

Auto Approval rules

Get Authority rules

Rule Name

Purpose

For Process

Rule

Audit Text

Rule Name

Purpose

For Process

Run If Qualification

Set Fields Type o Value o Query o SQL o Process o Other

From Form

On Server Server

Qualification

Set Field Value


Rule worksheets

Get Authority Self rules

Self Approval rules

Validate Approver rules

Rule Name

Purpose

For Process



From Form

On Server Server

Qualification

Set Field Value

Rule Name

Purpose

For Process

Rule

Audit Text

Rule Name

Purpose

For Process



From Form

On Server Server

Qualification



Prep Get Next Approver rules

Get Next Approver rules

Rule Name

Purpose

Rule Type

Run If Statement


From Form

On Server Server

Qualification

Set Field Value

Rule Name

Purpose

Rule Type

If Multiple Results

o Value from First o Values from Allo Return Error o clear

If Multiple Approvers

o One Must Sign o All Must Sign o clear

Next Approver Rule Is

o Additive o Ending o Exclusive o clear

Run If Statement


From Form

On Server Server

Qualification

Set Field Value


Rule worksheets

Get Authority Regular rules

Parameterized Get Next Approver rules

Rule Name

Purpose

For Process



From Form

On Server Server

Qualification

Set Field Value

Rule Name

Purpose

Rule Type

If Multiple Results

o Value from First o Values from Allo Return Error o clear

If Multiple Approvers

o One Must Sign o All Must Sign o clear

Next Approver Rule Is

o Additive o Ending o Exclusive o clear

Guaranteed Add o No o Yes

Run If Statement


From Form

On Server Server

Qualification

Set Field Value



Signature Accumulator rules

Statistical Override rules

Completion rules

Rule Name

Purpose

For Process



From Form

On Server Server

Set Field Value

Rule Name

Purpose

For Process



From Form

On Server Server

Set Field Value

Rule Name

Purpose

For Process

Rule


Rule worksheets

Approval Process Done rulesRule Name

Purpose

For Process

Rule State o Approved o Rejected o Cancelled o Error


From Form

On Server Server

Set Field Value


Appendix

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


! Using Application-Command processes (page 180)! Approval server commands (page 182)



Using Application-Command processesThe Application-Command process allows the specification of commands to be executed by an application. Whenever an Application-Command process is run, a request is created in the Application Pending form that contains details about the command. The Application Dispatcher retrieves commands from this form and passes them to the approval server for processing. If the Application Dispatcher is not in use, the approval server retrieves commands directly from the Application Pending form.

Application-Command commands use the Run Process action. As with all Run Process actions, you should use quotes around a parameter when its value contains a space, to make sure that it is evaluated correctly.

Application-Command processes exist on the AR System server. If you are performing an operation from an active link, you must use the syntax that indicates that the process should be run as a remote process on the server.

For more information about how to use Run Process actions, keywords, and syntax, see the Workflow Objects Guide and the Integration Guide.

Application command syntax and conventionsThe basic command format is:

Application-Command category command [-s formName][-e requestID] [-t tag] [-1 field1] [-2 field2] [-3 field3][-o otherString<255chars] [-l otherStringUnlimited]

This document uses the following conventions to describe application commands:

! Parameters enclosed in square brackets are optional.

! Parameters not enclosed in brackets are required.

! Braces indicate that you must specify only one of the enclosed values.

Application command parametersTable B-1 describes the parameters and their expected values in detail. The category and command parameters are positional. The other parameters are optional, and can appear in any order after the two positional parameters. If you supply any parameter that is not defined for the command, it is ignored.

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


category A character string that identifies which application the command is for; maximum length: 30 characters. For the approval server, this value is always Approval.

command A character string that indicates a specific operation to be performed within the category; maximum length: 30 characters. Commands for the approval server are defined in this section.


Using Application-Command processes

NOTE If the operation is performed from a filter or escalation, the -s and -e parameters default to the current form name (as the application form name) and the current request ID (as the application request ID) . Therefore, if the default values are sufficient, you can omit these parameters.If the operation is performed from an active link, the AR System server cannot determine what the current environment is, and these values must be supplied.

Example of an application commandThe following command would start the approval process named MyProcess against the current request:

Application-Command Approval New-Details -s “$SCHEMA$” -e “$Request-ID” -t “MyProcess”

TIP The descriptions of the -s and -e parameters (Table B-1 and the adjacent note) are applicable to all approval server commands in which they are mentioned, and therefore, not repeated in the “Approval server commands” section on page 182.

-s formName is the name of a form to which the command is related.

-e requestID is the ID of the request to which the command is related. If the request is in a join form, the request ID string consists of the ID of each request separated by a vertical bar, such as: 000000000012344|000000000084934If no request ID is specified, this value defaults to the current entry ID.

-t tag is a description that is specific to the category and command. It might be a further identifier for the operation. For example, for many approval commands, the tag is the name of the approval process.

-1 field1, field2, or field3 is the ID of a field or an integer code associated with the category or command.

-o otherString<255chars is a string that provides any further information; maximum length: 255 characters. For example, you can provide a list of approvers who are expected to act on this request.

-l otherStringUnlimited is a string that provides any further information. For example, you can provide a list of approvers who are expected to act on this request.

Note: The approval server does not impose a restriction on this string, but its maximum length might be limited by the AR System database.

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




Approval server commandsThis section enlists all commands defined for the approval server. Most of the commands are used automatically by the approval server and its workflow.

Use these commands as the command parameter for Application-Command processes. You must precede each command with Application-Command Approval.

Add-PGNA-ValuesAdd-PGNA-Values [-t detailID] [-o ruleName] [-l valueList]

This command provides the variable values for the Parameterized Get Next Approver rule type.

In the following example, the variables enclosed in quotes are provided to the approval server for use when the next Parameterized Get Next Approver rule runs:

Add-PGNA-Values -t “00000000000012” -o “Sample Param GNA Rule” -l “4/Frank Williams”

WARNING Do not use a slash (/) character within a valueList parameter, because it is a separator. For example, if you use the following command, then Williams is ignored, and the result might not be as expected.Add-PGNA-Values -t “00000000000012” -o “Sample Param GNA Rule”-l "4/Frank /Williams"

Table B-2: Add-PGNA-Values command parameters


-t detailID is the request ID of the AP:Detail record.

-o ruleName is the name of the Get Next Approver rule that needs these values.

-l valueList is list of values separated by forward slashes (/).


Approval server commands

Add-SigAdd-Sig [-s formName] [-e requestID] [-t processName]-o {approverList} [-1 {0|1}] [-2 {0|1|2|999}] [-l assigneeGroupID]

This command links to an existing approval details record, and creates one if none exists. It then adds one or more signature lines for each value of the -o parameter.

NOTE If this command is executed for a request that is in the Process Done phase, it restarts the approval process for that request.

Table B-3: Add-Sig command parameters


-t processName is the name of an existing approval process.! If supplied, the specified approval process is activated.! If not supplied, the system searches for a process against the specified form.! If only one process is specified, that process is used.! If several processes are specified, an error is reported, and no approval

process starts.! If the same process is attached to more than one approval request form, the

approval server cannot determine which form to use, and an error is returned.

-o approverList is the list approvers for whom to add signatures. If omitted, this command performs no action. Multiple approvers are separated by semicolons.

-1 Indicates whether the new signature line is identified as “independent” or “not independent”.! 1—Signature line is not independent! 0 or any other value—Signature line is independent

-2 The –2 option indicates the action to take on multiple approvers. 0 (the default) means “one of,” 1 means “all of,” 2 means “only one,” and 999 means to pull the value from the process definition.Indicates the action to take on multiple approvers.! 0—Default; creates a signature line for all approvers, and the first approver

to act on the request determines the response. The request is withdrawn from the other approvers.

! 1—Creates a signature line for all approvers, and all approvers must act on the request.

! 2—Creates a signature line for all approvers, and only one of those must act on the request. Multiple responses generate an error, and the approval process stops.

! 999—Uses the value specified for If multiple approvers in the process definition.

-l This parameter was added to allow you to pass a value for Assignee Group Permissions (field ID 112), for use with the multi-tenancy feature.For more information about multi-tenancy, see the BMC Remedy IT Service Management Suite 7.6.00 Guide to Multi-Tenancy.



Det-ApprovedDet-Approved [-s formName] [-e requestID] [-t processName]

This command marks the AP:Detail record “Approved.” Any outstanding signature lines or More Information records are marked “Closed.” The Process Done phase notifies the associated request of the approval. This command corresponds to an approval by global override.

Det-CancelledDet-Cancelled [-s formName] [-e requestID] [-t processName]

This command stops an approval process that is in progress, and marks the AP:Detail record “Cancelled.” Any outstanding signature lines or More Information records are marked “Cancelled.” The Process Done phase notifies the associated request of the cancellation.

Table B-4: Det-Approved command parameters


-t processName is the name of a process associated with the request.! If supplied, only the associated detail record is updated.! If not supplied, all detail records from all processes associated with the

request are updated.! If the same process is attached to more than one form, all the detail records

associated with this process, regardless of the application, are marked “Approved.”

Table B-5: Det-Cancelled command parameters




associated with this process, regardless of the application, are marked “Cancelled.”



Det-ErrorDet-Error [-s formName] [-e requestID] [-t processName]

This command marks the approval detail item “Error.” Any outstanding signature lines or More Information records are marked “Closed.” The Process Done phase notifies the associated request of the error. This command is intended only to be used internally by the approval server.

Det-RejectedDet-Rejected [-s formName] [-e requestID] [-t processName]

This command marks the approval detail item “Rejected.” Any outstanding signature lines or More Information records are marked “Closed.” The Process Done phase notifies the associated request of the rejection. This command corresponds to a rejection by global override.

Table B-6: Det-Error command parameters




associated with this process, regardless of the application, are marked “Error.”

Table B-7: Det-Rejected command parameters




associated with this process, regardless of the application, are marked “Rejected.”



Generate-Multi-Process-PreviewGenerate-Multi-Process-Preview [-s formName] [-e requestID]-l phase:processList; [-o {0|1}]

Creates a multi-process preview request for the associated application request. Optionally, you might choose to create a single process preview request using the appropriate parameter. For more information, see “Multi-process preview” on page 170.

Generate-PreviewGenerate-Preview [-o “Generate-Preview”] -e “requestID”-s “formName” [-t “processName”]

Creates a preview request for a single process based on the future signature lines found in the AP:PreviewInfo form for the associated application request.

For example:

Generate-Preview -o “Generate-Preview” -e “$RequestID$”-s “AS ADDSIG:Lunch Scheduler”-t “AS ADDSIG:Management Cost Authorization”

Table B-8: Generate-Multi-Process-Preview command parameters


-l The names of processes to include. If omitted, this command performs no action. Multiple process names are separated by semicolons.

Optionally, you can include extra information as a prefix to a process name separated by a colon (:). It could be anything related to the process that you want to highlight. For example, in the case of BMC Remedy Change Management applications, you can include “phase” information.

-o Indicates whether a single process (0) or multi-process (1) preview should be generated. If omitted, its value defaults to 1.

Table B-9: Generate-Preview command parameters


-o If specified, the value of this parameter must be “Generate-Preview.”

-e requestID identifies the request being processed.

-s formName must be the application form name.

-t processName is the name of a process associated with the request.



MoreInfo-ReturnMoreInfo-Return [-s formName] [-e requestID]

This command takes data from the specified More Information request and copies the response back to the associated signature request. The More Information request must be marked “Completed.”

New-DetailsNew-Details [-s formName] [-e requestID] [-t processName] [-1 priority] [-2 processDueDate] [-l assigneeGroupID]

This command starts an approval server process for the specified request.

This command creates an approval details record. It then searches for Auto Approval and Self Approval rules; if either exists and passes, the command marks the record “Approved” and continues with the Process Done phase to update the associated request. If no Auto Approval or Self Approval rules pass, the first set of approvers is found and signature lines are created for them as defined by the rules of the process.

If this command is fired after Add-Sig, and a detail record already exists for the application request, an error occurs and the process terminates. To fix this issue, pull the NotAddSig field (field ID 14523) from AP:Detail onto the two-way join between your application form and AP:Detail, and save the join form.

Table B-10: MoreInfo-Return command parameters


-s If supplied, formName it must be the More Information form.

-e If supplied, requestID must be the ID of the More Information record.

Table B-11: New-Details command parameters


-t processName is the name of a process associated with the request.! If supplied, the specified approval process is activated.! If not supplied, the system searches for a process against the specified form.! If several processes are specified, an error is reported, and no approval

process starts.! If the same process is attached to more than one application form, the

approval server cannot determine which form to use, and returns an error.

-1 If supplied, it sets the priority to Urgent (1), Normal (2), or Low (3). Any other priority is ignored, and the default—Normal (2)—is applied.

-2 If supplied, this integer value is translated into the Process Due Date and further used to calculate the action date for the signature; the Process Due interval defined on AP:Process Definition is ignored in this case.

-l If supplied, this value is passed to field 112 (Assignee Group Permissions), which is used to support the multi-tenancy feature.



Rename-FormRename-Form -t oldFormName -o newFormName [-1 activeOnly][-2 doRename]

This command changes the name of a form. All references in the definition forms are updated.

Rename-ProcessRename-Process -t oldProcessName -o newProcessName [-1 activeOnly] [-2 doRename]

This command changes the name of a process. All references in the related definition forms are updated. The name of a process can be as long as 80 bytes. This equates to 80 characters in English and most European languages, but only 40 characters in double-byte languages.

Table B-12: Rename-Form command parameters


-t oldFormName is the name of the form that you want to rename.

-o newFormName is the new name that you want to assign to the form.

-1 This parameter controls which AP:Detail records are updated. If set to 1, only active entries are updated. Providing any other activeOnly value causes all entries to be updated.

Note: Requests in the Error state also qualify as active.

-2 This parameter controls the renaming of the form. If set to 1, the form itself is renamed. If you provide any other doRename value, the approval server assumes that the form has already been renamed using BMC Remedy Developer Studio, and you are simply updating the cross-references.

Table B-13: Rename-Process command parameters


-t oldProcessName is the name of the process that you want to rename.

-o newProcessName is the new name that you want to assign to the process.

-1 This parameter controls which AP:Detail records are updated. If set to 1, only active entries are updated. Providing any other activeOnly value causes all entries to be updated.

Note: Requests in the Error state also qualify as active.

-2 This parameter controls the renaming of the process. If set to 1, the process itself is renamed. If you provide any other doRename value, the approval server assumes that the form has already been renamed using the AP:Process Definition form, and you are simply updating the cross-references.



Sig-ApprovedSig-Approved [-s formName] -e requestID [-t processName]

This command performs approval processing on a signature line that has been marked “Approved.” The rule process continues to the next approvers.

Sig-CancelledSig-Cancelled [-s formName] -e requestID [-t processName][-1 {0|1}]

This command performs cancellation processing on a signature line that has been marked “Cancelled.” The request can be in any active state (Pending, Hold, More Information, Error) for this operation to be performed. The signature line is cancelled and the process performs the appropriate actions, depending on whether other signature lines are active.

Table B-14: Sig-Approved command parameters


-s If supplied, formName must match the value in the AP:Signature form.

-e requestID is the ID of the signature entry.

-t If supplied, processName must match the process name specified in the AP:Signature form.

Table B-15: Sig-Cancelled command parameters




-t If supplied, processName must match the process name specified in the AP:Signature form.

-1 Indicates whether the related signature lines should be cancelled.! The default value is 0, in which case the related signature lines are not

cancelled.! If you supply 1, the related signature lines are also cancelled.For example, signatures are created for two people, Allen and Bob, in an ad hoc manner, with the All Must Sign option. When Sig-Cancelled is used to cancel Allen’s signature with the -1 parameter values:! 0—only Allen’s signature is marked “Cancelled,” and not the related

signature lines.! 1—both Allen’s and Bob’s signatures are marked as “Cancelled.”



Sig-NotifySig-Notify [-s formName] -e requestID [-1 numNotifications]

This command causes a notification message to be sent, indicating that the specified AP:Signature record has exceeded its defined time limit without being resolved. The notification message is sent to the corresponding form-AP:Detail-Signature join.

Sig-Notify-ChangeSig-Notify-Change -s formName -e requestID [-t processName]

This command causes a notification message to be sent, indicating that the specified entry has been changed. The approval server sends a notification about the change in the signature status to all users who have previously acted upon a signature line for a specific entry.

The notification message is sent to the corresponding AP:Detail-Signature join form after the detail record is rejected or approved by using the Det-Rejected or Det-Approved command.

The -s and -e parameters are required to identify the entry that has been changed.

Table B-16: Sig-Notify command parameters



-e requestID is the ID of an AP:Signature form request.

-1 If supplied, numNotifications indicates the notification value.! 0—Default value; indicates that this is the initial notification.! Any other value—indicates that this is a repeat notification.This parameter triggers the delivery of the notification or repeat notification message.

Table B-17: Sig-Notify-Change command parameters


-t processName is the name of a process associated with the request.! If specified, the notification is sent to the appropriate process.! If not specified, the notification is sent to all the processes associated with

the entry.



Sig-Notify-StateSig-Notify-State -s formName -e requestID [-t processName][-1 numNotifications] -2 {0|3|4|6|otherState} [-3 {0|1}]

This command causes a notification message to be sent, indicating that the specified AP:Signature record has exceeded its defined time limit for a given state without being resolved. The notification message is sent to the corresponding AP:Detail-Signature join form.

This command gets fired when a user acts on a request through Approval Central. An administrator can fire this command manually, and the notification is sent if the signature state has been changed to Hold, More Information, or Error.

A notification can only be sent if the administrator has created AP:Notification records for the following states: Hold, More Information, Error, Still Pending, Still Pending (Repeat), Still Hold, Still Hold (Repeat), Still More Information, Still More Information (Repeat), Still Error, and Still Error (Repeat).

Table B-18: Sig-Notify-State command parameters


-s formName must be the AP:Signature form.

-e requestID identifies the request being processed.

-t If supplied, processName must match the process name specified in the AP:Signature form.! If supplied, the approval server uses it to execute this application

command.! If not supplied, the approval server determines the process name using the formName and requestID.

-1 If supplied, numNotifications indicates the notification value.! 0—Default value; indicates that this is the initial notification.! Any other value—indicates that this is a repeat notification.This parameter triggers the delivery of the notification or repeat notification message.

-2 This parameter specifies the numeric value of the state the notification is for.! It can be set to 0 (Pending), 3 (Hold), 4 (More Information), or 6 (Error).! otherState will default to 0 (Pending).

-3 Provides more information about the notification.! 0 (Default)—indicates that the notification is for an escalation.! 1—indicates that the notification is simply a direct notification.! Any other value assumes the default.



Sig-ReassignSig-Reassign [-s formName] -e requestID [-t processName]{-o shortApproverList | -l longApproverList}

This command reassigns the signature line to another approver list by using either the -o (for an approver list less than 255 characters) or -l option. The signature line must be in an active state (Pending, Hold, More Information, Error) for this operation to be performed.

Sig-RejectedSig-Rejected [-s formName] -e requestID [-t processName]

This command is issued when a signature line is changed to Rejected. It marks the associated detail line as “Rejected.”

Table B-19: Sig-Reassign command parameters


-s If supplied, formName must be the AP:Signature form.


-t If supplied, processName must match the process specified by the detail record that is associated with the signature line.

-o shortApproverList contains the names of the approvers to whom the request is to be reassigned, when the length of the approver names does not exceed 255 characters.

-l longApproverList contains the names of the approvers to whom the request is to be reassigned, when the length of the approver names is longer than 255 characters.The approval server does not impose an upper limit on the length of this string. However, it is limited by the BLOB column of the database in use.

Table B-20: Sig-Rejected command parameters


-s If supplied, formName must be the AP:Signature form.


-t If supplied, processName must match the process specified by the detail record that is associated with the specified signature line.



Update-ConfigUpdate-Config -t settingLabel [-o settingValue]

This command updates administrative configuration settings for the application.

Table B-21: Update-Config command parameters


-t settingLabel identifies the specific setting being updated. This label is defined in arstruct.h and is placed in the ar.cfg (or ar.conf) file.

-o You can use this parameter as follows:! Omit it to reset settingLabel to its default value.! Mention a settingValue in the format appropriate for the ar.cfg (or ar.conf) file to change the value of the settingLabel.

Examples of configuration settings:! For the approval notification setting, not specifying this parameter resets all

options to their default values. Otherwise, only the option that is defined in the settingValue parameter is reset.

! For the debug mode setting, other debug options can be defined, and if they are, this setting takes effect. However, if only 0 or 65536 (the setting for approval debugging) is set, then only that flag is changed, and other settings remain as they are in the file.

Note: The approval server immediately applies the changes in settings that are not start-up-only.


Appendix

D
Approval forms
This section describes all the BMC Remedy Approval Server (approval server) forms and their fields.

AR System administrators, process administrators, and approvers can access the most important approval server functionality in the Approval Central and AP:Administration forms. For example, the best practice is to use AP:Administration to access the AP:Server Settings and AP:Admin-Rename forms, rather than opening the helper forms independently.


! Administration forms (page 208)! User forms (page 255)



Administration formsAdministration forms are used either by approval administrators to manage process settings, or by the approval server to manage data.

AP:AdhocDetailsThis form stores the information entered through AP:AdhocDialog. See “AP:AdhocDialog” on page 263.

Figure D-1: AP:AdhocDetails form

Table D-1: Fields on AP:AdhocDetails (Sheet 1 of 2)

Field Description

Name The name of the ad hoc approver.

Sequence The sequence at which the ad hoc approver is added.

If Multiple ! One—Indicates that at least one ad hoc approver must approve the corresponding request.

! All—Indicates that at all the ad hoc approver must approve the corresponding request.

Independent ! Yes—Indicates to the approval server that the request can proceed to the next level of its process without waiting for the signature of the current ad hoc approver.

! No—Indicates to the approval server that the current ad hoc approver’s signature is required before the request can proceed to the next level of its process.

Signature ID The signature ID for which the ad hoc approver is added.

Detail ID The detail ID corresponding to the signature for which the ad hoc approver is added.

Process Name The name of the process to which the corresponding request belongs.


Administration forms

For more information, see “Using a custom ad hoc dialog box with the approval server” on page 171.

AP:AdministrationProcess administrators use this form to create and modify the records that make up approval processes. See “Using the approval server Administration form” on page 24.

Figure D-2: AP:Administration form—Process tab

Form Name The application request form through which the request was created.

Current Sequence

The current sequence of the corresponding process.

Application Request ID

The request ID of the application through which the corresponding request was created.

Locked ! Yes—Indicates to the approval server that the ad hoc approver entry is ready to be associated with the corresponding approval request.

! No—Indicates to the approval server that the ad hoc approver entry is not to be associated with the corresponding approval request.

Note: When AP:AdhocDialog is used to add ad hoc approvers, this field is set to Yes by default.

SigToBeDeleted When an ad hoc approver entry is deleted, this field is used to indicate the corresponding signature entry that should be deleted.

Table D-1: Fields on AP:AdhocDetails (Sheet 2 of 2)

Field Description



AP:Admin-DeleteVerifyThis dialog box appears when a process administrator tries to delete an entry in AP:Administration. The entry could be a process, rule, notification, role, form, another process administrator, or an alternate approver.

You can delete only one entry at a time. When you select a process and click Delete, the dialog indicates that if you proceed, the associated rules, notifications, and administrators are also deleted.

! Click Yes to delete the entry. The corresponding record in AP:Question-Comment-Info is deleted.

! Click No to close the dialog box without deleting the entry.

AP:Admin-RenameThis dialog box appears when a process administrator selects Rename in the navigation pane of the Administration form.

Table D-2: Fields on AP:Administration

Field Description

Show for process Use the menu to limit the display list to items associated with the selected process. This field is not active for the Role and Form categories.

Process, rule, notification, role, form, administrator, alternate

Click a tab to display a list of items of that type. This also selects which category of items is used when you click the buttons on this form.

View Click this button to open the item selected.

Search Click this button to open a search form for items of the category determined by the current tab.

Create Click this button to create a new item of the category determined by the current tab.

Delete Click this button to delete the currently selected item.

Refresh Click this button to reload the displayed list.

Server settings Click this link in the navigation pane to open the Server Settings form. See “AP:Admin-ServerSettings” on page 212.

Rename Click this link in the navigation pane to open the AP:Admin-Rename form. See “AP:Admin-Rename” on page 210.



Figure D-3: AP:Admin-Rename dialog box

Table D-3: Fields on AP:Admin-Rename

Field Description

Select the type of object to be renamed

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

Select the form to be renamed /Select GUID of the process to be renamed

Select the process name from the menu. When AR System supplies the GUID, select the supplied GUID.

Enter new process name /Enter new form name

Type the replacement name for the process or form.The name of a process can be as long as 80 bytes. This equates to 80 characters in English and most European languages, but only 40 characters in double-byte languages.

Scope of update Select an option from the menu to determine which of the associated detail records are renamed. ! All Requests renames all detail records for current and past

approval requests associated with the form or process.! Only Active Requests renames detail records only for

currently open approval requests associated with the form or process.

Including object itself ! Select this check box to include the form or process you are renaming.

! Deselect this check box if you have already renamed the form or process manually, and are now renaming the associated requests.

Rename Complete the rename operation.

Cancel Close the form with no action performed.



NOTE If you renamed a process manually instead of using the Rename dialog box, the Rename command will not change names of attached rules. You must restore the process name manually and rename the entire process. Or you can rename all the attached rules using the Rename dialog box.

AP:Admin-ServerSettingsProcess administrators use this form to change server settings for the approval server. To open this form, select Server Settings in the navigation pane of the AP:Administrator form.

Basic tab

Figure D-4: AP:Admin-ServerSettings form—Basic tab

Table D-4: Fields on AP:Admin-ServerSettings—Basic tab (Sheet 1 of 2)

Field Description

Logging Settings

Approval Debug Mode Select this check box to enable approval server logging.

Log File Name Type the directory path and file name for the log file.



Click Save to apply your changes, Reset to reload the form with the previously stored values, and Close to close the dialog box without saving any changes.

Other Settings

Definition Check Interval

Type a number of seconds to define how often the approval server checks the definitions for changes.A larger number increases AR System performance by checking less often. A smaller number of seconds is useful while creating and testing a process. A zero (0) in this field causes the system to check for definition changes with each operation.

Note: When testing custom applications, after creating a process, you should wait until the Definition Check Interval period before creating requests. Otherwise, the processing of requests fails, and the following error is written to the logs:

No join between applicationFormName and the approval detail form.

Private AR Server RPC Socket

Type the RPC socket number of a private queue to use when accessing the AR System server.Leave this field empty if you do not use a private queue.

Plugin Loopback RPC Socket

Type the RPC socket number of a private queue used for loopback calls.Leave this field empty if your server does not use a dedicated queue for loopback calls.

Due-Soon Interval Type the duration after which approval requests that are due for action should be highlighted on Approval Central. Use the adjacent drop-down list to specify whether this duration should be measured in hours or days.This interval is subtracted from the value of the Automatic Action interval defined at the process level. Accordingly, requests are displayed as due-soon approvals on Approval Central. For more information, see “Approval Central” on page 255.For example, if the process states that the automatic action interval for a request is five days, and the Due-Soon Interval is four days, the request appears as a due-soon approval for the relevant approver one day before the automatic action is due.

Recent History Interval Type the duration within which a user can see in the recent history an approval request that was submitted or acted upon. Select the unit of measurement (Hours or Days) using the adjacent drop-down list.This affects My Recent Approvals on Approval Central. See “Approval Central” on page 255.

Table D-4: Fields on AP:Admin-ServerSettings—Basic tab (Sheet 2 of 2)

Field Description



Notifications tabThe Notifications tab allows you to enable or disable notifications for various approval server events.

Figure D-5: AP:Admin-ServerSettings form—Notifications tab

You can specify whether or not to send notifications on the following events:

When any of these event types occur during an approval process, the approval server acts according to the following choices:

! Disabled—No notifications are sent.

! Enabled—Notifications are sent to all the approvers.

! Enabled Including Alternate (default setting)—Notifications are sent to all the approvers and active alternates.

To use notifications, you must define the specific notifications for each process in the AP:Administration form.

! New Signature ! Error! Approve ! Cancel! Reject ! More Info Return! Alternate Approve ! Reject by /at Later Level! Alternate Reject ! Cancel at Later Level! Override Approve ! Reject by Another Approver! Override Reject ! Hold! Global Approve ! More Info! Global Reject ! Change After Approval / Approved! Reassign ! Before Reassign



Escalations tab

Figure D-6: AP:Admin-ServerSettings form—Escalations tab

AP:DetailThe AP:Detail form holds all data about an approval request. You can use this form to determine the status of a request, and to see a history of activity on the request for any approval process. In addition to the fields described in this section, the AP:Detail form also includes hidden Currency, Date, and Time fields to store temporary results during workflow. For example, Currency Field 1 and Currency Field 2 are temporary fields of the currency type.

Table D-5: Fields on AP:Admin-ServerSettings—Escalations tab

Field Description

Still ActiveStill Active (repeat)Still PendingStill Pending (repeat)Still HoldStill Hold (repeat)Still More InfoStill More Info (repeat)Still ErrorStill Error (repeat)

! Disabled means the approval server disables escalations for this event type during an approval process.

! Enabled means the approval server enables escalations for the approver list when this event type occurs during an approval process.

! Enabled Including Alternate (default setting) means the approval server enables escalations to the approver list as well all active alternates when this event type occurs during an approval process.

These settings enable escalations for each event type. To use escalations, you must define the specific escalations for each process in the AP:Process Definition form.



Figure D-7: AP:Detail form

Table D-6: Fields on AP:Detail

Field Description

Application The AR System populates this field the with name of the approval request form for the request.

Request The AR System populates this field with the AR System ID for the request.

Process The AR System populates this field with the name of the approval process for the current Detail entry.

Comments The AR System stores comments entered by approvers in this field.

Priority Displays the priority of this request, as set by the process.

Submitter The AR System populates this field with the AR System user name of the person who submitted the request.

Status The AR System populates this field with the status of the request.

Approval Audit Trail This field contains an audit trail of date, time, and approver for actions taken on this request. This information is part of the permanent record for this request.

Global Approve Approves the request, overriding the regular approval process. You must have process administrator override authority to perform this action. However, the best practice is to use Approval Central for overrides.

Global Reject Rejects the request, overriding the regular approval process. You must have process administrator override authority to perform this action. However, the best practice is to use Approval Central for overrides.

Assignee Group Permissions

The AR System populates this field with the Assignee Group for the request. This field supports the multi-tenancy feature.

Process Instance ID The AR System populates this field with the GUID for the process associated with the request.



AP:Detail-SignatureAP:Detail-Signature is a join form that combines data from the AP:Detail and AP:Signature forms. You link this form to your application’s approval request form to create a three-way join when you add approvals to your application. The approval server uses this form for internal processing. The visible fields of this form appear by default in the three-way join form, which displays request details.

To open the three-way join form, click Source ID on Approval Central, and click the Show Signatures button (if implemented) on the application form that appears.

In addition to the fields described in this section, the AP:Detail-Signature form also includes many hidden fields used to store temporary results during workflow.

Figure D-8: AP:Detail-Signature form



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

Field Description

Approval Status The AR System populates this field with the current status for the signature record.! Pending—The approval server is waiting for a response to a

request for this signature line.! Approved—The request is approved for this signature line.! Rejected—The request is rejected for this signature line.! Hold—The request is on hold for this signature line, so no

approval server actions occur.! More Information—The approver associated with this

signature line is waiting for a response to a More Information Request.

! Cancelled—This request was withdrawn from the approval process.

! Error—The approval server detected an error state while processing this request.

! Closed—This request is ended and operations can no longer be performed on it.

Password This field is optional. The administrator should configure it to appear on the three-way join form when the process has Require Passwords set to Yes.Type your password for verification. The approval server verifies the contents of this field before a Save operation occurs.

Approval Priority Displays the priority of this request as defined in the approval process.

Comments Enter any comments you want to store with the approval request.

Next Approvers When the process allows ad hoc approvers to be added, type the AR System user names of the next approvers.

If Multiple Approvers If you enter ad hoc approvers, select how the approval process operates when more than one approver appears in the Next Approver field.! One Must Sign—A single signature entry is created for all

approvers in the Next Approver field. Only one of those approvers needs to take action on the request.

! All Must Sign—Separate signature entries are created for all approvers in the Next Approver field. All approvers must act on the request for it to move to the next stage.

Reassign To Type the AR System user name of an approver to whom you want to reassign this request.

Approvers The AR System populates this field with the AR System user name of the approver for this signature line.

Approval Audit Trail This field contains an audit trail of date, time, and approver for actions taken on this request. This information is part of the permanent record for this request.



AP:DynamicLabelsThis form enables you to set locale-specific labels for four fields on the AP:Show-Detail form. The default labels for these fields are GL Account, Cost Center, Total Cost, and Phase, respectively.

Figure D-9: AP:DynamicLabels form

Assignee Group Permission


For Application The AR System populates this field with the name of the approval request form for the request.

For Request The AR System populates this field with the AR System ID for the request.

For Process The AR System populates this field with the name of the approval process of this request.

Submitter The AR System populates this field with the name of the person who submitted the request.

Approver Signature This field records the AR System user name of the approver who has responded for this signature line. The name appears only after an authorized person modifies the Approval Status field.

Alternate Signature This field records the AR System user name of the alternate approver who modifies the Approval Status field, if any.

More Information This field contains More Information requests sent by the approver for this request and signature line, and the responses to those requests. The field is not populated until the requestee responds to the More Information request.

Show Details Opens the approval request form for this request.

More information Opens AP:Dtl-Sig-MoreInfoDialog and searches for More Information requests associated with this approval request.

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

Field Description



Provide labels for the fields 14508, 14509, 14510, and 14511, and click Save.

For information about where these labels appear, see “AP:Form.”

AP:FormThis form is linked to the Form tab of AP:Administration. Process administrators use this form to attach approval request forms to the approval server.

Basic tab

Figure D-10: AP:Form—Basic tab

Table D-8: Fields on AP:DynamicLabels

Field Description

Application Select an application name.

Process Select the process for which you want to customize the field labels.

Locale Select a locale from the menu.

Table D-9: Fields on AP:Form—Basic tab (Sheet 1 of 2)

Field Description

Form Name Select a form on the current server, or type a form name.

Lookup Keyword Type a keyword to be used by the approval server when searching for this form. The keyword acts as a permanent search term, even if the name of the form changes.



Advanced tabThe Advanced tab enables Process administrators to define field mappings for a request form at the application level. These mappings are not mandatory.

Figure D-11: AP:Form—Advanced tab

Used By This field contains the name of the AR System application that uses this form. AR System populates this field with “Approval.”

Approval Reporting Enter the name of a form used for reporting, if any.



Search In Search mode, click this button to perform your search.

Save In Submit mode, click this button to save your changes.

Close Click this button to close the window.

Table D-9: Fields on AP:Form—Basic tab (Sheet 2 of 2)

Field Description



The fields on this form are reserved field IDs in the approval server. You can map them to other fields on the application forms by using the corresponding menus. The values from the mapped fields are displayed on Approval Central and AP:Show-Detail. Table D-10 describes where these values appear.

Table D-10: Fields on AP:Form—Advanced tab

Field Description

Application Request ID

Map to an application ID—it could be the request ID or any other ID field in the application.For example, BMC Remedy Change Management uses its own IDs to represent a particular record, apart from the one generated by AR System. You can map this field to that field from the BMC Remedy Change Management application.The value from the mapped field is displayed on Approval Central as the Source ID link. If the value is NULL, the request ID is displayed by default. See “Approval Request Summary” on page 263.

Requestor Map to a user field on the application form.The value from the mapped field is displayed in the Requester column on Approval Central.

Field 1 {14506} The value from the mapped field is displayed in the Summary column on Approval Central.

Field 2 {14507} Currently, the approval server does not use Field 2. This field was used in releases earlier than 7.5.00 to display certain fields on the approval console.

Field 3 {14508}Field 4 {14509}Field 5 {14510}Field 6 {14511}

The values from the mapped fields are displayed in the top panel on AP:Show-Detail.For example, for a request of the Lunch Scheduler sample application, these values appear against the following labels:! P-C GL Account! P-C Cost Center! P-C Total Cost! P-C PhaseIn your application, you can specify the labels that should appear for these fields on AP:Show-Detail.

Field 7 {14512} The value from the mapped field is displayed in a tool tip that appears when you hover on a request on Approval Central.

Field 8 {14513} The value from the mapped field is displayed in the Notes field for a request on Approval Central.

Field 9 {14514} The value from the mapped field is displayed in the Attachment table on AP:Show-Detail.

Note: You can map this field only to other Attachment fields.

Define Labels Click to define labels for the fields 14508, 14509, 14510, and 14511, for various applications, processes, and locales.The AP:DynamicLabels form appears. See “AP:DynamicLabels” on page 219.



NOTE Changing the field mappings on this form only affects new requests. The older requests retain their original field values.

For information about the Administrative Information tab, see “Administrative Information tab” on page 267.

AP:NotificationProcess administrators use this form to create and modify notifications sent by approval processes. This form opens from when you click View or Create from the Notification tab of AP:Administration.

Basic tab

Figure D-12: AP:Notification form—Basic tab

Table D-11: Fields on AP:Notification—Basic tab (Sheet 1 of 2)

Field Description

Notification name Type a name for the notification.

Process name Select the process name from the list. The process must already exist.



Details tab

Figure D-13: AP:Notification form—Details tab

Status Use the drop-down list to select the status of the notification.! Active—Notification will be sent when the process triggers it.! Inactive—The notification will not be sent.

Process Instance ID The AR System populates this field with the GUID of the selected process.

Notify On Use the drop-down list to select the type of event that will trigger this notification.

Note: If you choose Error, the notification is sent only if the status of the request is set to Error in AP:Signature and AP:Detail.



Qualification If necessary, enter additional conditions to control when the notification is sent. The approval server uses condition in this field in addition to the Notify On event.

Search In Search mode, searches the AP:Notification form.

Save In New mode, saves the notification.

Close Close the window without saving changes.

Table D-11: Fields on AP:Notification—Basic tab (Sheet 2 of 2)

Field Description



Email tab

Figure D-14: AP:Notification form—Email tab

Table D-12: Fields on AP:Notification—Details tab

Field Description

Method Use the drop-down list to define the method of notification.! None—No notification is sent.! Alert—Notification is sent using BMC Remedy Alert.! Email—Notification is sent by electronic mail. ! User Default—Notification is sent using the default notification

method defined in the User form for each of the recipients. If the User record does not contain a default notification method, BMC Remedy Alert is used.

If you select Email or User Default, the Email tab is activated.

Send to ! Notify List—The approval server sends notifications to the default recipients for the event type. See Table 9-3 on page 160.

! Other—If you select Other, enter the notification recipients in the field to the right. To use a field reference (for example, $fieldName$ click the field menu icon.

Subject Type a subject line for the notification message. You can select AR System variables from the list.

Additional Fields To attach additional field information to the notification, use the drop-down list to select the field names.

Message Type the message text for the notification. Use the drop-down list to include AR System variables in the message text.

Priority Select a priority from 0 to 10 to allow users to sort their notifications by order of importance. Entries created with an earlier version of the approval server will default to a Priority of 1.




AP:Preview DataThis form stores intermediate data that is used to generate the multi-process preview for an approval request. See “Multi-process preview” on page 170.

The field values correspond to the input parameter values of the Generate-Multi-Process-Preview command. See “Generate-Multi-Process-Preview” on page 186.

Table D-13: Fields on AP:Notification—Email tab

Field Description

Fields Each field on this form includes the Fields button. Use this menu to select fields from the approval server forms when completing each field, if appropriate.

Keywords Each field on this form includes the Keywords button. Use this menu to select AR System key words when completing each field, if appropriate.

Mailbox name Enter the name of the AR System outgoing mailbox that you want to handle the notifications.

From Enter a name for the sender of the notification, or select variables from the Fields and Keywords menus.

Reply To Enter a name for the Reply-To field of the notification email, or select variables from the Fields and Keywords menus.

CC Enter the recipients of the notification email, or select variables from the Fields and Keywords menus.

BCC Enter the recipients of the notification email who should receive blind copies, or select variables from the Fields and Keywords menus. Recipients entered in this field do not appear in the recipient list for other users.

Organization Enter a company name, an organization, a keyword, or a field reference to a name for the notification email.

Header Enter the names of templates to use for the header of the email notification. You can enter the name of the template directly, or enter a field reference or keyword to retrieve a template name.

Content Enter the names of templates to use for the content of the email notification. You can enter the name of the template directly, or enter a field reference or keyword to retrieve a template name.

Footer Enter the names of templates to use for the footer of the email notification. You can enter the name of the template directly, or enter a field reference or keyword to retrieve a template name.



Figure D-15: AP:Preview Data form

AP:PreviewInfoThe approval server uses this form to store preview data when the process is configured to generate previews. Process administrators can use this form to preview all the approvers assigned to work on an approval request.

You must enter data into all the visible fields to search the AP:PreviewInfo form.

See “Configuring previews” on page 33.

Figure D-16: AP:PreviewInfo form

Table D-14: Fields on AP:Preview Data

Field Description

Application Request ID The application request ID.

Application Form Name The application form name.

Preview Type Indicates whether a single process or multi-process preview is generated.

Process List The list of processes separated by semicolons (;).

Phase-Process List The semicolon-separated list of processes, each prefixed with some related information and separated by a colon (:).Some processes might not have any related information prefixed.



AP:PreviewSignaturesThe AP:PreviewSignatures form keeps track of signature entries generated as part of the approval preview feature (except for real-time preview).

NOTE The approval server uses this form internally, and users must not use this form to create records manually.

When a signature or detail record-related application command is submitted, the approval server creates signatures of future approvers in the chain if the Generate Preview field for the process definition is set to one of the following:

! On Request Only

! On Start of Process

! On Generation or Change to a Signature

These signature records are stored in the AP:PreviewSignatures database schema.

Real-time preview does not use the AP:PreviewSignatures form, because it stores signature records in-memory.

Table D-15: Fields on AP:PreviewInfo

Field Description

Request/Ticket Number

The request ID that you want previewed.

Single/Multi Process Select the appropriate value to indicate whether you want to generate a single process or multi-process preview.

Retrieval Type Users have an option of specifying a value as a qualification for the query being made.! Full—Returns list of all completed signatures (from the

AP:Signature form), and all previews from the preview form.! Remaining—Returns list of only the preview signatures

(those that are not yet opened and entered in the AP:Signature form).

! Complete—Returns list of only the signatures that have already been completed, that is, those that already exist on the AP:Signatures form, and are still open (Pending/More Info). You can query the AP:Signature form for this information as well, but form displays such data in a better format.

Show for Process Select the process related to the request.

Application Form Name

Select the application form name related to the request.



Figure D-17: AP:PreviewSignatures form

AP:Process AdministratorThe AP:Process Administrator form opens when you click View or Create on the Administrator tab in AP:Administration. AR System administrators and process administrators use this form to create, delete, and modify the abilities of other process administrators. See “Configuring process administrator capabilities” on page 26.

Figure D-18: AP:Process Administrator form—Process Administrator tab

Table D-16: Fields on AP:PreviewSignatures

Field Description

Approval ID The application request ID.

Approval Status The current status of the request.

Approvers List of approver names separated by semicolons.



Table D-17: Fields on AP:Process Administrator—Process Administrator tab

Field Description

Individual Enter the AR System user name of the individual who is to be a process administrator.

Authority Use the drop-down list to select the privileges allocated to the individual in the field preceding.! Full Admin—Grants the ability to modify processes as well as

the ability to approve or reject a request regardless of the normal process.

! Override Only Admin—Grants the ability to approve or reject a request regardless of the normal process, but not the ability to create or modify processes.

Notify Method Use the drop-down list to determine the method for notifications to this user.! None—The approval server does not send a notification.! Alert—The approval server sends the notification using

BMC Remedy Alert.See the Configuration Guide, “Using alerts,” page 251.

! Email—The approval server sends the notification through electronic mail. Notifications can be sent to non-AR System users, to an alias for a group, or to an email address representing a program.

! User Default—The approval server sends the notification using the default notification method defined in the User form for each of the recipients. If the User record does not contain a default notification method, BMC Remedy Alert is used.

Covering This option determines the processes for which this person receives process administrator privileges.! All—Grants process administrator authority for all Approval

processes defined in the Process Definition form.! Specific Process—Grants process administrator authority for

the process you select in the Process Name field.

Process Name Use the drop-down list to select a process name if you selected Specific Process in the Covering field.

Status Use the drop-down list to determine the status of this person’s process administration privileges.! Active—The process administrator authority is enabled and

the user can immediately work on processes or requests.! Inactive—The process administrator authority is disabled.

This allows you to temporarily suspend authority of the user when it is not needed, and enable it at a later time.

Search In Search mode, searches the AP:Process Administrator form.

Save In New mode, saves the entry to the form.

Close Close the window without saving.




NOTE The first process administrator must be created by your AR System administrator.

AP:Process DefinitionThis form opens when you click View or Create on the Process tab of AP:Administration. Process administrators use this form to create and modify approval processes. See “Using the Process tab on AP:Administration” on page 98.

Basic tab

Figure D-19: AP:Process Definition form—Basic tab

Table D-18: Fields on AP:Process Definition—Basic tab (Sheet 1 of 7)

Field Description

Process Enter a name for this process. Process names must be unique and must have no more than 254 characters (including spaces). It is helpful to make the name descriptive of the process’s function.

Form Select the AR System form that you are connecting to the approval server. This becomes the approval request form.

Note: You must add the form to the Form tab of the AP:Administration form to make it appear on this menu.



Type Select the process type from the available options:! Parent-Child! Level! Ad Hoc! Rule-BasedSee “Approval process types” on page 75.

Status Select the process status from the available options:! Active—(Default) The process generates approvals for the

approval request form.! Inactive—The process is disabled and generates no approvals.You might want to set the status to Inactive during the development of the process and the associated rules. When all the appropriate rules are in place, you can modify the process and set the status to Active.Requests related to processes in the Inactive state are displayed on Approval Central, but approvers cannot act upon such requests. The following message is displayed in such an event:This action is not allowed on the selected requests, because the related process is inactive. (ARERR 46411)However, approvers can take action on requests related to processes in the Inactive state from the application’s three-way join. To disallow approvers to act upon such requests from the three-way join, developers need to write the appropriate workflow.

Request Owner Field Enter a valid AR System user name or select the field that identifies the owner of the approval request from the menu.The fields in this menu are populated from the approval request form. See “Request Owner Field” on page 239.

First Approver Field Enter a valid AR System user name or select the field that identifies the first approver for this process from the menu.The fields in this menu are populated from the approval request form.This field is required for Ad Hoc process type, optional if you allow ad hoc overrides, and otherwise unused.


Field Description



Generate Preview Select generate preview setting from the available options:! None—The approval server does not generate preview

information in the Preview Signatures form for the process.! On Request Only—The approval server generates preview

information only when it receives a “Generate-Preview” signal. With this option, the application controls the load on the approval server.

! On Start of Process—The approval server generates preview information when any of the following events occurs:! A “Generate-Preview” signal is received.! A new approval process starts (for example, when a details

request is created, or when an existing request that was closed is reopened).

! A new signature is created.! The status of an existing signature changes.

! On Generation or Change to a Signature—The approval server generates preview information when any of the following events occurs:! A “Generate-Preview” signal is received.! A new approval process starts (for example, when a details

request is created, or when an existing request that was closed is reopened).

! A new signature is created or the status of an existing signature is changed.

! Real-time Only—The approval server generates preview information (but does not cache it) only when a preview is requested. This option displays the most current information, but it puts the highest load on the approval server.

Note: If you select the On Request Only, On Start of Process, or On Generation or Change to a Signature option, the preview displayed might not be the most current information.

Can Reassign? Specify whether approvers should or should not be able to reassign a request of this process type to another approver.

Full Name Form Select a form that provides the full name of the approver to be added to the signature line. You could also enter a custom form name by using the adjacent text field. This information is pushed to the Full Name field on AP:Signature.For more information, see “Full Name” on page 254 and “Full Name Form” on page 239.


Field Description



Exclude User Field This menu lists all the fields on the application form. Select a field that contains user names.The users from the selected field are excluded from the list of approvers—their signatures are not created—for a request of this process type.If the selected field contains a role:! Users belonging to that role are excluded.! If the role is part of an approval chain and contains only one

user, the other approvers can act on the request and the process can complete successfully regardless of the One Must Sign or All Must Sign setting.

If an excluded user is an approver in the middle of an approval chain, the approver before the excluded user can act on the request, and the request remains open. However, when the excluded user is encountered, the request state is changed to Error on the application and detail form, and no further action can be taken.The exclusion takes place only after the Get Next Approver rule is executed.Because these users are excluded from the list of approvers, they do not appear on the Approver tab of AP:Show-Detail.For a Level process, if one of the approvers is excluded on a level, other approvers can take action, and the request can proceed.When processing Auto Approval and Self Approval rules, the approval server ignores this field.If a user specified in this field is the only approver for the request, the approval process fails and an error is reported.The user exclusion operations and the related errors, if any, are listed in the approval log files.The values in this field are ignored in the following conditions:! When defining a process:

! If you select the Ad Hoc type.! If one of the users specified for exclusion is also specified as

the first approver.! When acting on a request (regardless of process type):

! If an approver reassigns a request to one of the users specified for exclusion.

! If an approver specifies one of the users specified for exclusion as the next approver.

Note: The check for excluding users from the list of approvers is done before signature creation, therefore it does not impact the requests for which signatures have already been created.


Field Description



Approval Success Select the manner with which the approval server determines whether the approval process for a request is complete:! No More Approvers—(Default) The process is complete when

all signature lines are complete. If you select this option and if the signature line for a request is cancelled and no other signature exists, the request is marked Approved, not Cancelled.

! Completion Rule—Use a Completion rule to determine the successful completion of the approval process. If you select this option, you must create a Completion rule and associate it with this process or the process is never considered complete.

If Multiple Approvers This field applies only if you are defining an Ad Hoc process or are going to allow ad hoc overrides. The value you select determines how many signature line records the approval server creates when building an approver list.Specify using the available options how to manage signature entries when a request is assigned to multiple approvers:! One Must Sign—Create only one signature line for a list of

potential approvers. The signature line is complete when one of the approvers acts on the request. The first approver to act on the request determines the response; the request is withdrawn from the other approvers.The field for approver names on a signature-line record is limited to 255 characters on certain databases. Using roles might help you to work around this limitation, because roles are internally expanded to individual approver names during further processing.This option overrides the If Multiple Approver setting on any roles selected as an approver.

! All Must Sign—Create separate signature lines for each approver. All approvers must act on their own signature line for the request to proceed.If an approver list includes roles, the If Multiple Approver setting for the specific role determines whether the role is expanded into individual signature lines for each member of the role or a single signature line is created for the entire role. See “Defining roles” on page 106.

! Allow Only One Approver—(Default) Create a single signature line for one individual. If you use this option and a requester specifies multiple approvers, the approval server stops the process and marks it as an error.


Field Description



Allow Ad Hoc Next Approver?

This field applies to Parent-Child, Level, and Rule-Based process types.Specify using the available option whether users can add approvers to the approver list for a request:! Anyone—The requester and any approver can select an ad hoc

next approver.! Approver—Only approvers can specify an ad hoc next

approver.! No one—(Default) The process should not allow users to

specify an ad hoc next approver.

For Self Assignment This field specifies how the approval server determines the next approver, when the requester is not the person who submitted the approval request (for example, when an assistant enters an approval request on behalf of someone else).Select from the available options:! Use Get Next Approver Rules—(Default) Use a Get Next

Approver rule to determine the first approver.! Assign to Owner if Approver—Use the requester as the first

approver if the requester is defined as a valid approver for the approval server.If you select this option, you must define a Validate Approver rule to verify whether the owner is a valid approver.

! Always Assign to Owner—Use the requestor as the first approver in all cases.

Validate Approvers This field tells the approval server whether to verify the value in your next approver field with a Validate Approver rule when creating a request.Select from the available options:! Yes—Validate the approvers when saving a request.! No—(Default) Skip validating approvers.

Require password This field determines whether the approver must enter a password to save changes to an approval request.Select from the Available options:! Yes—Mandate the use of a password when saving changes to

an approval request.! No—(Default) Allow saving changes to request without

validating the password.


Field Description




The AR System populates this field with the Assignee Group for the request; the Public group is selected by default. The approval server uses this field to support multi-tenancy for use by application service providers.If you use this field for multi-tenancy support, create workflow to populate this field with the correct assignee group name. You do not need to change this setting when creating the rule.The ID of this field is 112, and it appears on all approval server forms. The field 112 value from records created in the AP:Detail form is used automatically in all the other approval server forms (for example, AP:Signature, AP:More Information, and so on).See “Error 333 and Assignee Group Permission” on page 285.

Ad Hoc Settings This field is enabled only if you select:! An Ad Hoc process type! A process type other than Ad Hoc and “Anyone” or

“Approver” in the Allow Ad Hoc Next Approver fieldThe options are:! Default—(Default) Disables the adjacent Ad Hoc Form field.

When an approver clicks the Adhoc button on AP:Show-Detail, the AP:AdhocDialog dialog box appears. Data about the ad hoc approver entered through AP:AdhocDialog is stored in the AP:AdhocDetails form.

! User Defined—Enables the adjacent Ad Hoc Form field. When an approver clicks the Adhoc button on AP:Show-Detail, the form specified in the Ad Hoc Form field appears. Data about the ad hoc approver entered through this form is stored in AP:AdhocDetails.

Ad Hoc Form This drop-down list displays all the forms in the AR System server. Select the form that you want to be displayed when an approver clicks the Adhoc button on AP:Show-Detail.Approvers should be able to provide data about ad hoc approvers in this form, and the form should have the necessary workflow to store this data in AP:AdhocDetails.If you select a custom form, make sure that application developers have added the necessary fields and workflow to it.

Retrieving first approver failed, error?

This field determines the course of action in case the approval server fails to retrieve the first approver for a request.! Yes—(Default) Set the state of the request to Error and add the

error details to the audit trail.! No—Set the state of the request to Pending. Later, if Add-Sig

is fired for that request, the same AP:Detail record is used.

Search Appears in the Search mode; click to search the AP:Process Definition form.

Save Appears in the New mode; click to save the entry to the AP:Process Definition form.

Close Close the window without saving.


Field Description



Request Owner Field

The setting of this field is crucial for:

! The execution of Self Approval rules—The value of this field is compared with the current user’s name, and if they match, the rule is executed, otherwise it is skipped.

! Finding the first approval in the approval chain—In the Parent-Child, Level, and Rule-Based process types, the first approver in the chain is completely dependent on the name of the person stored in the field mapped to AP:Process Definition > Request Owner Field. The Request Owner Field must contain a valid entry in the approval lookup form (for example, AP-Sample:Signature Authority is the lookup form for the Lunch Scheduler sample application).

To set an appropriate value for Request Owner Field, a process administrator should consider the following:

! Does this field store the name of the person defined in the approval lookup form?

! Is the organizational structure for this user defined in the approval lookup form?

The value of Request Owner Field is not considered when finding the first approver in an ad hoc process, because the requester is responsible for specifying all the required approvers.

Full Name Form

If your application does not contain any User form that contains the full name of a person, you should create a custom form that provides this information. The custom form should contain two character fields, as follows, with their input lengths set to 0:

! The field with the ID 10001 should be used to hold the login name.

! The field with the ID 10002 should be used to capture the full name, which could be generated by any means.

Create a filter on this form, which executes on a service action. This filter should use the data in the first field (10001) as input to generate the corresponding full name and set that in the second field (10002).

See “Full Name” on page 254.



Configuration tab

Figure D-20: AP:Process Definition form—Configuration tab

Table D-19: Fields on AP:Process Definition—Configuration tab (Sheet 1 of 2)

Field Description

Process Intervals

These fields are used to determine the action date for signatures on a request pertaining to this process. See “Action date for a process or signature” on page 80.

Process Due Enter a number in the Interval field and the select the Unit of measurement. This specifies the total duration in which the process is due.

Signature Due Enter a number in the Interval field and the select the Unit of measurement. This specifies the total duration in which each signature for the process is due.

Note: If you enter a value more than what is specified in Process Due, this value is ignored. The value in Process Due is then used to compute the action date, instead of the one you specify in this field.

Buffer Period Enter a number in the Interval field and the select the Unit of measurement. This buffer period is considered as a delta to be deducted from all process intervals, except Signature Due, when computing the action date.



Enable Preview Select Yes to use the Preview feature in calculating the Signature Due Date. The Preview feature is used to fetch information about the future approvers, to calculate the total number of signatures required to complete the process. The Signature Due interval is then computed as the Process Due interval divided by the total number of signatures required.Select No to avoid the use of the Preview feature. In this case, only the value specified in Signature Due is considered.

Note: This field is used only in the case of Parent-Child and Level processes. The value of this field is not considered when calculating the Signature Due interval for ad hoc requests.

Specify menu name to list users for the following operations

More InformationReassignAd-hoc

Select the menu from which to derive user names for the corresponding operations.The selected menu determines the list of users that appears when a user creates a More Information request (by adding a question or comment), or chooses to reassign a request, or to assign a request to an ad hoc approver.If you do not specify a menu for any of these operations, users do not have the option of choosing names from a user list; they can continue with the operation by entering login names manually.

Rejection Justification

Require Justification on Rejection

Select Yes to make it mandatory for an approver to provide a justification when rejecting a request. In addition to storing the justification in various approval server fields, it is pushed to the application form’s field specified in the Justification Field menu.Select No to indicate that rejection justification is optional; an approver is not prompted to justify rejecting a request. However, if provided, the justification is processed further.

Justification Field Select the field in which to store the rejection justification. This menu lists Character fields from the application form.

Note: Currently, this menu also displays Attachment fields along with Character fields, because of an AR System server issue.

From the list of available fields, select a Character field whose length is unrestricted (0). Otherwise, if the approver enters a justification of more than 255 characters:! A warning is added to the approval log.! The justification is not made available on the application form.If you do not select a field from this menu, the approver’s input is stored in the Justification field (ID 14518) on AP:Signature and as a comment of the Justification type on AP:Question-Comment-Info. See “AP:Rejection Justification” on page 271.

Table D-19: Fields on AP:Process Definition—Configuration tab (Sheet 2 of 2)

Field Description



Signature Escalations tabs

Figure D-21: AP:Process Definition form—Signature Escalations (Normal) tab

The three tabs (Normal, Urgent, and Low) on the Signature Escalation tab contain identical fields.

Table D-20: Fields on AP:Process Definition—Signature Escalations tabs (Sheet 1 of 2)

Field Description

Use schedules

Business calendar Use the drop-down list to select a workday schedule created on one of the business time workday forms.

Holiday calendar Use the drop-down list to select a holiday schedule created on one of the business time holiday forms.

Automatic action

After Interval Type a numeric value for the amount of time to pass before this action is taken. For example, type a 2 for two hours or two days. The unit is determined in the next field.

Note: This is called the Automatic Action interval, which is used to compute the action date for the corresponding process.

Unit Select the unit of Hours or Days as the unit for the interval in the previous field.



Change State Use the drop-down list to select the status you want to force on this request if no activity occurs in the interval defined in the two preceding fields.Leave this field and the preceding two empty if you do not want the status of a request changed automatically.

Note: This reflects on AP:Show-Detail > Action Date field and Approval Central > Action Date column. See “AP:Show-Detail” on page 271 and “Approval Central” on page 255.


First Interval Type a numeric value for the amount of time to pass before this notification first occurs.

Note: This is one of the Escalation intervals, which is used to compute the action date for the corresponding process.

Unit Select the unit of Hours or Days for the interval in the previous field.

Note: This reflects on Approval Central > Past Due requests > Action Date column. See “Approval Central” on page 255.

Repeat Interval Type a numeric value for the amount of time to pass before this notification recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.


Notification: Still in State

On State Set the separate escalation and repeat intervals to occur when a form is saved with the status of Pending, Error, Hold, or More Information.

First Interval Type a numeric value for the amount of time to pass before this notification first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.

Note: This is one of the Escalation intervals, which is used to compute the action date for the corresponding process.


Repeat Interval Type a numeric value for the amount of time to pass before this notification recurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.


Table D-20: Fields on AP:Process Definition—Signature Escalations tabs (Sheet 2 of 2)

Field Description



More Information Escalations tab

Figure D-22: AP:Process Definition form—More Information Escalations tab

For more information about the Administrative Information tab, see “Administrative Information tab” on page 267.

Table D-21: Fields on AP:Process Definition—More Information Escalations tab

Field Description

Use schedules

Business calendar Use the drop-down list to select a workday schedule created on one of the business time workday forms.

Holiday calendar Use the drop-down list to select a holiday schedule created on one of the business time holiday forms.

Notification: still outstanding

First interval Type a numeric value for the amount of time to pass before this action first occurs. For example, type a 2 for two hours or two days. The unit is determined in the next field.


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.




AP:Question-Comment-InfoThe approval server uses this form internally to store additional information that requestors and approvers provide about requests.

Table D-22 describes the data stored in this form and the source of that data.

This form also stores the text from the following sources:

AP:Reserved WordProcess administrators use this form to create keywords and functions for approval processes.

Figure D-23: AP:Reserved Word form

Table D-22: Records in AP:Question-Comment-Info

Record type Source field

Question Stores text from the Question field on AP:Show-Detail or AP:More Information.

Comment Stores text from the Summary field on AP:Show-Detail or the Comment field (if added) on the application form.If you add an activity log entry of the Justification type on AP:Show-Detail, text from the Summary field is also stored here.Attachments associated with comments are stored in the attachments table adjacent to this field.

Justification Stores text from the Justification For Action field on AP:Show-Detail or Approval Central.If the Justification For Action field and its appropriate workflow is added to the application form or the three-way join form, the corresponding text is stored here.

Form Field

AP:More Information Response

AP:Show-Detail ! Response! Notes

Application form Notes (if added with the appropriate workflow)



AP:RoleThe AP:Role form opens when you click View or Create on the Role tab of AP:Administration. Process administrators use this form to create role definitions for approval processes. See “Defining roles” on page 106.

Figure D-24: AP:Role form—Role Information tab


Table D-23: Fields on AP:Reserved Word

Field Description

Name Type the word you want to reserve.

Name Type Click the option button to select whether the word is a keyword or function.


Select the name of the special control group for you want to have row-level permissions.

Table D-24: Fields on AP:Role—Role Information tab (Sheet 1 of 2)

Field Description

Role Name Type the name for this role.

If Multiple Approvers Select one of the options:! One must sign—A single signature entry is created for all

individuals in the Member List field. Only one individual needs to take action.

! All must sign—Separate signature entries are created for all individuals in the Member List field. All individuals must take action for the request to move forward.

This field is valid only if more than one entry exists in the Member List field.



AP:Rule DefinitionThe AP:Rule Definition form opens when you click View or Create on the Rule tab of AP:Administration.

Basic tab

Figure D-25: AP:Rule Definition form—Basic tab

Process administrators use this form to create and modify rules for approval processes. See “Using the Rule tab on AP:Administration” on page 110.

Status Use the drop-down list to select the status of this role.! Active—This role can be used by any approval process.! Inactive—This role is disabled for all approval processes.

Member List Type the AR System user name for each person who is a member of this role. Use a semicolon (;) as a separator between names.

Table D-24: Fields on AP:Role—Role Information tab (Sheet 2 of 2)

Field Description

Table D-25: Fields on AP:Rule Definition—Basic tab (Sheet 1 of 4)

Field Description

Definition

Rule Name Type a name for this rule.The name of a rule can be as long as 254 characters in English and most European languages, but only 127 characters in double-byte languages.

For Process Use the drop-down list to select a process for this rule.



Process Instance ID The AR System automatically populates this field with the GUID of the process.

Rule Type Use the drop-down list to select the rule type. See Chapter 7, “Defining approval rules.”

Order Type a number to determine execution order for this rule. Larger numbers execute after smaller numbers. Rules with the same number in this field execute in an unpredictable order.

Status Use the drop-down list to select the status of this rule.

If Multiple Results Use the drop-down list to select the behavior when multiple results are found.

! Value from First—The approval server uses the value from the first record retrieved.

! Values from All—The approval server uses all of the values retrieved.

! Return Error—The approval server produces an error message if more than one record is retrieved.

If Multiple Approvers Select one of the options:! One Must Sign—A single signature entry is created for all

approvers. Only one of those approvers needs to take action on the request.

! All Must Sign—Separate signature entries are created for all approvers. All approvers must act on the request for it to move to the next stage.

Next Approver Rule Is Use the drop-down list to select the behavior when multiple Get Next Approver rules exist.! Additive—This rule appends approvers to the existing

approver list, and further rules are processed.! Ending—This rule appends additional approvers to the

existing approver list, but no further rules are processed.! Exclusive—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 usually used for a Rule-Based process that has a set of Get Next Approver rules to build an approver list.


The AR System populates this field with the Assignee Group for the request. This field supports the multi-tenancy feature.See “Error 333 and Assignee Group Permission” on page 285.


Field Description



Qualification

Run if This field label appears for the following rule types:! Get Authority! Get Authority Regular! Get Authority Self! Get Next Approver! Parameterized Get Next Approval Rule! Prep Get Next Approver! Signature Accumulator! Statistical Override! Validate ApproverEnter the qualification in the Run If field. Use the buttons and drop-down list to help. See “Using the Rule tab on AP:Administration” on page 110. In addition, you can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:

‘Submitter’ = “John”Otherwise, if you enter:

$Submitter$ = “John”the value from the current transaction will be returned:“John” = “John”

Rule This field label appears for the following rule types:! Auto Approval! Self Approval! Completion RuleEnter the qualification in the Rule field. Use the buttons and drop-down list to help. See “Using the Rule tab on AP:Administration” on page 110. In addition, you can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:

‘Submitter’ = “John”Otherwise, if you enter:

$Submitter$ = “John”the value from the current transaction will be returned:“John” = “John”

Audit text This field appears for Auto Approval and Self Approval rules. Type the text you want to appear in the permanent record for the request whenever this rule executes. Use the drop-down list to select keywords to include in your audit trail message.


Field Description



Set Fields tabThe Set Fields tab appears only when you select a rule type for which you can specify a Run If qualification and the subsequent Set Fields actions.

Figure D-26: AP:Rule Definition form—Set Fields tab

Rule State This field label appears for Approval Process Done rules. Select one or more rule conditions from among the radio buttons.The options are:! Approved! Rejected! Cancelled! ErrorThe rule executes when the approval detail record moves to the selected state.

Guaranteed Add ! Yes—The parameterized rule runs even when a Completion rule would otherwise determine that the process is done, thus guaranteeing that the user will be added as an approver.

! No—(Default) If a Completion rule determines that the conditions exist for the process to be done, the process does not return to the Get Next Approver stage to run this rule.

Search In Search mode, click this button to perform your search.

Save In Submit mode, click this button to save your changes.

Close Click this button to close the window.


Field Description



Table D-26: Fields on AP:Rule Definition—Set Fields tab (Sheet 1 of 2)

Field Description

Set Fields Type Select an item from the drop-down list to specify how the rule should populate this field type. The options are: Value, Query, SQL, Process, and Other.

From Form For a query, select the name of the form that contains the data to retrieve.

On Server Use the drop-down list to select the server that contains the form.! Current—Select this option if the form resides on the same

server as the approval server.! Alternate—Select this option if the form resides on another

server.

Server Type the name of the server that holds the form.This field is available only when the On Server field contains the value Alternate.

Separator string Type the letters, numbers, or symbols to use when separating multiple entries set in the same field.This field is disabled with some options available in the Set Field Type field.

Qualification

Query builder buttons The Fields from Set Fields Form, Fields from Application Form, and other SQL keywords and operator buttons are available for use only when you select a Set Fields type other than Value.For example, choosing SQL causes Select, From, Where, and the comma separator (,) buttons to appear so that you can construct SQL statements easily.

SQL Command / Qualification Type a qualification or use the other fields to select functions or

keywords.You can dynamically define the search criteria by using the EXTERNAL keyword. When using the EXTERNAL keyword, make sure you see fields using single quotes instead of dollar signs, for example:‘Submitter’ = “John”Otherwise, if you enter:$Submitter$ = “John”then the value from the current transaction is returned:“John” = “John”




AP:SignatureThe AP:Signature form stores the signature lines for approval requests. Administrators can use this form to review the responses to a request. However, you should modify this information only through Approval Central.

Figure D-27: AP:Signature form

Fields data

Field name Type a field name or use the drop-down list to select a field name. The Field Name field is disabled with some options available in the Set Field Type field.One rule can populate more than one field by using separate lines for Field Name and Value.

Value Type the value or use the drop-down list to select a value to populate the field. The Value field is disabled for some Set Field types.One rule can populate more than one field by using separate lines for Field Name and Value.

Table D-26: Fields on AP:Rule Definition—Set Fields tab (Sheet 2 of 2)

Field Description



The approval server automatically drops duplicate signature lines if an approver appears in multiple groups to which a request is assigned or if there are duplicate individual mappings.

Table D-27: Fields on AP:Signature

Field Description

Approval ID The AR System populates this field with the AR System ID for this request.

Approvers The AR System populates this field with the name of the approver for this signature line.

More Information The AR System populates this field with the questions and answers to More Information Requests.

Approval Status The AR System populates this field with the status of the request.

Next Approver The AR System populates this field in an ad hoc situation with the name of the next approver.

If Multiple Approvers This field is valid only if multiple entries exist in the Next Approver field. Select one of the options:! One Must Sign—A single signature entry is created for all

approvers in the Next Approver field. Only one of those approvers needs to take action on the request.

! All Must Sign—Separate signature entries are created for all approvers in the Next Approver field. All approvers must act on the request for it to move to the next stage.

Alternate Signature The AR System populates this field with the user name of an alternate approver, if the alternate acts on the request.

Approver Signature The AR System populates this field with the user name of the approver when the approver acts on the request.

Signature Method The AR System populates this field with the method by which this request was approved.! Alternate—An alternate signed this request instead of a

normally scheduled approver.! Regular—A normally scheduled approver signed this request.! Override—Someone with process administration authority

performed an override to respond to this request instead of a normally scheduled approver.



Full Name Used to store the full names of approvers to whom the corresponding request is assigned.See “Full Name” on page 254.

Role ID Used to make a signature role aware.For more information, see “Role ID” on page 254 and “Creating signature escalations” on page 101.



In such a event, entries such as the following are recorded in the approval log:

<APPR> * Process option set to not validate user so no work needed<APPR> Expanding roles for approver(s): SGP000000000082|CAB-Member<APPR> Expanding roles for approver(s): SGP000000000084|CAB-MemberAPPR> Dropping duplicate approver line for USER1;USER2;USER3;<APPR> Dropping duplicate approver line for USER1;USER2;USER3;

You can safely ignore such log entries; the signature lines are dropped because the approval server maintains only one signature line for an approver per request until the associated process is active.

Full NameThe approval server uses the login name to search for the corresponding full name when creating a signature entry. It first searches the User forms, and if they do not have the full name information, it searches the custom form specified on AP:Process Definition. This information is stored in the Full Name character field (14201). See “Full Name Form” on page 239.

If there is no custom Full Name Form, or if the full name information is not found through this form, the login name is used as default.

Setting the full name on a signature line is a one-time activity; this value is not set at run time. The full name provided at the time of signature line creation stays constant. When upgrading to release 7.5.00 or later, if the Full Name value is not available, it is set according to the current Full Name value from the related form. If the Full Name value is required to be set dynamically, application developers must write the appropriate escalations, because applications can fetch user information from different forms, like the User form, CTM:People form, and so on.

Role IDIf a signature is created by expanding a role, the Role ID character field (14200) stores the role ID of the source role, which was expanded to create the individual signature line. The following situations could occur:

! If a role has One Must Sign set to true, only one signature entry is created for all the members belonging to the role. The related role ID is copied to the Role ID character field.

! If a role has All Must Sign set to true, the role ID is copied to each signature entry that is created by expanding the role.

Depending on the process definition, the signature entries are created as follows:

! When One Must Sign is defined at the process level, only one signature entry is created, irrespective of the If Multiple Approvers setting at the role level. In this case, the individuals defined as approvers and the individuals expanded from the roles provided as approvers appear in a single signature entry. Role IDs for all the roles in the approvers list are put in the newly added field on the AP:Signature form for the corresponding signature.


User forms

! When All Must Sign is defined at the process level, multiple signatures are created according to the If Multiple Approvers setting at the role level. In this case, each signature entry contains the role ID that was responsible for creating the entry by expanding the individuals in the role.

The values in the Role ID field could differ as follows:

! The Role ID field remains blank for individuals in the approvers list.

! The Role ID field can have a single role ID or multiple roles IDs based on the definitions. All role IDs are enclosed between semicolons.

! Consider a case where a role is defined as an approver, which in turn is composed of roles. When this is expanded recursively to write individuals in the signature entry, the Role ID field has the role ID of the base role that was provided as the approver.

For example: The Finance role contains the users Jim and Frank. The Purchase role contains the users Paul and Bob. The Administrator role is a superset of Finance, Purchase, and a few more roles. When the Administrator role is defined as an approver for a request, even though it expands the Finance, Purchase, and other roles recursively to get individual approvers, the Role ID fields of the signatures created for these approvers contains the role ID of the Administrator role.

AR System Business Time formsProcess Administrators use the following AR System forms to determine the business hours and holidays to be used by approval processes and other AR System workflow:

! Business Time Holidays

! Business Time Workdays

See the Configuration Guide, “Using the old Business Time forms,” page 240.

User formsUser forms are used by submitters, approvers, process administrators, and so on.

Approval CentralThe Approval Central form, which acts as the approval server console, appears when you log in to AR System and click the Approval Central link on the home page. This link is localized.

TIP The localized link is visible only if the Localize Server option is enabled on the Advanced tab of the AR System Administration: Server Information form. See the Configuration Guide, “Server Information—Advanced tab,” page 121.



NOTE The Approval Central view is not supported on 7.0.01 or earlier versions of AR System clients. When Approval Central is opened in version 7.0.01 of BMC Remedy Mid Tier or BMC Remedy User, a warning message is displayed and the counts against the links in the left pane are not displayed.

Approvers use Approval Central to respond to approval requests, and to access request details. Requesters use it to access More Information requests sent to them. See Chapter 3, “Processing approval requests.”

Figure D-28: Approval Central form

Approval Central enables you to quickly review the approval requests awaiting your attention. These could be direct requests or requests for which you act as an alternate approver. You can approve, reject, hold, or view the details of a pending request using the appropriate buttons provided at the bottom of the form. You can reassign a pending request only if the Can Reassign option for the corresponding approval process is set to Yes in AP:Process Definition.

When you open Approval Central, the Pending Approvals table appears by default, and it displays requests that have the Pending, Hold, or More Information status.


User forms

The left pane contains two sections: Approval Tasks and Action Menu. Clicking a link in these sections displays a corresponding panel in the right pane.

Approval TasksThe links in this section correspond to pre-defined searches. A table in the corresponding panel on the right displays the search results. See “Approval Search Result table” on page 259.

Approval requests that need attention

When you click the Needs Attention link in the Approval Tasks section of the left pane, a table of questions and answers posted to you appears in the right pane.

The table contains the columns: From, To, Action Date, Application, Request, and Status, which display the corresponding information for each request.

You can perform one of the following actions on any selected request in this table:

! Click Respond to answer the corresponding question. The AP:More Information form opens in the Modify mode.

! Click View to open the corresponding question-answer thread. The AP:More Information form opens in the display mode.

Table D-28: Fields on Approval Central—Approval Tasks section

Field Description

Needs Attention Click to view the requests for which a question or answer is directed at you. Such requests are in the More Information state.The Need Attention Approvals panel displays a table with the columns: From, To, Action Date, Description, Application, Request, and Status.

Pending Approvals Click to view the requests that await your approval. Such requests are in the Pending state.

Past Due Click to view the requests whose Action Date has passed. The Past Due Approvals table displays requests having the Pending, Hold, or More Information status.For more information about the Action Date, see step 5 and step 6 of the“To enter signature escalations” section.

Due Soon Click to view the requests whose Action Date is approaching. The Due Soon Approvals table displays requests having the Pending, Hold, or More Information status.A Process Administrator configures, through AP:Administration, the time factor that decides whether an approval request falls under the Due Soon category. For more information, see step 5 of the “To enter signature escalations” section.

Rejected by Others Click to view the requests that you approved earlier, but are rejected by an approver further in the approval sequence.This is a pre-defined search, the results of which appear on the right pane in the Approvals Rejected by Others panel.



After you respond to a question or view the answer to a question you raised, the state of the request changes from More Information to Pending.

Action Menu

The right pane displays the appropriate panels when you click the links in the Approval Tasks or the Action Menu sections in the left pane. You can expand or collapse these panels using the arrow icon next to the panel title.

Approval SearchEnables you to specify criteria for searching through approval requests. Select or enter field values in this section of the form to search for requests and display the results in the Search Results table.

Figure D-29: Approval Central form—Approval Search section

Table D-29: Fields on Approval Central—Action Menu section

Field Description

My Recent History Click to view the requests that you approved or rejected, and requests that have the Error status. This is a pre-defined search, the results of which appear on the right pane in the My Recent Approvals History table. Requests displayed in this table have the Approved, Rejected, or Error status.

A Process Administrator configures the number of history items to display. See “AP:Admin-ServerSettings” on page 212.This is a pre-defined search, the results of which appear on the right pane in the My Recent Approvals History table.

Search My Approvals Click to display the Approval Search panel where you can specify various search criteria and view the results in the Search Results table.

My Alternate Approvers

Click this link to open the AP:Alternate form in New mode.For more information, see “AP:Alternate” on page 266.


User forms

Approval Search Result tableThe Approval Search Result table is displayed in the right pane, and its contents change according to the links you click in the left pane.

Some rows might have a bell icon displayed in the first untitled column, indicating that the corresponding request is Urgent.

Table D-30: Fields on Approval Central—Approval Search section

Field Description

Application Select an application from the list of available applications.Select the name of the approval request form from the list to search for approval requests related to that form.

Process Select a process. If you select an application, only the processes belonging to that application appear in this menu.

Acting As Select a value from the list to search for requests with the selected type of approver authority. The default is “Myself.”If you choose “All” and perform a search, the resulting list contains the same requests that appear when you click the Pending Approvals link.

User Contains the name of the current user or the user on whose behalf you are acting as alternate, or performing an override.! If Acting As is set to “Myself” or “Global Override,”

AR System populates this field with the name of the current user.

! If Acting As is set to “Alternate” or “Override,” you must enter the AR System name of the user for whom you are acting as an alternate, or performing an override.

Approval Status Select an approval status from the list to search for requests with the selected status. The default is “Pending.”

Requester Type all or part of a requester’s AR System full name to search for approval requests from that requester. The search results display the requests created by this requester only if you have the correct privileges on the corresponding requests.

Summary Enter one or more words in the summary that you want to search for.

Action Date Select the Action Date.See “Signature Escalations tabs” on page 242 and step 5 of the “To enter signature escalations” section.

Priority Select the priority. This is the priority of the approval request and not that of the application request.

Modified Date Select the date on which the requests you want to search for were last modified.

Search Click to perform the search after you specify all the required criteria.

Clear All Click to clear all the search fields.



The second untitled column contains check boxes that you can use to select the corresponding requests. Use the check boxes to select multiple requests on which you want to perform similar actions.

Clicking on a row, without using the corresponding check box, will select that row and deselect everything else. Click the Select All or Deselect All buttons to select or deselect all the requests in this table. See “Working with multiple pending requests” on page 261.

Table D-31: Fields on Approval Central—Approval Search Result table (Sheet 1 of 2)

Field Description

Action Date The date on or before which, if you do not act upon the request, either you receive a notification that it is still outstanding, or the state of the request is changed automatically.This is applicable only to those requests where Notification:Still Outstanding, or Automatic Action, or both are configured in the corresponding AP:Process Definition form. The Action Date is calculated as the least of these two values, if both are specified. See “Signature Escalations tabs” on page 242 and step 5 of the “To enter signature escalations” section.

Summary The description associated with the Source ID (Application ID). This value is populated from field 14506 on AP:Detail that contains the Description value for the associated application request.When you hover over this field, a tool tip displays the comment provided by the requestor when creating the application request. This additional information helps you take a quick decision about the request.

Note: This field appears only if the appropriate setting is done on the Advanced tab of AP:Form. See “AP:Form” on page 220.

Requester The name of the requestor. This information is obtained from the three-way join form for the related application.

Acting As The name of the approver to whom the request is originally assigned. This field contains a value only if you are the alternate approver for the original request assignee.

Priority The priority of the approval request that is stored in the corresponding AP:Detail record. The possible values are: Urgent, Normal, and Low.

Application The application name associated with the request. For example: SRM, Change Management. This name is provided by the application itself.

Status The current state of the request. The possible values are: Pending, Approved, Rejected, Cancelled, Hold, More Information, Error, and Closed.


User forms

Working with multiple pending requests

To select a single row in the Approval Requests table, click anywhere on the row; its check box gets selected and those of other rows are unselected. To select multiple requests, use the corresponding check boxes. However, at a time only one row appears highlighted (irrespective of the status of its check box).

NOTE Multiple row selection does not work for requests of the Needs Attention category.

You can select multiple requests and approve, reject, hold, or reassign them together. Upon clicking the appropriate action button, a guide runs through the individual requests and performs the actions. If one or more of the associated processes mandate passwords, you are prompted to provide it, only once, before the action is performed.

Setting display preferences on Approval Central

Use the Preferences menu to set display preferences for the tables on this screen as follows:

! Add Column—Use to select a column to be displayed.

! Remove Column—Use to select a column to be hidden.

! Set Refresh Interval—Click to open a dialog box that allows you to specify the duration (in minutes) after which the table is automatically refreshed.

! Reset—Click to revert any changes you made to the appearance of the table, or the refresh interval.

! Save—Click to save any changes you made to the appearance of the table or the refresh interval. These changes are saved only for the current session and are not persistent, which means they are not retained when you log out and log in again.

Preferences Click to set the preferences to display items in this table. You can choose to display or hide a column, set the refresh interval, and reset or save the display settings.

Justification For Action Enter some meaningful text in this field to be recorded as a justification for your action, and click Reject. An entry is added to the Activity Log table.If you click any other action button, this field is ignored.For information about how your input is processed, see “Rejection justification for approval requests” on page 40.

Table D-31: Fields on Approval Central—Approval Search Result table (Sheet 2 of 2)

Field Description



Action buttonsYou can select one or more requests on Approval Central and click the appropriate buttons to perform the desired actions. The buttons are disabled only if there are no requests to be selected.

Selecting one or more requests enables all the action buttons irrespective of the status of the request. If a certain action can not be performed on a selected request, one of the following occurs:

! Clicking the action button has no effect. For example, if you select a request that is on hold, clicking the Hold button will have no effect.

! Clicking the action button displays an error message and the request remains unchanged. For example, if you select an request with the Approved, Rejected, or Error status and click either Approve, Reject, Hold, or Reassign, the following error message is displayed:

Select atleast one row with appropriate status to perform the buttonLabel action. (ARERR errorNumber)

Table D-32: Action buttons to operate on selected requests

Field Description

Approve Click to approve the selected requests.

Reject Click to reject the selected requests.If rejection justification is mandatory, but the Justification For Action field is empty, a dialog box prompts you to enter a reason for rejecting the request. The same comment is applied to all the selected requests.See “Rejection justification for approval requests” on page 40.

Hold Click to put the selected requests on hold.

Reassign Click to reassign the selected requests to another person.If Can Reassign is set to Yes for the corresponding process, the AP:Reassign dialog box prompts you to enter the name of an approver; otherwise an error is displayed.

Note: The AP:Reassign dialog box appears only once, which means that all the selected requests are assigned to the same person. Validation for the user name entered in the dialog box is not provided out-of-the-box.

View Details Click to open the AP:Show-Detail form, which displays the details of the highlighted approval request and enables you to take further action.This command works on only one request at a time. If you select multiple requests and click View Details, the Activity Log is displayed only for the request whose row appears highlighted.


User forms

Approval Request Summary

When you click any of the Approve, Reject, Hold, or Reassign buttons, a dialog box prompts you to enter your password. The statuses of the selected requests are changed only if you provide a valid password, otherwise an error is displayed.

AP:AdhocDialogThis dialog box appears when you click the Adhoc button on the AP:Show-Detail form for a request. The appearance of this dialog box is dependent on the value of the Ad Hoc Settings field on AP:Process Definition; it appears only if the Default option is selected. However, if the approval administrator selects the User Defined option, the custom dialog box for the corresponding form is displayed.

AP:AdhocDialog shows the list of existing ad hoc approvers, if any, and enables you to add to or remove from this list. If the table contains multiple rows, the first row is selected by default.

Table D-33: Fields on Approval Central—Approval Request Summary section

Field Description

Source ID Displays the application ID (the request ID or any other ID in the application) as a link. Click the link to display the relevant application form.

Note: If you upgrade from an earlier version of the approval server to 7.5.00 or later, this link displays the correct application ID for newly created requests. The application ID might not be accurate for requests that were created before upgrading. To specify the value for this link, the process administrator must map the Application Request ID field on the Advanced tab of AP:Form to the appropriate field on the application form. See “AP:Form” on page 220.

Notes Displays the notes associated with the Source ID, if any.The value of this field is retrieved from the application form field that the process administrator mapped to Field8 {14513} on the Advanced tab of AP:Form. See “AP:Form” on page 220.

Activity Log Displays the activity log (Questions, Comments, and other information) associated with the Source ID.Click View Activity Summary to view all the activities related to the current request in a report format.



Figure D-30: AP:AdhocDialog form

Table D-34: Fields on AP:AdhocDialog (Sheet 1 of 2)

Field Description

Name Select a name from the user list or enter the name of a new ad hoc approver. You can also specify multiple ad hoc approvers by typing their names separated by semicolons.If you select a row in the following table, the corresponding approver name appears in this field, but you can modify and save it.

Sequence Enter or modify the sequence at which to add the ad hoc approver. The default is 1.

If Multiple Approvers Select one of the options:! One Must Sign—Only one signature entry is created. If you

specified multiple approvers, only one of them needs to take action on this request.

! All Must Sign—A separate signature entry is created for each approver in the Name field. All of them must take action on the request for it to move to the next stage.

Independent Select one of the options.! Yes—Indicates to the approval server that the request can

proceed to the next level of its process without waiting for the signature of the current ad hoc approver.

! No—Indicates to the approval server that the current ad hoc approver’s signature is required before the request can proceed to the next level of its process.


Note: This menu is available on the mid tier only.


User forms

NOTE After you add an ad hoc approver at the current level and save the record (the data is saved in AP:AdhocDetails), you cannot modify it. If you need to make changes, delete the existing ad hoc approver record and create a new one.

You can modify the record of an ad hoc approver who is assigned for a future level.

Refresh Click to refresh the contents of this table.

Note: This field is available on the mid tier only.

Add Click to add a new ad hoc approver, after you enter appropriate values in the fields.

Modify Select a row that you have not yet saved, and click to modify the details of the corresponding ad hoc approver.

Note: This button remains disabled when you select rows that have already been saved.

Delete Select one or more rows using the corresponding check box and click to delete the association of the corresponding ad hoc approvers with the current request.

Save Select one or more rows using the corresponding check box and click to save the new ad hoc approvers to the AP:AdhocDetails form.

Note: Even though a row is added to the table, it is not saved until you explicitly select it and click Save.

Close Click to close the dialog box; if there are any unsaved records in the table, you can confirm whether to return to the dialog box and save them or ignore them and close the dialog box.If you make any changes to the list of ad hoc approvers, the contents of the Approver tab reflect the same.

Table D-34: Fields on AP:AdhocDialog (Sheet 2 of 2)

Field Description



AP:AlternateApprovers use this form to create, delete, and maintain alternate approvers.

Alternate Information tab

Figure D-31: AP:Alternate form—Alternate Information tab

Table D-35: Fields on AP:Alternate—Alternate Information tab (Sheet 1 of 2)

Field Description

Alternate Type the AR System user name of the person who is to act as alternate.

For Type the AR System user name of the person for whom the Alternate will substitute. The default is the current user.

Start Date Open the calendar control and select the date and time when the alternate’s authority begins.

End Date Open the calendar control and select the date and time when the alternate’s authority ends.

Notify Alternate Select whether the alternate is notified when a request comes to the original approver.! Yes notifies the alternate when a request is pending.! No does not notify the alternate.To notify alternates, the process administrator must perform the following tasks: 1 Create notifications on the New Signature notify on event.2 Select Enabled Including Alternate on the AP:Admin-Server

Settings form.


User forms

Administrative Information tab

Figure D-32: AP:Alternate form—Administrative Information tab

Covering Select a value to identify which processes are included in this alternate’s authority.! All—This alternate has authority to approve all processes for

which the original approver has authority.! Specific Process—This alternate has authority for only the

process specified in the Process field.

Process If you selected Specific Process, select the process for which the alternate has authority.

Process Instance ID AR System automatically enters the GUID of the process selected in the Process field.

Status AR System automatically completes this field based on the server’s current date and time.! Future—This alternate is not yet active.! Current—The alternate is presently active.! Past—The alternate is no longer active.! Cancelled—The alternate record has been cancelled and the

alternate is not active.

Search In Search mode, searches the AP:Alternate form.

Save Save changes and entries to the form.

Close Close the window without making any changes.

Table D-35: Fields on AP:Alternate—Alternate Information tab (Sheet 2 of 2)

Field Description



AP:Dtl-Sig-MoreInfoDialogThis form appears when you click More Information on the AP:Detail-Signature form, or Manage More Information on the three-way join forms in the sample applications. When opened, it is populated with a list of More Information requests related to the current approval request.

Figure D-33: AP:Dtl-Sig-MoreInfoDialog form

Table D-36: Fields on AP:Alternate—Administrative Information tab

Field Description

Alternate ID AR System populates this field with an AR System ID for this record.

Create Date AR System populates this field with the date this alternate was created.

Assigned To Type the name of the original approver assigning authority to this alternate. The default is the current user.

Help Text Type information to aid users who are setting up alternates.

Change history Type any additional information to be recorded with the alternate assignment. This information becomes part of the permanent record for this alternate.

Last Modified By AR System populates this field with the name of the person who last modified this alternate.

Last Modified Date AR System populates this field with the date of the last modification to this alternate.

Table D-37: Fields on AP:Dtl-Sig-MoreInfoDialog (Sheet 1 of 2)

Field Description

Existing More Information records

This field displays any More Information records attached to the current approval process.


Refresh Refreshes the list.


User forms

AP:More InformationThis form contains More Information requests. It opens when you click New Record or Open on the AP:Dtl-Sig-MoreInfoDialog form.

Figure D-34: AP:More Information form

New Record Opens the AP:More Information form in New mode, where you can create a new More Information request.

Open Opens the selected item in list.

Close Close the form.

Table D-37: Fields on AP:Dtl-Sig-MoreInfoDialog (Sheet 2 of 2)

Field Description

Table D-38: Fields on AP:More Information

Field Description

To Select the recipient’s name from the menu, or enter the recipient’s AR System user name. You can not select or enter multiple names in this field.The user names in this drop-down list are determined by the menu specified in the process definition. For more information, see “AP:Process Definition” on page 231.

From AR System user name of the sender of the More Information request. This field is read-only after the record is saved.

More Info Status Status of the More Information request.

Application The application to which the request belongs.

Request Request ID of the request.

Question The question pertaining to the More Information request.

Response Response to question about the More Information request.





AP:PasswordThis dialog box appears when an approver clicks Approve, Reject, or Reassign on Approval Central for a request whose process requires a password. An approver must enter the correct AR System user password and click Submit. If the password in authenticated, the request status is changed. Otherwise, an authentication error is displayed and no action is taken on the request.

AP:Reassign

Figure D-35: AP:Reassign dialog box

This dialog box appears when an approver selects one or more approval requests on Approval Central or opens AP:Show-Detail for a record, and clicks Reassign.

Select a name from the user list or enter the precise AR System login name of the approver to whom you want to reassign the request, and click OK.

If the requests you selected belong to different processes, each of which have a different menu configuration for the user list, the user list pertaining to the first request is displayed. To choose from the appropriate user list for a request, work with a single request at a time.

Click Cancel to close the dialog box without performing any action on the request.

Table D-39: Fields on AP:Password

Field Description

Submit Enter the correct password to approve or reject the request, and click to submit the password for authentication.If authenticated, an Approve or Reject action occurs. If not authenticated, AR System returns an authentication error.

Cancel Click to close the dialog box without submitting the password. No action is taken on the request.


User forms

AP:Rejection JustificationThis dialog box appears when an approver selects one or more approval requests on Approval Central or opens AP:Show-Detail and clicks Reject without entering some text in the Justification For Action field.

The approver can perform the following actions:

! Enter the justification for rejecting the request, and click OK.

When rejecting multiple requests simultaneously, the dialog box appears only once. The same comment is added to the activity log of all the selected requests.

! Click Cancel to close the dialog box without providing a comment.

If the process mandates rejection justification, the Reject action is skipped and a message to that effect is displayed. The request remains in the Pending state.

AP:Show-DetailThe AP:Show-Detail form displays all the data related to an approval request. This data is fetched from the AP:Detail form.

For more information, see “AP:Detail” on page 215.



Figure D-36: AP:Show-Detail form—Approver tab with multi-process preview

The P-C Phase, P-C GL Account, P-C Cost Center, and P-C Total Cost are generic character fields, which application developers can use to show additional character data. The labels of these fields can also be changed dynamically so that the labels are in sync with the values. These labels are localized.

NOTE Localized labels are visible only if the Localize Server option is enabled on the Advanced tab of the AR System Administration: Server Information form. See the Configuration Guide, “Server Information—Advanced tab,” page 121.

The Action Date field indicates the duration after which the state of the approval request is changed automatically or a notification is sent to the relevant approver to act on the same. This occurs only if it is so defined in the process. For more information, see “AP:Process Definition” on page 231 and “Creating signature escalations” on page 101.


User forms

You can use this form to perform the following operations:

! View a history of activities on a request for any approval process in the form of a table or a flowchart.

! Add or remove ad hoc approvers to the approval chain.

! Add and view questions, comments, notes, and attachments for further information.

When you click any of the Approve, Reject, Reassign, Hold, or Adhoc buttons, a dialog box prompts you to enter your password. The request status is changed, or AP:AdhocDialog is displayed, only if you provide a valid password, otherwise an error is displayed.

Table D-40: Fields on AP:Show-Detail

Field Description

Approver tab Displays the approval process preview for the current request as a flowchart or a table.

See “Approver tab” on page 274.

Activity Log tab Displays the list of questions and comments associated with the current request in a table. You can also add or delete questions and comments.See “Activity Log tab” on page 276.

Approve Click to approve the current request.

Reject Click to reject the current request.

Reassign Click to reassign the current request to another person. If Can Reassign is set to Yes for the corresponding process, a dialog box prompts you to enter the name of an approver; otherwise an error is displayed.

Hold Click to put the current request on hold.

Adhoc Click to add ad hoc approvers to the approval chain or remove existing ad hoc approvers for the selected requests. The table or flowchart in the Approver tab is updated accordingly.The Adhoc button is disabled in the following conditions:! Ad Hoc Settings are not defined for the associated process.! The request is in the Process Done stage.If the Default option is selected for the Ad Hoc Settings of a process, the AP:AdhocDialog appears for the corresponding request. See “AP:AdhocDialog” on page 263.

Close Click to close the AP:Show-Detail form.



Approver tabThis tab displays a preview of the processes through which the current request might traverse until it reaches the Completion Check stage.

A legend at the bottom of this tab indicates the meaning of the status icons attached to each signature in the preview.

NOTE When the AP:Show-Detail form is viewed through versions earlier than 7.5.00 of BMC Remedy User or BMC Remedy Mid Tier, the Preview Type option on the Approver tab is unavailable (disabled).

Sequence diagram

The sequence diagram is a flowchart representation of the approval chain for the current request. If you add or remove an ad hoc approver, or perform any other action on the request, it is reflected in the flowchart immediately. If an approver name is not available, the flowchart displays empty blocks in its place. The flowchart displays only valid approvers.

Table D-41: Fields on AP:Show-Detail—Approver tab

Field Description

Preview Type: Current Process Only

Click to see a preview of how the current request might traverse through the current approval process.This preview is generated after the process begins (when the detail and signature records for the current request have been created).

Preview Type: Multiple Processes

Click to see a flowchart or tabular view of the path the current request might traverse when it pertains to multiple processes.This view appears only when the Generate-Multi-Process-Preview application command is executed, whose input values determine the what appears in the view.See “Multi-process preview” on page 170.

View As: Sequence Diagram

Click to see a flowchart view of the current approval request.See “Sequence diagram” on page 274.

View As: Table Click to see a tabular view of the current approval request.See “Table” on page 275.

Zoom Click the icon to see an enlarged flowchart view in a new window.

Note: This button is available only when viewing the Sequence Diagram.

Refresh Click to refresh the contents of this tab.

Note: This button is provided because the mid tier does not allow the use of the F5 key (Windows) to refresh the contents of the current screen.


User forms

The flowchart view is localized; its elements can be displayed in all languages available with AR System.

NOTE Localized data is visible only if the Localize Server option is enabled on the Advanced tab of the AR System Administration: Server Information form. See the Configuration Guide, “Server Information—Advanced tab,” page 121.

The flowchart view is available out-of-the-box on AP:Show-Detail, which has two related active links, namely, AP:Show-Detail-LoadObject and AP:Show-Detail-HandleEvent.

To display a customized flowchart view on your own form, you need:

! A Data Visualization Field (DVF) pointing to the Visualizer module.

! Two active links that accept three input values, namely, application request ID, application form name, and detail ID. Providing the detail ID is optional.

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

The flowchart view is backward compatible with mid tier releases 7.1.00 and 7.0.01. You can use any version of BMC Remedy User to see the flowchart view for an approval request, or view it through a browser.

NOTE When the AR System server has encryption enabled (Premium Security or Performance Security), the multi-process preview flowchart might take longer to load.

Table

The table depicts the approval sequence. If you add or remove an ad hoc approver, or perform any other action on the request, it is reflected in the flowchart immediately.

Figure D-37: AP:Show-Detail form—Multi-process preview table



Activity Log tab

Figure D-38: AP:Show-Detail—Activity Log tab

Table D-42: Fields on AP:Show-Detail—Activity Log tab (Sheet 1 of 2)

Field Description

Refresh Click to refresh the contents of this tab.

Justification For Action Enter some meaningful text in this field to be recorded as a justification for your action, and click Reject. An entry is added to the Activity Log table.If you click any other action button, this field is ignored.For information about how your input is processed, see “Rejection justification for approval requests” on page 40.After you enter text in this field and click Reject, the entry might not appear in the Activity Log table. However, the activity is recorded and the corresponding entry is visible when the request is opened again in AP:Show-Detail.

Activity Log Details This section enables you add, modify, and delete comments, questions, notes, and attachments to the current request.

Type This drop-down list enables you to specify whether you are creating a comment or a question.


User forms

Right click anywhere in this tab to open the Preferences context menu. This menu enables you to refresh the contents of the table, add or remove columns from the view, set the refresh interval, and reset or save the changes you make to the table.

Comments

This feature enables submitters (requestor and approvers) to include comments and attachments for an approval request. These could be useful as additional information for the next approver in the chain.

Question To Select a name from the user list or enter the AR System login name of the person to whom you want to raise a question. This field is enabled only if you select Question from the Type drop-down list.Using the Question To field, an approver can ask questions to the requestor or any other person who belongs to the same group as the approver.

Note: The approval server does not have any means to know where a particular user’s details are stored. (The consuming applications are responsible to validate the login name.) The source of a user could be any form other than the User form that AR System provides, for example, the user information could be retrieved from an LDAP server.

Question / Summary This field is labeled as Question when you choose to add a question to the approval request; enter the question here. It is labeled as Summary when you choose to add a comment; enter the brief comment here.

Response / Notes This field is labeled as Response when you view a question about the approval request; the corresponding response appears here. It is labeled as Notes when you choose to add a comment; enter the detailed comment here.

Attachment Use this field to add an attachment along with your comment. Only one attachment is allowed per comment.If you view a comment that has an attachment associated with it this table field displays the file name, size, and label for the same.Note that attachments cannot be associated with questions. This field gets disabled when you select Questions from the Type drop-down list.

Submitter Displays the name of the submitter.

Submit Date Displays the date and time of submission.

Add Click to add a comment or question to the approval request. This field is enabled only if you have the necessary permissions.

Save Click to save a new comment or question.

Cancel Click to cancel any new comment or question that you were trying to add to the current request.

Delete Click to delete the selected comment or question.

Table D-42: Fields on AP:Show-Detail—Activity Log tab (Sheet 2 of 2)

Field Description



Approvers can work with comments in the following ways using this form:

! Add or delete their own comments, and view the comments included by other approvers.

! Include an attachment at the time of creating a comment. They can also modify or delete the attachments associated with their own comments.

! Edit or delete comments of other approvers if they are the Alternate Approvers or Administrators. Approvers other than these can only view the corresponding details.

Requestors can work with comments in the following ways:

! Provide a comment with an attachment through the application form. The workflow on the Activity Log checks the respective application form for the requestor's comment on the selected approval request. If a comment is available, it displays the comment in the Activity Log table.

! Modify or delete comments they created. If the requestor modifies a comment or its attachment, or both, the Activity Log displays the modified details whenever an approver invokes the Activity Log (or refreshes the table).

Questions

This feature enables approvers to ask questions about an approval request to requestors and other approvers. These answers could be useful as clarifications to the current and future approvers in the chain.

Approvers can work with questions in the following ways using this form:

! Add, modify, and delete their own questions, and view the questions raised by other approvers.

! Edit or delete questions raised by other approvers if they are the Alternate Approvers or Administrators. Approvers other than these can only view the corresponding details.

Requestors can work with questions in the following ways:

! Cannot create a question because the Activity Log, which is invoked from Approval Central, is available only to approvers. A requester does not have access to the Activity Log.

! Provide the response to a question through the More Information form.

The Questions feature works as follows:

! An approver can raise a question to any user of the system (or application). If the notifications are configured, the respective user receives a notification. The user then clicks the Response button in the Approval Request Summary section of Approval Central to open the AP:MoreInformation form for the request.

! An approver can raise only one question at a time per request because, when a question is created, the status of the request is changed to More Information. After a requestor or approver responds to the question, the request is again assigned the Pending status.


User forms

! Approvers can modify or delete the questions they raised before the addressees respond to them. No notification is sent in this case.

! The question details in the table are associated with the Approval ID, Signature ID, and a Question ID.

! Questions cannot be redirected.

! Every question can be associated with only one answer.

AP:ShowDetail-DeleteVerifyThis dialog box appears when an approver tries to delete an Activity Log entry in AP:Show-Detail. The entry could be a question, comment, or justification that the approver created.

You can delete only one entry at a time. You cannot delete entries created by the requestor or other approvers.

! Click Yes to delete the entry for the request. The corresponding record in AP:Question-Comment-Info is deleted.

! Click No to close the dialog box without deleting the entry.


Appendix

E
Installing the approval server in a server group
This section describes how to install BMC Remedy Approval Server (approval server) in an AR System server group.

In an AR System server group environment, two or more servers share the same database. If one server stops working, another one continues to process requests. See the Configuration Guide, “Configuring server groups,” page 168.

In a server group environment, when an AR System server becomes unavailable, the newly active AR System server performs the following actions:

! Sets Approval-Server-Suspended: F in the ar.cfg (Windows) or ar.conf (UNIX) file on the unavailable server. This indicates that the approval server on that AR System server is unavailable for processing.

! Sets Approval-Server-Suspended: T in the local ar.cfg (Windows) or ar.conf (UNIX) file. The local approval server begins processing the approval requests.

Consider that servers with the following configuration are used to set up a server group named SvrGrp:

Table E-1: Sample server group configuration

Server type Server name

Processor architecture

Processor type

Available RAM

Operating system

Database

AR System SvrA SPARC Dual 4 GB Solaris 10 -

AR System SvrB SPARC Dual 4 GB Solaris 10 -

Database DataSvrC SPARC Quad 16 GB Solaris 10 Oracle 10gInstance name: svrgrpdb

Appendix E Installing the approval server in a server group 281


! To install the approval server in a server group

1 Install the AR System server on SvrA so that svrgrpdb hosts the AR System server data files.

2 Install the AR System server on SvrB, as follows:

a Use svrgrpdb as Database Name or Connection String.

b Choose the Server Group mode to install the AR System server.

3 Install the approval server on SvrA and SvrB.

4 Log in to SvrA, and perform the following steps:

a In a browser or BMC Remedy User, open the AR System Administration Console > System > General > Server Information form.

b On the Configuration tab, select the Server Group Member checkbox.

c On the Advanced tab, enter SvrGrp as the Server Group Name.

d Click OK to apply the changes.

Restart the server for the changes to take effect.

5 Repeat step 4 for SvrB.

NOTE The change in the Server Group Name is effective only when all servers in the group are restarted.

6 Apply the AR System licenses to one of the servers. The licenses are stored in the database and shared by the servers in a server group.

For example, log in to SvrA, and perform the following steps:

a Open AR System Administration Console > System > General > Add or Remove Licenses form.

b For the AR Server License Type, enter “SERVERGROUP=SvrGrp” as the License Qualifier.

c Click Save to apply the changes.

Restart the server for the changes to take effect.

7 Log in to any one of the servers, and perform the following steps:

a Open the AR System Server Group Operation Ranking form.

b Configure the approval server operation of Server SvrA to hold Rank 1, and save the form.

c Configure the approval server operation of Server SvrB to hold Rank 2, and save the form.

Restart SvrA and SvrB for the changes to take effect.


Appendix

F
Troubleshooting
This section contains troubleshooting information for BMC Remedy Approval Server (approval server).


! Installation and upgrade (page 284)! Error 333 and Assignee Group Permission (page 285)! Approval server log files (page 285)! Runtime issues (page 286)! Approval server configuration file settings (page 286)! System error messages (page 288)! Accessibility issues (page 288)



Installation and upgradeThis section describes known concerns regarding the approval server installation or upgrade.

Issues when upgrading to version 7.6.03The following issues occur when upgrading to version 7.6.03 of the approval server:

! The following error is written to the ARSystemInstallDir/Logs/Approval-RIK_PostUpgradeInstall.log file while the sample data is being imported:

ERROR (338): Duplicate Entry ID

You can safely ignore this error because it has no impact on the functionality of the approval server.

! When upgrading from version 7.1.00 on a non-root location, definition files are not updated.

Workaround: Before upgrading, explicitly set the write permissions to the installation folder.

Previous approval server installations

WARNING Version 7.1.00 or later of the approval server is incompatible with the version of the approval server bundled with certain Remedy applications. Do not install version 7.1.00 or later of the approval server on a system with any of the following Remedy applications:

! Remedy Purchasing@Work 2.x, or earlier! Remedy SetUp@Work 1.0, or earlier! Remedy Change Management 3.x, or earlier

Installer terminates while checking for conflictsIf 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 workflowIf you have customized a previous approval server installation, or customized an application that includes a bundled approval server, you should back up your customized forms, HTML files, and workflow before installation.


Error 333 and Assignee Group Permission

Error 333 and Assignee Group PermissionTo enable users to enter information into approval server forms, the form, field, and other object permissions must be set correctly. Most of the required permission settings are imported when you install the approval server. Only an AR System administrator, or a subadministrator with administrator permissions to the objects in question can change access control settings. See the Form and Application Objects Guide, “Defining access control,” page 19.

To support multi-tenancy, you must pass the -l parameter with the group values to the New-Details or Add-Sig command. If you do not pass the -l parameter, the approval server reports:

ARERR [333] You have no access to field: fieldID.

Approval server log filesThe AR System suite installer creates a log that records the results of importing all the approval server-related definitions and data. After installation, you can turn on approval server logging.

Location of log filesTwo copies of the installation log files are saved in the ARSystemServerInstallDir/Logs/ folder:

! Plain-text format

! Approval-RIK_PreInstall.log

! Approval-RIK_PostInstall.log

! HTML—Approval-RIK_PostInstall.html

ARSystemServerInstallDir is the directory where the AR System server executable is installed, such as C:\Program Files\BMC Software\AR System (Windows) or /opt/bmc/ARSystem (UNIX).

Log data for an upgrade installation is written to the following files in the same folder:

! Approval-RIK_PostUpgradeInstall.log

! upgrade.log

Approver server loggingTo verify that the approval server is running or to audit its activities, you can turn on logging as described in “Configuring server settings” on page 27. After you provide the log file name and location and save the server settings, the approval server begins logging. The first entry in the log file is:

<APPR> Approval Server Trace Log -- ON timeStamp



Runtime issuesThis section describes how to resolve some possible runtime issues.

Approver receives request but cannot respondWhen approving or rejecting an approval request, an approver might encounter the following error:

You are not currently defined as an alternate for any user and you are not on the Approvers list for this approval. (ARERR 10000)

Check the following and take the necessary actions to process the request further:

! Is the approver’s AR System user name is spelled correctly in the Validate Approver rule?

! Is the approver designated as an alternate approver for a time span in the past or the future?

Deadlocked approval serverThe approval server runs as an ARDBC plug-in. In some cases, such as when using the preview feature, the approval server makes a call back to the AR System server to retrieve and compile information. This is referred to as a loopback call, because the call to the AR System server occurs in response to a call from the AR System server. If the AR System server queues are overloaded, loopback calls can lead to a deadlock, and the AR System server will freeze until the calls to the plug-in server time out.

To prevent this, the approval server requires that the AR System server have a reserved RPC queue for loopback calls from the Plug-in server. If you do not configure this, the preview feature will not work. See “Private queues for loopback calls” on page 28.

Approval server configuration file settingsThe ar.cfg (or ar.conf) file is the AR System configuration file. It contains AR System server configuration settings and is created when you install AR System server.

In most cases, you do not need to enter the configuration settings manually. When you make a server configuration change in the Server Information dialog, or in the Server Settings window of the approval server, AR System enters the configuration parameters and their new values in the configuration file.

This section describes configuration file settings specific to the approval server. For information about other configuration file settings, see the Configuration Guide, “AR System configuration files,” page 345.


Approval server configuration file settings

Table F-1: BMC Remedy Approval Server configuration file settings

Configuration setting Description How to set it

Alternate-Approval-Reg

Specifies whether applications such as the approval server listen for the AR System server’s signal directly (F) or listen for the application dispatcher to signal (T).The default value of this setting is T, which makes sure that the approval server receives the signals sent by the dispatcher. You should change the value to F only when the application dispatcher is not working; this provides an alternative method to receive signals form the AR System server.

See “Application Dispatcher” on page 289.

The AR System server installation creates this entry and sets the value to T. To change the setting, use a text editor to edit the ar.cfg or ar.conf file.

Appr-Defn-Check-Interval

The interval (in seconds) after which the approval server checks for changed or updated data in the data definition forms.

AP:Admin-ServerSettings

Approval-Log-File

Full path of the approval server log file. AP:Admin-ServerSettings

Approval-Notify Specifies the approval notifications configured from the Server Settings dialog box. Each event ID has an Approval-Notify entry. Only change these settings from the Server Settings dialog box.


Approval-RPC-Socket

A specific RPC program number (RPC socket) dedicated to the approval server for calls to the AR System server. This setting defines a private queue for the approval server.


Plugin-Loopback-RPC-Socket

An RPC program number (RPC socket) dedicated to loopback calls from the Plug-in server. The approval server runs as a plug-in. If this value is set and Approval-RPC-Socket is not set, the Plug-in server uses this queue for approval server loopback calls.

AP:Admin-ServerSettings or Server Information dialog box.

Approval-Polling-Interval

This setting causes the approval server to poll the AR System server for pending work. It is intended to operate as a backup method, not the primary contact method. Under normal circumstances, the AR System server or the Application Dispatcher (depending on the configuration) contacts the approval server when work is pending.With this setting in place, the approval server polls the AR System server only if it does not receive any signal from the AR System server in the specified time.Specify the interval in seconds. The minimum is 30 seconds, and the maximum is 3600 seconds (one hour). For example:Approval-Polling-Interval:600

Edit the ar.cfg or ar.conf file with a text editor.



System error messagesThe approval server uses error messages in the AR System error range 4500 to 4899. These errors are documented in the Error Messages Guide along with all other AR System error messages.

Error messages are displayed in English unless specified otherwise. To display error messages in a localized format, select the Localize Server option on the Advanced tab of the AR System Administration: Server Information form.

Accessibility issuesWhen working with approval server forms, you might encounter the following accessibility issues:

! The Select All button on Approval Central does not work for section 508 users. If the user navigates to the Select All button by using the Tab key and presses Enter, only the next request is selected instead of all the requests in the table.

! The JAWS screen reader is unable to detect the check boxes that indicate which requests are currently selected.

! JAWS does not read aloud the following non-editable fields on Approval Central:

! The Approval Request Summary header

! The Source ID link

! The Activity Log header

! When a section 508 user opens a menu, a pop-up dialog box appears, which lists the items in that menu. Then, JAWS reads the items out aloud. If the user presses Tab, the focus moves to the Cancel button instead of the next item in the menu.


Glossary

action dateThe duration within which an approver must take action on a pending request. This value is derived from various process intervals defined on AP:Process Definition.

Ad Hoc processAn approval process type with no predictable routing, in which the requester and approvers select the subsequent approver. See also Parent-Child, Level, and Rule-Based process types.

Ad hoc overrideIn Parent-Child, Level, and Rule-Based processes, ad hoc overrides approvers to alter the predetermined routing. The Allow Ad Hoc Next Approver? field controls whether the process allows this.

alternate approveAn indication for notifications when an alternate has responded with an approval.

alternate approverAn AR System user with the authority to substitute for an approver within an approval process.

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

Application DispatcherAn AR System server process (Windows) or daemon (UNIX) installed with the AR System server that monitors the Application Pending form, and signals other server applications, such as the approval server, when they have work to do.

approvalAn electronic signature by an authorized person. In the approval server, an approval is indicated by the status “Approved” on a request that has followed an automated process to gather the required signatures.

approval applicationAn interrelated set of forms, workflow, processes and rules that allow users to enter a request and approvers to respond, route the request to completion, and generate notifications related to the request.

Approval Audit TrailA field in the detail form that tracks all status changes to the approval request, including the date, time, and approver name.

approval processA procedure that generates all necessary signatures to authorize an approval request in an AR System application.

Approval Process DoneA 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 requestA request entered in an approval application to request authorization for a change, an expenditure, or any other business situation that requires signatures.

approval request formAn AR System form used by requesters to enter a request for approval.

Glossary 289


BMC Remedy Approval ServerAn AR System application server that runs as a plug-in. It routes an application’s approval request form to generate signatures. The approval server also creates an audit trail for all approval activity.

approvedThe status of a signature when the approver has authorized the request. Also, the status of a completed approval request when all approvers have authorized the request.

approverAn AR System user with the authority to approve or reject approval requests.

approver listThe list of approvers eligible to respond on the signature lines for an approval process.

Auto ApprovalA rule type that allows for automatic approval by the approval server of a request that meets specified criteria.

cancel at later levelAn indication for notifications when an approval process is cancelled after it has been approved by a previous approver.

cancelledThe status of a completed approval request that was withdrawn by the requester or cancelled by an approver or process administrator.

chained approval processA sequence of approval processes that appear to the user as one approval, but in fact are made up of two or more separate approval processes.

close approveAn indication for notifications when a request has multiple possible but not required approvers and another of the approvers approves the request.

closed The status of an approval request that has been resolved and is no longer waiting for an approver or More Information response.

close rejectAn indication for notification when a request has multiple possible approvers and another of the approvers rejects the request.

Completion ruleA rule type that checks whether conditions exist to stop routing a request. If a completion check is successful, no new approvers will see the request. The request might not be done, but the request has been routed to everyone who must respond.

detail recordThe approval server creates an entry in the AP:Detail form when a new approval request is submitted. This form tracks the details of the approval process for the request. It is part of the two-way and three-way join forms that are central to approval processing.

doneAn approval request is done when all the required approvers have responded to the request, or the request is cancelled, or the approval server has put the request into an error state.

errorThe status of an incomplete approval request in which routing problems have occurred.

escalationA workflow component that searches at specified times or at regular intervals for requests matching a specified condition and performs specified operations on all matching requests. For approval requests, escalations are set relative to approval process actions and states.

Get AuthorityA rule type that gathers information about the current approver or environment that is used by subsequent Self Approval or Completion rules.

Get Authority RegularA rule type that gathers information about the current approver or environment that is used by subsequent completion rule tests.


Glossary

Get Authority SelfA rule type that gathers information about the current approver or environment that is used by subsequent Self Approval rule tests.

Get Next ApproverA rule type that finds the next approvers in the current process, including the first approver at the start of processing. Also, a stage of the approval process.

holdAn indication for notifications when a request is changed to the Hold status. This is also a status in which an approval request is assigned to an approver but the approver has held the request. In this case, no approval server activity occurs until the hold is removed.

join formA type of form that contains information from two or more AR System forms. Join forms point to the data stored on the AR System forms that were used to create the join form. The approval server uses the two-way join form AP:Detail-Signature, and a three-way join form, which is a join between the application’s approval request form and AP:Detail Signature.

LevelAn approval process type with relationships based on the approvers’ membership in organizational groups (not AR System groups). See also Parent-Child, Ad Hoc process, and Rule-Based.

More Information requestAn approver’s 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 returnAn indication for notifications when a More Information request has been responded to.

new signatureAn indication for notifications that a new signature record has been created for an approval request.

notificationA message to a user from workflow. This can be an alert, email, or other message using integrations. Notifications are linked to the approval request status and process states.

override approveAn indication for notifications when a process administrator has approved a request in a manner that circumvents the normal process.

override rejectAn indication for notifications when a process administrator has rejected a request in a manner that circumvents the normal process.

Parameterized Get Next ApproverA rule type that uses run-time variables to find approvers in the current process. It lets requesters and approvers add additional approvers to any level in an approval process (not just the next level).

Parent-ChildAn approval process type with a fixed relationship between approvers, such as a management hierarchy. See also Level, Ad Hoc process, and Rule-Based.

pendingThe status of an incomplete approval request awaiting response or more information from an approver. Also, the status of a signature line that is waiting for a response from the approver.

plug-inAn auxiliary program that works with the AR System server. A plug-in is a dynamically linked library (DLL) on Microsoft platforms and a shared object on UNIX platforms. The AR System plug-in service loads the plug-in at start time. The approval server is a plug-in.

Prep Get Next ApproverA rule type that gathers information to be used by the Get Next Approver rules.

process administratorAn AR System user who is a member of the Approval Admin group (402). Process administrators can have authority to set up and maintain approval processes, or to act as an override approver only.

Glossary 291


qualificationA condition statement using search criteria that can include field references, values, and arithmetical and relational operators. In approval server processes, rules, and workflow objects, condition statements are used to determine whether the process, rule, or filter should run, and to control data gathering.

reassignAn action for an approver to reroute a request by changing the assigned approvers.

reject by another approverAn indication for notifications when multiple required approvals are outstanding and one of the other approvers rejects the request.

reject by later levelAn indication for notifications when an approval process is rejected by an approver after it has been approved by a previous approver.

rejectedThe status of a completed approval request when an approver has rejected the request. Also the status of the signature line of the approver who has rejected the request.

requesterA user who submits a form to request an approval, triggering approval server action.

roleA named alias for one or more approvers. Using roles allows the definition of a position regardless of the individual approvers who are currently fulfilling that position.

Rule-BasedA custom approval process type designed by the process administrator, in which relationships are defined by rules rather than by data in a form. See also Parent-Child, Level, and Ad Hoc process.

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

signatureAn entry in the AP:Signature form that represents the response of an approver to an approval request.

Signature AccumulatorA rule type that is used to collect statistical information about the signature records associated with an approval process.

signature authorityThe ability of an approver to authorize a request, based on policies established by the organization and defined in a signature authority form.

signature authority formA form created by the administrator that contains approver names or roles and their signature authority limits, to support data gathering by get authority rules.

signature recordA database record in the AP:Signature form that represents the signature of an approver. If an approval request requires more than one signature, multiple signature records are generated for that single approval request.

Statistical OverrideA 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 fieldThe core field (ID 7) in which AR System tracks the status of a request. In the approval server, the AP:Detail form uses this field to track the overall status of the request. In the AP:Signature form, the field is renamed to Approval Status, and it tracks the approval status of the individual signature line.

Validate ApproverA rule type that is used to verify that a name specified as the next approver is a valid user. Only used to verify a user specified in an Ad Hoc process or an ad hoc override of another process type.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Index

Aad hoc

approvers for a request 208, 263getting next approver in process 78overrides 43processes 78

Allow Ad Hoc Next Approver 43alternate approvers

about 21, 50acting as 52defining for others 54designating 50modifying 52

Application Dispatcher 72Application Pending form 72Application-Command processes

See also Approval Server commandsabout 179Application Pending form and 180run process action 180syntax 180

approval applicationsconnecting to the Approval Server 152designing 152

Approval Centralabout 36fields 255form 255opening from home page 37opening in a browser 37opening in BMC Remedy User 37using 60

approval events 31Approval Process Done rules

creating 139examples 93, 140worksheet 205

approval processesabout 19, 72, 75Ad Hoc processes 78Approver Response stage 74

approval processes (continued)associating with an application 231chaining 147, 158completion 236Completion Check stage 74creating 98, 157, 196deleting 104filters and 148, 157Level processes 77modifying 103Next Approver stage 74Parent-Child processes 75Process Done stage 74process status field and 148renaming 104restarting 149routing 74Rule-Based processes 79rules and 72, 157Self Check stage 74stages of 73types 75workflow and 157worksheets 196

approval request form 71approval requests

Approval Status field 41approving and rejecting 41, 60checking 66complete versus done 74creating 59detail view 41pending 38processing 38reassigning 45, 61retrieving 38routing 74, 76, 77, 78, 85search criteria 38viewing 41

approval rule types, diagram 82

Index 293


approval rulesall get authority 116Approval Process Done rules 93associating with a process 112Auto Approval rules 83Completion rules 92creating 110, 200defining actions 113deleting 141Get Authority Regular rules 91Get Authority rules 84Get Authority Self rules 84Get Next Approver rules 85modifying 141order 112Parameterized Get Next Approver rules 86Prep Get Next Approver rules 85processes and 82qualifying conditions 112querying 113running server processes 113Self Approval rules 84setting values 113Signature Accumulator rules 88SQL commands in 113Statistical Override rules 88Validate Approver rules 86worksheets 200

Approval Serverbasic concepts 19configuring 24, 286connecting an application 152error messages 288flowcharts and 33forms 207server settings 27upgrading 174

Approval Server commandsAdd-PGNA-Values 168, 182Add-Sig 183Det-Approved 184Det-Cancelled 184Det-Error 185Det-Rejected 185Generate-Multi-Process-Preview 186Generate-Preview 186MoreInfo-Return 187New-Details 187Rename-Form 188Rename-Process 188Sig-Approved 189Sig-Cancelled 189

Approval Server commands (continued)Sig-Notify 190Sig-Notify-Change 190Sig-Notify-State 191Sig-Reassign 192Sig-Rejected 192Update-Config 193

Approval Status options 87approver list

about 20Get Next Approver rules and 124

approver name length 95Approver Response stage

about 74rules in 87

approversabout 20adding 43cannot respond 286field menu of approver names 168manual specification of 43multiple 106next approver 43

AR System configuration files 286AR System object list 37ar.cfg 286ar.conf 286arjoinfix

connecting applications to the Approval Server 155

portnum parameter 156updating three-way join forms 176

Assignee Group Permissions fieldmulti-tenancy and 238rule configuration 112

Auto Approval rulesabout 82creating 114examples 83, 115Self Check stage and 74

BBMC Software, contacting 2business time, configuring 32



Cchaining approval processes 147, 158Completion Check stage

about 74rules in 91

Completion rulesabout 92configuring processes and 236creating 138determining success 92examples 91, 92, 138worksheet 204

configuringApproval Server 24flowcharts 33process administrator 26

customer support 3

Ddebug log 27definition check interval 30documentation, AR System 13

Eerror messages 288escalations, configuring 32

Ffield permissions, troubleshooting 285filters, approval processes and 148flowcharts, Approval Server and 33forms

See also forms, application; forms, Approval Server; forms, Get Agreement; forms, Lunch Scheduler

administration forms 208renaming 104user forms 255workflow and 166

forms, applicationapproval request

about 71arjoinfix and 155connecting to the Approval Server 152creating 153linking a process to 231linking to the Approval Server 156permissions 153

signature authority 72supporting forms

about 70examples 146

three-way joinsabout 71, 153arjoinfix and 177creating 154request details 41updating for release 7.x.xx functionality 176

two-way joinsabout 153creating 154

forms, Approval ServerAP:Admin-DeleteVerify, fields in 210AP:Administration

creating processes 98creating rules 110fields in 209Form tab 156using 24

AP:Admin-Renamefields in 210using 104

AP:Admin-ServerSettingsescalations 32fields in 212notifications 31using 27

AP:Alternate, fields in 266AP:Detail

about 70fields in 215

AP:Detail-Signatureabout 71fields in 217

AP:Dtl-Sig-MoreInfoDialog, fields in 268AP:Form, fields in 220

Index 295


forms, Approval Server (continued)AP:More Information

about 72fields in 269permissions 64using 62

AP:NotificationBasic 159Details 162Email 163fields in 223

AP:Password, fields in 270AP:Pending Approvals 255AP:PreviewInfo

approver name length and 95configuring previews 33fields in 227retrieving data from 168

AP:PreviewSignatures 95AP:Process Administrator, fields in 229AP:Process Definition

creating a process 98defining More Information escalations 103defining signature escalations 101fields in 231

AP:Reserved Word, fields in 245AP:Role

defining roles 106fields in 246

AP:Rule DefinitionBasic 111fields in 247Set Fields 113

AP:Signatureabout 71fields in 252

Application Pending, about 72Approval Central

Approval Central and 36fields in 255

GGet Agreement

about 58activating rules 136AP-Sample2:Get Agreement form 59AP-Sample2:Issue Detail Signat form 62sample users 58statistical decision-making rules in 133three-way join form 62

Get Authority Regular rulesCompletion stage and 91creating 116worksheet 203

Get Authority rulesabout 82creating 116examples 117using with Self Approval rules 84versus Get Authority Self rules 84worksheet 200

Get Authority Self rulesabout 82creating 116using with Self Approval rules 84versus Get Authority rules 84worksheet 201

Get Next Approver rulesabout 85approver list and 124creating 121, 123examples 85, 125Level processes 122multiple rules 124Parent-Child processes 122Rule-Based processes 123worksheet 202

IIf Multiple Approvers

field values for 106installation, troubleshooting and 284

LLevel processes

about 77examples 145getting next approver 77requirements 77

licensing sample users 150log files

about 27configuring 30using 285

loopback callsavoiding deadlocks 286private queues and 28



Lunch Schedulerabout 144AP-Sample:Company form 146AP-Sample:Lunch Scheduler form 145AP-Sample:Lunch-Detail form 145AP-Sample:Lunch-Detail-Signatu form 145AP-Sample:Restaurant form 146AP-Sample:Signature Authority form 72, 146defining signature limits 134forms in 145Level process example 147licensing users 150Parent-Child process example 146process functionality 148processes in 145, 146Rule-Based process example 147users 150

MMore Information escalations, creating 103, 196More Information requests

about 45Approval Status and 63creating 46, 62responding 47, 63viewing 47viewing responses 48, 65viewing your submitted 48

multi-tenancyAssignee Group Permissions field 112supporting 238

NNext Approver stage

about 74ad hoc next approvers 86rules in 85

notificationsconfiguring 31creating 158Notify On options 160workflow-based 165

Notify On options 160

Ooverrides

global 55performing 54single signature 55

PParameterized Get Next Approver rules

about 85creating 126examples 128previews and 86, 168versus Get Next Approver rules 86worksheet 203

Parent-Child processesabout 75examples 145getting next approver 76requirements 76

passwordsrequiring for approval 237show field dynamically 167

Plugin Loopback RPC Socket, configuring 28, 30Plug-in server

configuring 30loopback calls 286

portmapper, arjoinfix and 156Prep Get Next Approver rules

about 85creating 120examples 85, 120Get Next Approver rules and 85worksheet 202

previewsAdd-PGNA-Values command and 168AP:Preview Data form 226configuring 33, 168, 234flowchart view 274multi-process preview 170, 226options 234Parameterized Get Next Approver rules and 168tabular view 275

Private AR Server RPC Socket, configuring 28, 30private queues

See also Plugin Loopback RPC Socket; Private AR Server RPC Socket

about 286

Index 297


process administratorsabout 21capabilities 25configuring 26creating 26defining alternate approvers 54performing overrides 54prerequisites 26responsibilities 25

Process Done stageabout 74rules in 93

process status field 148processes, about approval 19product support 3

Rrequesters 20requests

AP:Show-Detail form 271reassigning 45viewing details 271

rolesabout 20, 106defining 106

RPC sockets 30Rule-Based processes

about 79examples 145getting next approver 79requirements 79

Ssample applications

Get Agreement 58Lunch Scheduler 144

sample formsGet Agreement 59Lunch Scheduler 145

sample users, approval authority 150security, requiring passwords to approve 237Self Approval rules

about 82creating 118examples 84, 119get authority rules and 83Self Check stage and 74worksheet 201

Self Check stageabout 74rules in 82

Signature Accumulator rulesabout 88creating 131default statistical data and 131examples 89, 132Get Agreement functionality 133, 135Level processes and 89signature lines and 89worksheet 204

signature authorityform 72Lunch Scheduler sample application and 150

signaturescreating escalations 101, 197creating lines 85limits 134

specifying additional approvers 43statistical decision-making rules

See also Signature Accumulator rules; Statistical Override rules

about 88Statistical Override rules

about 88actions 89creating 132default data and 90, 137examples 133Get Agreement functionality 135process types and 89worksheet 204

status 41support, customer 3

Ttechnical support 3three-way join forms

See also forms, applicationexample 145

troubleshootingconfiguration file settings 286deadlocked Approval Server 286error messages 288field permission errors 285installation 284

two-way join formsSee also forms, applicationexample 145



Uupgrading the Approval Server 174users, licensing sample 150

VValidate Approver rules

about 85creating 129examples 86, 130worksheet 201

WWeb access 178workflow

enhancing Approval Server forms 166notifications and 165

worksheetsMore Information escalations 196processes 196rules 200signature escalations 197

Index 299

*160826**160826**160826**160826*

*160826*

approval server guide 7.6.03

Documents

ar system

ar system

bmc remedy

ar system

ad hoc settings

ad hoc override

ar system

ar system